1.
Since we don't have builder theme, I can't comment on that. But I have
seen using standard theme and left navigation, it appears under "Browse
Space".
2. This is configuration issue.
By default, Plugin allows only user groups that follow this naming
convention SPACEKEY-.+ so if your wiki spacekey is TEST, then it will
only show any groups starting with name TEST- like TEST-users or
TEST-admins etc.
This is done to restrict, Space Administrators to manage users for
their wiki space. Else they can update any user-groups which can be
security hole.
To test the things; you can configure Usergroups usage pattern as .*
With regards to use with Builder theme, we added extended support
for this plugin in Builder 2.0.8. Just add a new link to your menu (eg.
Edit > Administration menu) for the user management as follows:
{menuitem}{menulink:customusermanagement}Space user management{menulink}{menuitem}
That will then show the link in the menu. You can of course add the
link to any of the menus, or indeed anywhere else in the theme layout.
If using it outside a menu, add the flat=true param to the menuitem macro.
First I made a couple of mistake using the plugin but everything's ok now.
That's awesome because I had been searching for this kind of plugin
for a long while. There is only one stuff that could be great about
group management : the ability to browse the group itself. Is it
something coming soon in a new plgun's release?
Do you mean that you would like to know who are all users for given user-group ?
If that's the question then yes, I'm planning to add feature that very soon as I get time.
Yep, that was the question. I also found a pretty useful macro :
Unknown macro: {user-lister}
. It basically lists users of a given group. I am really waiting your new features, .
I got another customer request that could be interesting too. A lot
of space admins are interested in getting the same user permission
feature within group management. It might be a simple link to user
permissions.
I
tried this but when we click "View Users" an empty window pops up. I
dropped it back to the original version for now, perhaps I missed
something in installation.
There seems to exist a bug with this plugin and LDAP user management:
Basically it works fine. However, if I try to add multiple users a
"space group" at once, I get the error message that one or more users
do not exist (eg. for test1, test2):
* Some of the Users may not have been added to System.
Either following are invalid userids Or there is some issue with LDAP configuration.
Please verify with Confluence Administrator.
* List of not added Userids: test1, test2
Add test1 and test2 in two separate steps works fine.
When I developed this plugin, I couldn't able to test with user
management delegated to LDAP. (Is that the way you folks are using?) as
such setup is not available to me.
If you are able to add one user at a time, then adding multiple users should work too.
So just few questions to get more details:
1) Are you using the latest version of this plugin (it's also available through Repository Client!)
2) Can you please tell describe following settings for this plugin:
a) What's the value/setting for "User Manager Location:"
b) Are you using LDAP for User Authentication?:
I can't think of any which should not allow to work.
If you have handson on code development, I can recommend turing on
log and go through exceptions thrown. Else If it's possible (and ok?)
may be I would like to see things live in action.
Having some trouble here. Hopefully I'm remembering this sequence of events properly.
For a space, I was experimenting with creating the groups that would
be managed by space admins for my space and I seem to have hosed the
permissions for that space completely .
The space's key is DCP. I created the group dcp-user and gave it
permissions in the space. when I looked as a space admin,
however, the groups did not show up. So, I thought it might be
case sensitive and went to the Adminstration console to delete dcp-user
and add DCP-user.
If I try and delete the groups from the administration console, or
edit the permissions for the space in question, or click on its Manage
Users tab, I get this error (whether the plugin is enabled or not):
org.apache.velocity.exception.MethodInvocationException: Invocation of
method 'getGroupSpacePermissionsForSpace' in class
com.atlassian.confluence.user.actions.RemoveGroupAction threw exception
class net.sf.hibernate.LazyInitializationException : Failed to lazily
initialize a collection
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:309)
caused by: net.sf.hibernate.LazyInitializationException: Failed to lazily initialize a collection
at net.sf.hibernate.collection.PersistentCollection.initialize(PersistentCollection.java:201)
caused by:
net.sf.hibernate.UnresolvableObjectException: No row with the given
identifier exists: 2747, of class:
com.atlassian.confluence.security.SpacePermission
at net.sf.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:38)
Stack Trace:
[hide]org.apache.velocity.exception.MethodInvocationException:
Invocation of method 'getGroupSpacePermissionsForSpace' in class
com.atlassian.confluence.user.actions.RemoveGroupAction threw exception
class net.sf.hibernate.LazyInitializationException : Failed to lazily
initialize a collection
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:309).....
1. Yes group names are case sensitive that might be the reason, it
didn't appear in "Manage Users" tab. By default only groups that will
be displayed are of pattern SPACEKEY-.*
2. Regarding exceptions ... if you see the exception
caused by: net.sf.hibernate.UnresolvableObjectException: No row with
the given identifier exists: 2747, of class:
com.atlassian.confluence.security.SpacePermission
at net.sf.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:38)
It seems to be error thrown at SpacePermission.java.
3. Also one suggestion may be: you can try to play with other wiki space and add/associate user group with it.
We are using Confluence 2.3.1 and Jira 3.7.2 with user
management is delegated to Jira. I have followed all
the installation instructions but could not get the plugin to work.
It seems like many plugins "broke" when Jira 3.7 came out so I was wondering if this was one of them.
This
plug-in is working in an LDAP configuration on Confluence 2.4.5, except
that the users are not being added automatically to the
"confluence-users" group (only the selected space group.) The
plug-in configuration setting for LDAP is set to YES.
Suggestions?
Yes plugin should be able to add user to confluence-users. If
possible can you please explain me the detailed steps so that I can
simulate situation where it's not adding.
I myself has not tested in clustered environment as I don't have that setup.
My guess is it should be able to work. But best would be test it before you start working.
Right now I'm working with great folks from Duke University to
extend this plugin (like delegating functionality of creating new user
groups).
Issue here is, & a special character that being used as separator for parameter=value pairs. So in case selectedGroupName=d&d-users, selectedGroupName=d is one name value pair and other is d-users parameter.
We will see if encoding parameters can resolve this issue. Till then
I guess it's best to avoid special characters in user group naming.
This
looks great and exactly what I need to delegate Space related group
management. But. I have an LDAP directory that requires authentication
to access. The rev 1.1 plugin does not allow the specifying of a bind
user.
Related: why specify LDAP stuff anyway, its already in the osuser.xml file? I wrote some code to pull it out for the Confluence NTLM authenticator, perhaps that could be used to solve both issues? I'll have a hack anyway.
On
deployment I had a problem with multiple commons-logging api's found. ?
Not sure why the plugin got bundled with all the supporting JAR's (I'm
a newb at confluence plugins), removing all the JAR's solved that
problem but then after successful upload, trying to configure it got:
org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource '/templates/permissionmgmt/configure-usermgmt.vm'
at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:501)
at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:384)
at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:814)
at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:796)
at org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:512)
I had to search/replace "configure-usermgmt.vm" for "configure-plugin.vm"
Also, search/replace " actionmessages.vm" for "action-messages.vm"
That fixed it. But the Edit then broke. Im thinking trunk is in major flux right now. Any ideas when its going to be stable?
Right now we are working on few things like making this plugin:
Maven 2 compliant
Adding functionality of creating user groups.
Nice folks from Duke University are helping on adding this features.
Hence source may not be stable then. Hopefully we will fix it soon.
Regarding LDAP parameter additions. Yes if we can get the details
from osuser.xml that would be great. I will see how we can integrate.
If you have any easy way to do it let's know.
We should have a release sometime towards the end of this month (July 2007).
v2.0 of the plugin has been developed by a few of us at Duke University and built upon Rajendra's work.
The current version (pre-v2.0) is currently available at http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/trunk/.
Please note that trunk may be unstable, as there is still some work
left to do on it. We will tag it and release it via this page and
submit it to the central plugin repository sometime before the end of
the month.
The only supported build available for the plugin is Maven 2 can be
found in the README in the trunk dir. The Maven 1 build in trunk will
be removed in the next few weeks. (Originally was going to keep it but
there is no reason to.)
If used with normal "Confluence" user/group management option, the
primary outstanding bug in the plugin is one that keeps the page from
refreshing after a user is removed from a group. I'm looking into that
currently. It has been tested with thousands of users in the Confluence
database and uses Atlassian's PagerPaginationSupport and Pager classes
to handle a lot of data reasonably well.
The "JIRA" user/group management option has not been tested since
v1.1 and has been transitioned for now to a hybrid of using JIRA SOAP
service for user/group management with the exception of using a JNDI
datasource to read (list) groups from the JIRA database, since that
functionality was not available in the SOAP service.
The code needs a lot of cleanup and needs some tests. We also need
to remove Duke-specific references and move messages into i18n
properties. We also want to change the directory structure to be a
"normal" maven 2 layout. We will be updating a lot of it over the next
week.
Also note, I would try it in a test environment before putting it
into production. The configuration has changed so if you deploy it into
an environment where v1.x was deployed, the plugin will not work until
you update the configuration (but doing that should be straightforward
because it is self-documenting).
We
have a fairly large site with some 1000 users. This plugin is
becoming the corner-stone of our effort to decentralize the user
provisioning process.
It
would extend the possible userbase of this plugin if the configuration
allowed an LDAP user and password to be set against the following keys
in the environment used to create the InitialContext:
Completely
agree with this. We're about to turn off anonymous access to our LDAP
servers for security purposes and I've got 100s of groups that are
going to be dead in the water. Ouch!
In the past, Andy has given two classes which can be used to get the
LDAP information from osuser.xml. I have to take closer look at it
though.
Right now this plugin is getting major changes in whole UI and
functionality. Alpa release should be available next week. Once we get
stable release out, will start working in this direction.
Thanks for the reply. We're really looking forward to the new functionality.
As for the anonymous LDAP piece, I've just been advised that
anonymous LDAP access will be turned off in two weeks. Let me know if
you'd like me to get one of my developers to give you a hand on
updating that piece.
Yes, some pretty big changes in v2.0. Basically the changes are:
Contains space group creation/deletion (the main reason for the new version, but is optional)
Lets
you do a search for users by username, fullname, email by starts with,
contains, ends with (is optional- if you have a lot of users and don't
want to upgrade to new user schema that atlassian support you may find
it slow. we wanted to include search by groupname, but would have
likely been too slow with a lot of users/groups)
UI is almost totally different (bulk import page is almost same though)
JIRA
functionality uses the JIRA soap service, so it no longer requires the
JIRA RPC plugin. However, because of missing functionality around group
listing it currently requires the username and password for the JIRA
It totally kicks butt
It
is almost fully i18n'd (except config help comments and config errors)
- this wasn't totally altruistic as we need Duke-specific messages and
labels, etc.
However, we ran into a few issues that we're still fixing. If we
hadn't just gone live with it and had a bunch of clustering issues
separate from the plugin, it would have been available by now.
Things left to do before alpha release:
Fixing some major bugs that came into full view in a last few days
Ren is adding confirm functionality to group removal (has the prototype done using YUI)
Things that we need help from others in testing (mostly because we don't have time at the moment):
Testing use of JIRA for user management in plugin
Testing LDAP integration
I will do my best to fit in the stuff around making LDAP support
authentication, and the info you supplied takes me 95% of the way there
(I just don't know how to get info from osuser.xml easily via the API
yet, so I may just add that into config for now)
Ren, could you talk a little about the UI changes?
Form
a UI standpoint we've split the the UI in to a basic (primary
interface) and advanced (bulk editing). Here are a few of the features
worth highlighting:
Group creation can optionally have users associated with the group at the time of creation.
Through the primary interface users can page through groups and delete users graphically.
From
the search interface a user can search the Confluence Directory and has
the option to add or remove users listed in the search results to /
from the currently selected group.
As Gary mentioned, Alpha release is going to be available very soon.
We need guys who can test the plugin in their environment. I myself
will be testing the functionality over the weekend.
I hope we should be able to get things done before your two week deadline.
Right now the outstanding bugs with v2.0 in trunk are:
Adding user with new group is creating groups but having
error on adding group membership because I put in a check to make sure
the group exists (somehow in confluence API it would seem, it is
converting the groupname to lowercase which I never noticed it doing
before which is throwing things off a bit)
Bulk add user to
groups is only adding user(s) to first group (I'm pretty sure this is
because the code to pull groups from checkbox list was changed from
v1.1)
Am working on those this afternoon and will get a link to the jar
posted to this page once completed. Note again that LDAP and JIRA
functionality haven't been tested. We'll do our best to get the
username,password configuration (optionally) into config for LDAP.
Rajendra has his environment ready to test JIRA (and maybe LDAP?) I
think, so maybe he can tell me whether that is working fine or not.
Anyone who wishes to test would be great. I'll go ahead and put a new
project version into JIRA link above so you can write bugs against it.
Finally, please note that even though the v2.0 plugin may be exactly
what you need, don't place your job security on it. I had to spend a
good bit of time exploring poorly documented parts of the API and
getting the paging and user-atlassian part of Confluence 2.5.4 API to
behave and to work around bugs in it. Because of this, testing has
mostly consisted of trial and error. Ren and I did have it working
previously though with more than 45,000 users without it being slow
(with exception of search which is unusably slow with that many users
but that is optional in config and we're hoping that is because we
haven't done the user/group schema upgrade to get off of the open
symphony stuff as Atlassian suggested).
Will comment further as make progress. You are welcome to build
trunk if you want to see where we are. See README for details on
building.
Bugs we knew of in the plugin have been fixed (but we still haven't
tested with ldap and jira so if you can please test that too and let us
know what happens).
Ren and I however noticed a new bug in confluence massive 2.5.4 that
happens when multiple nodes in a cluster are doing group management at
once:
org.springframework.orm.hibernate.HibernateSystemException: a
different object with the same identifier value was already associated
with the session: 46, of class:
com.opensymphony.user.provider.hibernate.impl.HibernateGroupImpl;
nested exception is net.sf.hibernate.NonUniqueObjectException: a
different object with the same identifier value was already associated
with the session: 46, of class:
com.opensymphony.user.provider.hibernate.impl.HibernateGroupImpl
net.sf.hibernate.NonUniqueObjectException: a different object with the
same identifier value was already associated with the session: 46, of
class: com.opensymphony.user.provider.hibernate.impl.HibernateGroupImpl
at net.sf.hibernate.impl.SessionImpl.doSave(SessionImpl.java:852)
at net.sf.hibernate.impl.SessionImpl.saveWithGeneratedIdentifier(SessionImpl.java:790)
at net.sf.hibernate.impl.SessionImpl.save(SessionImpl.java:749)
at org.springframework.orm.hibernate.HibernateTemplate$12.doInHibernate(HibernateTemplate.java:492)
at org.springframework.orm.hibernate.HibernateTemplate.execute(HibernateTemplate.java:312)
at org.springframework.orm.hibernate.HibernateTemplate.save(HibernateTemplate.java:489)
at bucket.user.persistence.dao.hibernate.BucketGroupDAO.saveGroup(BucketGroupDAO.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:284)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:155)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:122)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
at $Proxy5.saveGroup(Unknown Source)
at com.opensymphony.user.provider.hibernate.HibernateAccessProvider.create(HibernateAccessProvider.java:52)
at bucket.user.providers.ChainedUserProvider.create(ChainedUserProvider.java:115)
at bucket.user.providers.CachingAccessProvider.create(CachingAccessProvider.java:81)
at com.atlassian.user.impl.osuser.OSUGroupManager.createGroup(OSUGroupManager.java:89)
at com.atlassian.user.impl.delegation.DelegatingListGroupManager.createGroup(DelegatingListGroupManager.java:162)
at bucket.user.DefaultUserAccessor.addGroup(DefaultUserAccessor.java:188)
at com.atlassian.confluence.user.DefaultUserAccessor.addGroup(DefaultUserAccessor.java:81)
have submitted that as support issue and will let you know status. Please test the plugin out though.
I just looked at the beta1 (cant raise a bug report, not registered with jira, yet). Installed ok, but got a stack when :-
Select Browse Space, Select Manage Users/Groups,
Was present with some lines of text saying I needed to do a few
things, and that an admin had to configure it _here_, when clicking the
_here_ link, I was asked to login again, following this, I got:-
com.opensymphony.xwork.config.ConfigurationException: There is no
Action mapped for namespace /admin/plugins/custompermissionsconfig and
action name config
at com.opensymphony.xwork.DefaultActionProxy.(DefaultActionProxy.java:72)
at com.opensymphony.xwork.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:45)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceAction(ServletDispatcher.java:227)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:199)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:117)
at com.atlassian.confluence.util.profiling.ProfilingPageFilter.parsePage(ProfilingPageFilter.java:137)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.atlassian.core.filters.ServletContextThreadLocalFilter.doFilter(ServletContextThreadLocalFilter.java:21)
...
I think I had some bad config setup, but going back to the plugin
config and keying values until all were valid, seems to have solved
this. I guess the configure_here route should work but doesnt ?
Please don't use Base URL unless critically necessary as it results
in an absolute URL rather than a relative URL. This can cause all sorts
of problems with Confluence sites that can be accessed from multiple
entry points – for example every site out there which can run over both
HTTPS or HTTP, as well as ones which have multiple subdomains pointed
to the same Confluence install.
Fixes for most of the bugs Rajendra found over the weekend,
and integrated the patches he submitted. (Couldn't reproduce a couple
of those bugs though, which I left outstanding.)
Note that
one of those fixes was that you no longer need a JNDI datasource for
JIRA because listing groups can be done via confluence atlassian-user
API even when using JIRA. (Thanks, Rajendra for pointing that out!)
Added fix to confluence root references in vm's provided by Dan today.
Integrated
code provided by Andy to get LDAP username/password/etc. from
osuser.xml. (We're hoping Andy or someone else can test it with the
atlassian-user schema also, to make sure it works for those that have
upgraded.)
Hi
Gary, I've just completed the commons-digester based parser for
atlassian-user.xml , hopefully should be integrated tomorrow. We
could use some UI plumbing to choose which source to use as both files
can exist with LDAP content...
Let
me know and I can add that to the config. Be careful if you are putting
stuff in trunk to svn up first... some major changes today around
directory structure and package name.
looks maven2 standard, but not sure about top level package name
I still don't seem to have commit rights in any case. Not to
worry. I'm almost there with non-Atliassian dependant parsing of
osuser and atalssian-user files, given me another day or two to get
Unit Tests in and commit setup and then we'll need a UI selection based
on a list of 'providers'. It would be possible to have another
provider, sourced from the atlassian-user module, but Im not sure how
far back the API will be valid for (or forward), best to keep Atlassian
dependencies to a minimum?
As
a general question for the community... would people rather have the
Jira SOAP username, password, and endpoint URL set in
spaceusergroupmanagementplugin.properties (which you need to put
somewhere on classpath on every node running confluence), or would you
rather this simply be put into the UI for the configuration?
The only reason we chose to use a properties file, was because we
thought there might be a security concern around storing a password in
configuration. However, the bad side of using a properties file is that
it is a pain to change values and could be a pain to use in a clustered
environment since the properties file would have to be the same in all
of the nodes (although this is usually a one-time setup unless you have
to change the username/password/JIRA SOAP service endpoint URL).
my
2p: So long as the password isn't shown (is ***'d) in the UI it
shouldn't matter). The passwords could be stored in encrypted
(blowfish/3des etc) entered through the UI so as to avoid having
plain-text passwords but of course, if the source is open, so is the
decryption technique, making the whole thing moot-ish.
If a properties file were used, that would mean that non-clustered
plugin-installers would not be able to use this direct, possibly
through the plugin repository, which would be bad.
Why not do both, but go for the larger user-base of stand-alone
systems and do it primarily through the UI, storing the result in a
property file. If we incorporate a check for the existence of a
given property file (and possibly disablement of the UI aspect), this
will then allow custom cluster-installers to roll their own and to take
advantage of that feature.
Note
that I'm holding off on the alpha-3 build for a little while until we
get more feedback. Trunk contains an LDAP fix. It got broken in alpha-2
because of a bug in my integration of Andy's LDAP code, which we aren't
really setup to test with currently. Thanks to Rajendra for finding
that.If you need the fix in the meantime, just build trunk.
FYI
- I'll drop this into our test environment as soon as alpha-3 releases.
The LDAP piece is what we're interested in and prefer the
atlassian-user.xml pull or the UI entry. In our environment (Fortune
100) we've outsourced all support so making changes to properties files
is a long process.
We
are doing what we can to have an alpha-3 release this afternoon, and at
the latest (depending on atlassian) we'll release alpha-3 early next
week. Thanks to Andy and Rajendra for all of their hard work this week!
P.S.-anyone know when svn.atlassian.com is going to come back up again? Is hard to develop without source...
A number of bug fixes in 2.0-alpha-3. I got all of Andy's LDAP stuff
in correctly with config for LDAP username, passwd, etc. Rajendra found
a lot of bugs and sent in some patches we integrated, and I believe
that Rajendra tested LDAP successfully (so it should in theory support
both anonymous and authenticated LDAP). We also added support to keep
users with personal spaces from being able to manage users/groups
through the tab provided by this plugin.
It would be nice if you all could all test this out in a test environment and add some tickets to our plugin's JIRA project if anything is not working or is acting funny. Contact a JIRA administrator for access to JIRA. Comments to this page would be great also (it is just less messy to handle bugs in JIRA).
I committed updated LDAP code today, that addresses
firstname/lastname, also solving an outsanding problem with
Digester. If you can, test it out and let me know how it goes.
Thank you very much for providing such a nice plugin !
In our organization,we reached at one obstacle though, which we think is a security hole.
I have set the group patterns as ".*", so that all groups are available.
We have given the ability for personal space to all users.As they have
the personal space,they also have the rights to access the Space
Permissions for their personal space.So naturally,they can add any
group to their personal space.The user with the personal space has
access to "Manage Users" too , and hence can add/delete any user from
any group.So, in a way, this facility is available to all the users(as
everybody has a personal space), whereas we plan to give this only to
the space administrators.
Can
definitely understand that. If you could set up a test instance though
(even if it is just local) and give it a try, it would
really help to see what you think of it. (I believe it is almost fully
functional. You may not even notice the parts that aren't working.)
Looks
like Alpha-4 succeeded in resolving the LDAP issues I reported. Still
more to go, though, and I'll open a pair of issues now. Thanks for
working so hard on this!
Rajendra,
Andy, and I were just speaking offline about this and realized that it
was unclear that the original (and still current) intent of the LDAP
functionality within this plugin is for those running confluence
instances that are NOT using LDAP for user authentication to be able to
automatically provision users using information from LDAP when adding
users to groups via the plugin. Prior to this, even though I could see
that the plugin autoprovisions users this way when LDAP is configured
in the plugin, I didn't realize that this was only for those that
weren't using LDAP for authentication (although now it makes sense).
All this is to say, if you are using LDAP for authentication in
confluence, it sounds like you do NOT need to configure LDAP in the
plugin (which sounds counterintuitive, so we'll need to document this
in the plugin configuration and in the setup instructions for the
plugin fairly well). It is pretty cool that it can do that, but I'm
sure it was a point of confusion to others (because I didn't even know
it).
We use LDAP for user authentication. We use Confluence for group
management. (Well, LDAP too but not so much.) We use this tool, current
release version, to allow Space Admins to add users from LDAP to
Confluence groups.
Given all that, are you saying I need to go back in and, uh, de-define the LDAP stuff to get it to work right in my environment?
Lost I am!
Captcha: awaked - your post awaked me to the fact that I may have been misunderstanding...
The
LDAP config items within this plugin's configuration (not talking about
confluence, osuser or atlassian-user config, only the plugin config)
are currently only used to autoprovision users in confluence if they don't already exist in confluence (and they would already exist if you were using LDAP in confluence itself for user authentication, I'd think).
So in brief, if you are using LDAP for confluence user authentication, then you don't need to configure LDAP within the plugin configuration itself.
I created a ticket a little while ago for us to make it abundantly
clear in the plugin config and in the documentation above that this is
the case. Thanks to Andy for pointing this out and to Rajendra for
clearing it up.
Ok,
I'll remove the LDAP stuff from the Plugin by setting "LDAP
Authentication Used?" to No and see what happens. Won't be able to test
until SUSR-32 is resolved, though.
So now you've got me wondering why I have LDAP information defined in the current release version of the plugin...
But here is the thing: When you are associating given users, if
Confluence user account is not available for those users; CSUM will use
LDAP to get their details, create user account and then add those users
into mentioned groups.
Alrighty,
now you're confusing me and slightly contradicting Gary. So you're
saying that if a Space Admin goes to add a user that's not already in
Confluence, which happens, then CSUM does need to have the LDAP information so that it can go look up the account, add it to Confluence* and then to the group?
Given that last, then, where am I supposed to be entering my LDAP
authentication information? And if the answer is that it picks it up
from atlassian-user.xml, my follow up question is why I have to define
anything in CSUM at all since it's all in atlassian-user already?
Difficult, aren't I?
*One hopes it honors our settings that any account added to Confluence be added to "confluence-users" as well.
Captcha: stages - I'm starting to grasp the new settings to this plugin in stages
https://jira.atlassian.com/browse/CONF-9117
- user-atlassian migration should support users created with null
passwords without SQL update workaround needed (the users created
automatically using LDAP info will have null passwords)
I followed the instructions for installing the plugin (conf 2.5.5-std) and did it via the file upload.
It was recognized and as I was configuring it, it failed to save the configuration.
We are using an oracle backend for the db and shibboleth for the sign-in methodology (similar to Gary's environment I believe).
I can see the tab in the space admin area and when I visit it, I see this error:
more atlassian-confluence.log
2007-08-21 11:09:07,447 INFO [main] [com.atlassian.confluence.lifecycle] contextInitialized Starting Confluence 2.5.5 (build #81
1)
2007-08-21 11:19:38,937 ERROR [TP-Processor3] [csum.confluence.permissionmgmt.CustomPermissionManagerAction] findAndSetGroups Fa
iled attempting to find groups
-- url: /customspacemgmt/permissions/custompermissionsmanage.action | userName<EMAIL_ADDRESS>| action: custompermissionsman
age
csum.confluence.permissionmgmt.service.exception.ServiceException: Please set User Manager Location in plugin configuration
at csum.confluence.permissionmgmt.service.CustomPermissionServiceManager.getGroupManagementService(CustomPermissionServi
ceManager.java:59)
at csum.confluence.permissionmgmt.CustomPermissionManagerAction.getGroupManagementService(CustomPermissionManagerAction.
java:1128)
at csum.confluence.permissionmgmt.CustomPermissionManagerAction.findAndSetGroups(CustomPermissionManagerAction.java:1174
)
at csum.confluence.permissionmgmt.CustomPermissionManagerAction.populateGroupsUnlessCached(CustomPermissionManagerAction
.java:239)
at csum.confluence.permissionmgmt.CustomPermissionManagerAction.populateDataUnlessCached(CustomPermissionManagerAction.j
ava:224)
at csum.confluence.permissionmgmt.CustomPermissionManagerAction.execute(CustomPermissionManagerAction.java:574)
at csum.confluence.permissionmgmt.CustomPermissionManagerAction.doDefault(CustomPermissionManagerAction.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:302)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:170)
at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.confluence.util.LoggingContextInterceptor.intercept(LoggingContextInterceptor.java:48)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.confluence.security.actions.PermissionCheckInterceptor.intercept(PermissionCheckInterceptor.java:47)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.confluence.pages.actions.PageAwareInterceptor.intercept(PageAwareInterceptor.java:114)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.confluence.spaces.actions.SpaceAwareInterceptor.intercept(SpaceAwareInterceptor.java:67)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.confluence.core.actions.LastModifiedInterceptor.intercept(LastModifiedInterceptor.java:39)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.confluence.core.ConfluenceAutowireInterceptor.intercept(ConfluenceAutowireInterceptor.java:25)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.xwork.interceptors.XWorkTransactionInterceptor.intercept(XWorkTransactionInterceptor.java:98)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActionProxy.java:115)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceAction(ServletDispatcher.java:229)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:199)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:117)
at com.atlassian.confluence.util.profiling.ProfilingPageFilter.parsePage(ProfilingPageFilter.java:137)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.core.filters.ServletContextThreadLocalFilter.doFilter(ServletContextThreadLocalFilter.java:21)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.confluence.util.LoggingContextFilter.doFilter(LoggingContextFilter.java:46)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.confluence.util.UserThreadLocalFilter.doFilter(UserThreadLocalFilter.java:44)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.seraph.filter.SecurityFilter.doFilter(SecurityFilter.java:182)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.seraph.filter.LoginFilter.doFilter(LoginFilter.java:159)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.confluence.util.ClusterHeaderFilter.doFilter(ClusterHeaderFilter.java:35)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.johnson.filters.JohnsonFilter.doFilter(JohnsonFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.springframework.orm.hibernate.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:172)
at com.atlassian.spring.filter.FlushingSpringSessionInViewFilter.doFilterInternal(FlushingSpringSessionInViewFilter.java:29)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.util.profiling.filters.ProfilingFilter.doFilter(ProfilingFilter.java:122)
at com.atlassian.core.filters.ProfilingAndErrorFilter.doFilter(ProfilingAndErrorFilter.java:27)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.confluence.util.RequestCacheThreadLocalFilter.doFilter(RequestCacheThreadLocalFilter.java:25)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.core.filters.gzip.GzipFilter.doFilter(GzipFilter.java:61)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.atlassian.core.filters.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:684)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:534)
How can I force the settings to be saved???
Thanks !
When you go to configure the plugin settings and click the update
button at the bottom, are there any messages (in red) over any of the
fields in the form? If so, the settings weren't saved. The error that
you got was due to the "User Manager Location" in the config not being
saved (the radio button where you choose Confluence or Jira user
management).
Glad to know someone else is using Shibboleth (now I don't feel so
lonely) although for the purposes of the plugin it shouldn't matter
what authenticator you use.
I
was able to get it to work finally. Looks like the only thing different
(that I can tell) is I chose to have the plugin enabled and added a
downtime message to the configuration.
I committed the changes and I finally saw them.
Thanks very much for the quick turn around on the replyto this
issue. I'll probably have questions in the future, but will
tinker around with what we have right now.
Is there a way to bulk load/create groups through SOAP/XML-RPC
calls? I'm being asked how to synchronize course 'groups' in
certain areas of the wiki and this seems like an interesting place to
hang the feature off of.
Yes
you can do that, there are also plugins that purport to do bulk upload
but they've never worked for me, I chose the 'just in time' solution of
using the ConfluenceGroupJoiningAuthenticator.
Please expand on 'synchronize' and where your users are registered.You
can use CSUM to add a list of csv list of userids, if you have
configured LDAP correctly (or not as required!) they can be pre-created
and added to a given group (space specific group). Of course,
there is nothing stopping you using that same group in another
space.... hence, what are you synchronizing?
However, what I'm really interested to know is what are planning to
try to sync (blackboard course "groups", grouper groups, etc.?). I
think that there would be enough external interest from universities
such that whatever you are thinking of might be a good idea to do as a
new plugin, and if it is something Duke University could benefit from,
I'd be happy to talk offline about helping start up another plugin for
this.
alpha-5
is on hold for now. Was planning on releasing this afternoon, but
having some difficulty integrating with the new LDAP library. Hopefully
will be available in the next few days.
ldaputil
1.0.4 fixes all known LDAP bugs, I get green lights configuring CSUM
with my atlassian-user config - Ive tested the osuser with a separate
plugin (Ill try and test osuser with csum tomorrow).
Even
though Andy ended up fixing a few more things in LDAP in the last
several days, the problems I was having with LDAP were my own (I had a
bad atlassian-user.xml usernameAttribute). Going to run through another
round of testing and release alpha-5. Thanks, Andy!
v2.0-alpha-5
released! Please let us know how it goes. LDAP stuff is much better now
(thanks, Andy!), bugs worked out of user search to show users even
after add/delete, other bugs fixed, javascript validation added
(thanks, Ren!).
Oh,
a question for you, one which I could probably look up but will ask
here instead for the benefit of all as it pertains to how the plug-in
operates:
Does a Space Admin also need to be a member of the group in order to administer the group?
No
Space Admin doesn't need to be member of a groups associated to wiki
space. We do check to make sure that given user has a Space Admin
permissions or not.
2.0-beta-1
is now available. Please use this instead of previous versions. alpha-5
had a bug in bulk-edit that kept anyone from using it. It should soon
be available via the plugin repository also (I updated it and am
awaiting the metadata at the top of this page to show it is available).
Yea.
The metadata in the page finally updated. You can now download the
plugin via the metadata at the top or possibly via
"Administration->Plugin Repository" (although the latter for me
causes the javascript alert "TypeError: exception has no properties" in
Firefox and "TypeError: undefined value" in Safari, but maybe you will
have better luck than me... waiting to hear back from support on that).
Mark, thanks and we're really glad that you like it and find it useful!
Jonathan Nolen figured out the plugin metadata issue that was
causing the "TypeError: undefined value" and "TypeError:Exception has
no properties" issues. The url in the plugin's repository metadata.xml
has some whitespace around it. When Jonathan removed it, the repository
manager picked that change up (many minutes later) and now you can also
get the plugin from the Plugin Repository. Woohoo!
Just
checking in... Has anyone had any problems, or is all going fine?
Please use the Issue Tracking link at the top now if you have any
trouble, but please feel free to comment instead if you can't get a
Jira account in short order. Thanks!
Hey
everyone... have a quick question about LDAP... Specifically, for those
of you using full LDAP integration with Confluence (for auth, groups,
etc., not just for the csum plugin), when you create groups in the CSUM
plugin, is it creating groups in LDAP? As far as I knew, LDAP was
read-only to Confluence, but maybe I understood that incorrectly.
If it is not the case that the csum plugin can already create groups
in LDAP, does everyone think it is a good idea to add an option in the
csum plugin so that it could add (bind) groups in LDAP? If so, is there
anyone that would like to get involved in the development of that
feature?
Hey
Gary, given the bind command is required to write to ldap 'find . -name
"*.java" | grep bind' over the 2.5.6 sourcecode yielded two results
relating to import/export. To me this means there is no LDAP
write support in Confluence. Someone shoot me if I get this wrong
Struggling
to get CSUM working on 2.6.0 - has anyone else seen an issue? The
plugin just fails to install 2.0 (beta2), either from the repository or
via upload and 1.1 gives a system error.
Thanks,
Paul. We're looking into this currently. There are a lot of rumblings
about 2.6.0, so I don't know that I would recommend it for production
anywhere if you need plugins to be compatible.
Custom
Space User Managment 2.0-rc-1 released (release candidate 1). Should be
available on this page and via Administration -> Plugin Repository
within hours for those using Confluence versions pre-2.6.0.
Note that both this release and the final release of csum 2.0 that is planned within a few weeks or sooner will NOT
support Confluence 2.6.0 (because building against earlier versions of
Confluence breaks the plugin in 2.6.0 for some reason). However, almost
immediately after we release csum 2.0 final, we are planning to release
the first alpha version of csum 2.1 which partially works for
Confluence 2.6.x. What I mean by "partially works" is that I got a
pre-alpha 2.1 version of the plugin to load in 2.6.0 after some
tweaking, and so far it can create groups and add/remove users, but
unfortunately it can't remove groups (at least in my dev environment)
without a system error. The painful thing there is that it appears to
be a bug in Confluence's API (the only difference was what version of
confluence I built it against), so Atlassian needs our team to help
define what is wrong, and we must rely on them for a fixed version of
2.6 if that is the case. I've logged this as: http://jira.atlassian.com/browse/CONF-9623 (the pre-alpha Confluence 2.6.0 semi-compatible version of csum plug is attached to that bug here - please ignore the fact that it is 2.0-SNAPSHOT instead of 2.1-SNAPSHOT )
I'm sure all of that will turn out ok, but for now it is a headache.
Also, I tried it again today and noticed that the 2.0-rc-1 jar is
just as runnable in 2.6.0 as the 2.1-alpha jar I was talking about, and
it was built against Confluence 2.5.3 (note: it also builds against 2.3
which is the earliest version of Confluence in repository.atlassian.com).
This makes sense, but I did have to restart Tomcat in order for it to
take (before that would get error on load). Very strange stuff. Since
it is still semi-broken in 2.6.0 though, I'm going to leave the 2.0
releases' as incompatible with anything after 2.5.7. Note: there is a
Confluence 2.5.8 coming out, so we'll need to update the metadata once
we find out what that build number will be.
Thanks
for testing it out, Sherif! Yes, you are correct. This appears to be a
bug in 2.6.0. I logged a jira ticket with Atlassian to fix and have now
asked for a workaround. Please vote on it/watch it at http://jira.atlassian.com/browse/CONF-9623
Atlassian has been rather responsive the last few days so I know
they are working hard to resolve issues like this. I would strongly
suggest testing out things in 2.6.0 to make sure any other plugins you
rely on also work and letting the plugin authors know if they don't.
There were significant changes in 2.6.0 and from talking with David
Peterson it seems like the norm over the last several releases is for
plugin authors to stop supporting older versions when major changes
come out like this.
Also - a quick update on csum 2.0 final release: we wanted to get
this release out right away, but ran into some issues that Andy is
working hard to fix. I think we're hoping that will be resolved and
we'll have the final release done within a week or two. It is possible
that once Atlassian figures out their delete group bug that the 2.0
final release will work in Confluence 2.6.1+ as well (but don't quote
me on that).
If you have time to add a bug in our issue tracking system, that
might be best since you could attach more description of the error and
perhaps some debug log there: http://developer.atlassian.com/jira/browse/SUSR
Without any more information, I'm not sure what to say. We started
developing v2.0 of the csum plugin against 2.5.4 originally and as far
as I remember removing groups worked then, but I haven't personally
tested recent versions of the csum plugin against Confluence 2.5.4.
Something I always have wondered about is whether someone who has
integrated Confluence with LDAP for groups (or integrated with some
other read-only system-of-record for groups) might have problems with
group addition and deletion in csum. If that is the case here, there is
an option in the csum config that lets you turn off group add/remove
functionality as a temporary workaround, and perhaps at some point if
someone was interested they might add the functionality into the csum
plugin to be able to add/remove those groups if possible.
Custom
User Management Plugin v.2.0-rc-2 released and submitted to Plugin
Repository (I have no idea when it will be updated in plugin
repository, because for some reason the last release didn't take
either- will email Jonathan about that).
Fixes:
SUSR-40 - Adding Atlassian-proposed workaround for Velocity bug that made null email show up as last non-null email in user list
SUSR-60 - Updated to ldaputil 1.0.9 which fixed some bug Cisco was having with LDAP
Gary,Thanks for getting this version out so quick!
Tested on mine and it fixed one main issue I was having - If a group
was already assigned to the space, and I clicked 'manage users' tab -
it didnt pickup there were any groups there. This seems resolved now
-thanks. (I still can't delete a group - But Im that wasnt fixed in
this version was it)
Actually I think what you saw there was a result of us caching the
groups in the session, but I'm not sure. There is nothing that should
have changed around which groups it recognizes as belonging to the
space. The main things to do if you have problems with groups not
showing up that you think should show up are:
Click 'refresh' link towards bottom of page when in the Manage Users/Groups tab (in browse space)
If
that didn't work, make sure that the names of the groups you think
should show up in the list match the naming pattern defined in the
plugin configuration and that those groups have "view space" permission to the space you are administering.
We still don't have a fix for the removeGroup bug that shows up in 2.6.0 when using the csum plugin.
For anyone who wants the Custom Space User Management plugin to work
in Confluence 2.6.x (I assume everyone does), please vote for http://jira.atlassian.com/browse/CONF-9623
so maybe it will get some traction. I'd love for it to turn out to be
something that we can fix in the plugin, but it is suspicious to me
that it works in 2.5.x (which exception of Anne Marie's experience with
it) and not in 2.6.0.
Ok, I'm hoping everyone else is excited as I am about this... 2.0-rc-3 is available!. This version not only adds support for Confluence 2.6.0
(so you don't have to wait for 2.1!) via some workarounds for bugs in
2.6.0 that the guys at Atlassian helped nail down, but it also provides
a fix to support Confluence 2.3.
The following modifications have been made since v2.0-rc-2:
SUSR-61 - Now works with Confluence 2.6.0. See http://developer.atlassian.com/jira/browse/SUSR-61
for additional instructions if you have trouble uninstalling previous
version due to a Confluence bug (may require restart of application
server(s)). csum 2.0-rc-3 includes workaround for CONF-9623 remove
group bug in Confluence API introduced in Confluence 2.6.0. Note that
2.0-rc-2 fixed issues with 2.6.0 described in CONF-9605.
SUSR-63
- Added support for Confluence 2.3.x (re-added actionmessages.vm
implementation that had been absent since early alpha releases)
SUSR-66
- Bulk actions javascript validation fixed. Javascript validation color
changed to light red to match Confluence default theme.
Feel free to rain on my parade, but I am totally psyched about this!
Has been updated in the plugin repository metadata, so within a day
or so should be available via Plugin Repository (where all good boys
and girls go to get their plugins).
Yep, As Gary mentioned we are all excited about it.
Few things to add on ....
1. 2.0-rc2 has been tested with user management delegated to Jira.
One issue as mentioned by Gary, is group creation works, only it takes
time to appear on Confluence side.
2. We are working on doing some more stress testing with larger user
base to make sure that CSUM works pretty well in those cases too.
I'm
testing out 2.0-rc3 and am a little confused on the group matching.
With the 1.1 version of the plugin, I had been doing pattern matching
such as this: (.?)SPACEKEY(.) so that I could create groups such as: SUFFIX-SPACEKEY-FOO and SUFFIX-SPACEKEY-BAR
Am I correct in understand that all pattern matching has been
removed from the Group Matching? Would the implication be that the
dynamic suffixes that I'd been able to use before are no longer
plausible since it appears as though there can be only one suffix
defined?
The functionality you need is still there. Instead of using regular
expressions, you just specify the prefix/suffix (both optional) in the
plugin configuration setting: "Group Matching/New Group Name Creation
Pattern". The prefix and/or suffix can still contain the dynamic
"SPACEKEY". If I understand you correctly, you were just using the csum
v1.1 plugin to manage groups with names like "SUFFIX-SPACEKEY-FOO" and
"SUFFIX-SPACEKEY-BAR", right? So, what you'd do now is to specify the
left textfield of "Group Matching/New Group Name Creation Pattern" to
be (without the quotes) "SUFFIX-SPACEKEY" and then leave the suffix
field blank. Then it will work exactly as it had before.
The reason we did this was that you can't easily use a regular
expression to create new group valid group names that match it.
(Regular expressions are quite powerful, so it was unreasonable to try
to take a regular expression pattern and a partial name given by the
user and then create a valid groupname that not only matched the
regular expression, but matched the intent of the regular expression.)
When we added the group add functionality, we tried keeping both the
regular expression for matching and added the prefix/suffix for group
name creation, but that was really confusing to users, because your
regular expression and group prefix/suffix had to match (even when we
validated this in configuration, it was confusing to users- it just
wasn't very intuitive). So we ended up determining that for 99.9%
(perhaps 100%) of all cases, people probably didn't use regular
expressions in such a way that the prefix/suffix with dynamic SPACEKEY
in either/both way of handling group name matching and group name
creation wouldn't handle, so we dropped the regex and replaced it with
just the group prefix/suffix with dynamic SPACEKEY in either/both.
Hope this makes sense. I was really hoping that this wouldn't affect
anyone and that everyone could easily make the migration to the v2.0
way of doing things, which seems like it might work for you per your
example.
Hi
Gary, I'm trying this plug in right now and having the same question as
Scott. what I want to be able to do is the following:
- I have a user group that wanted to create 4 different spaces.
- they want to be able to create their own groups but SHARED amongst the 4 spaces.
- this means, they want to create a particular group only one time and be able to use it for all 4 spaces.
Is this possible to do with this plug in? if so, how
would I specify the "Group Matching/New Group Name Creation
Pattern"? When I tried what you suggested, it only allow me to
use 1 suffix and it's fixed. So, I ended up have
names like SUFFIX1-SPACEKEY1-XXX, SUFFIX1-SPACEKEY1-YYY. and
since the spacekey is dynamic, the group I created in 1 space can not
be found in another space.
* In the plugin config, specify a prefix and/or suffix that doesn't
contain SPACEKEY, for example you could possibly specify the prefix as
"grp-" (you could also try not specifying a prefix or suffix- but I
think that will allow them to manage confluence-administrators and
confluence-users, which you probably don't want). This will allow all
space admins to manage all space groups (which would be groups that
have the prefix and/or suffix you specified). This may or may not be
appropriate depending on your organization.
* You could just manage this group manually via creating it in
Administration -> Manage Groups -> Add Group then add the users,
add the users to the group, and give that group permissions to each
space in Browse Space -> Space Admin -> Permissions. This won't
allow the space admins to manage that group on their own, but if this
is a "one-off" situation, it might be best.
If that doesn't work for you, please let us know exactly how you
need it to work (from what you would specify in config to how things
would be done in the UI) and either add an enhancement request to Jira
(see Issue Management link at the top of the page) for exactly what you
are looking for or post it here and I will create a ticket in the CSUM
Jira. Then if you or anyone else would like to contribute that
functionality to the plugin, they are more than welcome, or we might
have resources to take on that development at some point in the future.
Guy,
I am using Theme Builder 2.0.9 and I am having the same problem as
Andy. I see on the adaptavist site that a different version of
the menulink is given and that is not working either.
The csum plugin works fine with the basic confluence themes in 2.6
If you can create/remove groups within Confluence Administration -> Manage Groups then you should be able to
create/remove groups within the C.S.U.M. plugin.
If
you are using Jira for external user management and configure the
C.S.U.M. plugin to use the Jira remote SOAP service, then the C.S.U.M.
plugin should be able to manage those users.
If Confluence
relies on LDAP for user authentication, then you can configure the
C.S.U.M. plugin to create users in the Confluence database by
attempting to add them to a group if you have configured the C.S.U.M.
plugin for LDAP.
That said, unless someone else speaks up, I can't confirm personally
that it will or won't work until you try it. Please try manually
creating/removing groups in Confluence Administration -> Manage
Groups and if that works, then try installing the C.S.U.M. plugin and
letting us know if you have any trouble.
Will be very interested to hear from you whether this works!
I
seem to be having problems with the plug-in when I am using
Crowd. First off, when I go to configure the plug-in, I have to
choose Confluence for the user management even though it is really
Crowd. Under Auto-provision users using LDAP info, if I choose
yes (which I want to), it wants to look in either the osuser.xml or
atlassian-user.xml for LDAP info. Using Crowd, I do not user
osuser.xml and I do not use the LDAP section of Atlassian-user (it is
commented out). With that said, I check "No" on this
option to complete the configuration. When I go to
create/add a group to a space, it allows me to create the group but
will not add any users - I actually get an error on the page when I try
to add users.
Create an issue and the error displayed in the UI and associated debug logs (see above) to that ticket
If you can do that, let me know about it and I can take on this issue (and take it on with Atlassian if necessary).
I apologize for the plugin configuration saying "Confluence" and not
mentioning "Crowd". What it means by using Confluence for user
management, is that it uses the Confluence API to add/remove groups
(and add users if you use the LDAP config piece of the plugin). If we
can help you get it working with Crowd, we'll definitely put some
information about that in the plugin config to make it more obvious how
those using Crowd can configure the plugin. If you have any suggestions
for wording/questions that might make it more obvious how to configure
it, please let us know.
I also apologize for the plugin looking in osuser.xml or
atlassian-user.xml for LDAP info. This was per request from our users,
but possibly we should have also included the ability to optionally
configure LDAP in the plugin itself as a 3rd option. If you or any one
else thinks that would be a good enhancement, let us know and possibly
we can add it in as a new feature. If you'd rather the plugin gather
LDAP information from some other source, please let us know how you
would propose the plugin could do that and we'll definitely consider it.
Everyone is also welcome to login to http://developer.atlassian.com/jira/browse/SUSR
and create enhancement requests or register what does and doesn't work
in the plugin. If you'd like to contribute to the plugin we'd like to
hear that as well. I've been a little busier lately so it would be good
to have some more help.
If you happened to have added a support ticket for Atlassian for
this plugin, they will unfortunately not help you. That's not to say
that Atlassian doesn't recommend customers to use our plugin. In fact,
Atlassian's David Soul recommended it for use by customers here: CONF-5302. It's just that Atlassian itself doesn't provide support for this plugin.
(Note: Atlassian does however provide us with free source control,
issue tracking, and wiki documentation hosting, as well as the best
customer service I've ever had!)
Raju, Andy, Ren and I are the volunteer dev team at the moment, and since we work out of the queue in http://developer.atlassian.com/jira/browse/SUSR , that is the best place to add tickets. Thanks in advance for your help!
There appears to be something in the integration between confluence
and crowd that is keeping it from being able to add group memberships:
2007-11-19 08:05:03,599 FATAL [http-80-Processor2] [service.soap.client.SecurityServerClient] addPrincipalToGroup Unable to connect to the crowd server: null :Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Could not receive fault.. Nested exception is org.codehaus.xfire.fault.XFireFault: No write method for property {http://rmi.java}cause in class java.rmi.RemoteException
-- url: /customspacemgmt/permissions/docustompermissionsmanage.action | userName: ... | action: docustompermissionsmanage
org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Could not receive fault.. Nested exception is org.codehaus.xfire.fault.XFireFault: No write method for property {http://rmi.java}cause in class java.rmi.RemoteException
org.codehaus.xfire.fault.XFireFault: Could not receive fault.. Nested exception is org.codehaus.xfire.fault.XFireFault: No write method for property {http://rmi.java}cause in class java.rmi.RemoteException
at org.codehaus.xfire.fault.XFireFault.createFault(XFireFault.java:89)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
at org.codehaus.xfire.client.Client.invoke(Client.java:335)
at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
at $Proxy43.addPrincipalToGroup(Unknown Source)
at com.atlassian.crowd.integration.service.soap.client.SecurityServerClient.addPrincipalToGroup(SecurityServerClient.java:462)
at com.atlassian.crowd.integration.atlassianuser.CrowdGroupManager.addMembership(CrowdGroupManager.java:340)
at com.atlassian.user.impl.delegation.DelegatingGroupManagerTemplate.addMembership(DelegatingGroupManagerTemplate.java:188)
at bucket.user.DefaultUserAccessor.addMembership(DefaultUserAccessor.java:505)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:287)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:181)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:148)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)
at $Proxy19.addMembership(Unknown Source)
I would have thought that Confluence would have integrated with
Crowd such that it could add/remove groups, add/remove group
memberships, and add/remove users. I'll open up a support ticket to
find out why that doesn't work and have them cc: you on that ticket.
The main problem right now is that we're trying to lock down csum
2.0 for a final release, and adding crowd support would disrupt that.
So... I think the right thing to do may be to go ahead and finalize
csum 2.0, and then add Crowd support and release it as 2.1-alpha-1 so
that you can give it a try (it wouldn't be a major architectural change
as the user/group piece is fairly modular and the crowd integration
should be almost exactly like the Jira SOAP service integration that it
already contains).
Note to all... the csum final release is going to add a "csum."
prefix to all of the i18n message keys. Sorry about that... I didn't
realize that Confluence shared the "i18n" resource across all plugins
(there is very little sandboxing unfortunately) and the old keys were
not unique enough and I noticed conflicts with other plugin projects of
mine.
Justen Stepka - Nov 20, 2007 20:37 - "Through the plugins API you
can use the user API as usual which will attempt to push changes
through Crowd to whatever directory store is being used."
When Confluence is integrated with Crowd, the Custom Space User
Management plugin (which uses UserAccessor in the Confluence API)
should be able to add/remove groups, add/remove group memberships, and
add/remove users if those same functions would work in Crowd itself
(i.e. as long as Crowd has rights to do those things and Confluence is
correctly configured to use Crowd and there are no
bugs/incompatibilities between the versions of Confluence and Crowd
that you are using).
This means that the Custom Space User Management plugin should in theory support Crowd integration with Confluence.
I'm assuming that it is either the case that Crowd itself is not
able to add group memberships into Active Directory in your case
because of some configuration issue with Active Directory, Crowd,
and/or Confluence, or this is a bug in some version of those that you
are using that you'd need to take up with Atlassian.
If you want to get the C.S.U.M. plugin working with Confluence and
Crowd at this point, the way I'd suggest doing it is to do the
following:
In Confluence, go to Administration -> Manage Groups and try to add a user to a group
From what Justen said, and from looking at your logs, I'm guessing that this will fail
Open
up a support ticket with support.atlassian.com and attach your logs to
the ticket, and tell them specifically what you did to produce that
problem (and try it again so you can say that the problem is
reproducible)
You shouldn't mention the C.S.U.M. plugin
because it has nothing to do with the problem. If you do mention it,
the support person will likely say that it is a 3rd-party plugin and
they only support plugins that Atlassian has written, so that's why I
would say don't mention it.
Whether it is a configuration issue or a bug, Atlassian should be able to help you with this problem
If that is not the case, and this issue only affects the C.S.U.M.
plugin (for reasons I can't imagine), then let us know. Either way,
please comment back on this page with whether you were able to get it
to work or not. We'd love to have a user of the plugin that got it to
work successfully with Crowd. I know others will likely be planning to
use it with Crowd soon, so it'd be great for them to know how your
issues were resolved.
Thanks and happy Thanksgiving! (for those in the states)
I don't think that you will be able to easily get this plug-in to
work with Crowd. The way Crowd works today is it does not allow
you to add an Active Directory user to a non-active directory
group. So, you cannot do this in Crowd without the plug-in.
So here is what I understand (tell me if I'm wrong):
The issue you are having with the plugin stems from a problem
between Crowd and Active Directory (Crowd does not allow you to add an
Active Directory user to a non-active directory group).
The
CSUM plugin should be able to work just fine with Crowd (itself) as it
currently stands. I say this because Atlassian's Justen Stepka
said,"Through the plugins API you can use the user API as usual which
will attempt to push changes through Crowd to whatever directory store
is being used."
We would like to help, but I'm not sure what else we can do. Your
testing definitely helped, and we look forward to hearing back from you
at some point if you find a solution to this problem.
If you can, please comment on that issue. If you can't comment on
that issue then please contact Atlassian
<EMAIL_ADDRESS>and let them know that you need to be
added to that ticket so you can respond.
This is a great plugin and is exactly what we are after at the moment. Thanks.
Just a general query, we are looking to upgrade to Confluence 2.7
and was wondering when you predict 2.7 support will be available for
this plugin? We've installed it on a test environment and although it
seems to work, users added to the space groups seem to get
automatically removed/reverted after the initial addition.
We haven't got time yet to test CSUM plugin against Confluence 2.7
Have you tried to use this plugin along with Confluence 2.6 or any
previous version. May be the bug you mentioned is already existing.
When you create the bug in the CSUM plugin's Jira instance ( http://developer.atlassian.com/jira/browse/SUSR
) make sure you let us know how you have the plugin configured and as
much other information you can provide about your environment (whether
you are using regular (osuser) schema or atlassian-user, whether you
are using LDAP/Jira/Confluence/Crowd, etc. and versions of each - all
of that will help us out a lot more). Another question:
After adding/removing a user...
If you do a refresh of the browser does it show up?
If you click the refresh link at the bottom of the CSUM (Manage Users/Groups) tab, does the user show up?
If you close and restart the browser does the user show up?
SUSR-67 - Made i18n keys unique to plugin so i18n messages
will be less likely to conflict with other plugins (although Confluence
should really sandbox them if possible)
i18n is broken after commit for SUSR-67 (fixed by Igor Minar)
Yahoo
js library that is used in the plugin seems to be buggy (or incorrectly
used?) and this breaks delete group functionality for IE users (fixed
by Igor Minar)
Gary
- awesome work! We had an issue with deleting groups using Internet
explorer, using the old version (kept getting a stack-trace error). But
that seems to have also fixed itself. I presume that was the third
point you raised above (the Fix for the Yahoo js Libary).
Also performance has improved! Thanks a lot from your friends here at Optus!
It
seems there should be a way for a "space admin" to create users for
that space. We have many spaces and the owner of a space wants the
ability to add new users to the space without going to the confluence
admin. The Custom Space User Management Plugin
([http://confluence.atlassian.com/display/CONFEXT/Custom+Space+User+Management+Plugin])
is close but only allows you to add existing users (already in
confluence or in LDAP to a group).  Any ideas?
I think this is a good idea, but I think it would require a
significant change to the user interface if you wanted to also set the
full name and email of the user when the user is added.
If you would submit a ticket in the csum jira (issue management link
at the top of page) that would be helpful. Otherwise, just reply and
I'll add the ticket into the system.
Please indicate whether you'd like new users to be added via a list
of usernames only (like the current interface) or if you'd rather be
able to enter each user one at a time. If you only enter a list of
usernames, user addition would be faster, but users (or administrators)
would have to go back and set their full name and email. If you want to
enter each user with username, full name, and email by hand, then the
interface would have to be changed probably so that those three fields
appeared over the group list and you would only be able to add one at a
time. Some might want a csv or excel upload for such a purpose, but
those are usually not a really good idea because less able users may
put the username, full name, and email into the wrong columns and
really hose things up when they import.
Also my team (at Duke) doesn't have a lot of time at the moment to
work on this (although maybe someone else on the CSUM dev team could
help). However, I'd like to understand this need so we can get this
enhancement request on the to-do list, and I think it is a good idea as
an optional configurable feature.
We also welcome developers that would like to contribute.
Space admin can create a new user, enter the new user Name,
Email, and password (not necessary be able to edit or reset this info)
Add them to group as the currently can with this plugin
A new user would be added to the Confluence-users group on creation.
After
creation, the space admin would get a confirmation that the new user
has been created, please send them an email with the following info:
(show the actual info for them to copy paste into an email)
Space URL
username
password
"This plugin can be used only if Wiki user management is delegated to Confluence."
Showstopper for us. Drats! We use LDAP for user management. Any chance you'll support this in the future?
Hi Peter,
Right now this plugin works with user management delegated within in Confluence or Jira.
The only reason I couldn't able to develop it for LDAP User management is I don't have setup for testing it.
If you have any idea how can I do local LDAP setup; will appericiate and test it for the same.
-
Rajendra
Hi Peter,
You should be able to use this plugin (with LDAP for user management). Just select the Conflunece as user management tool (during configuration.)
I have confirmed with Atlassian Team Member and it should work fine.
Let me know how it goes.
thanks,
Rajendra
I tried to get it but no go. Two issues:
1. Using the Builder theme, I can't actually browse to the User Management tool. If I change the theme to "Left" then I can see it under browse.
2. Going to it I get this message: "You can not manage user-groups associated with this wiki space. Please check with Confluence Administrators."
Suggestions?
Thinking on the #1 issue, perhaps it could be added to the same screen where Permissions is listed, i.e. the Space Administration tab?
1. Since we don't have builder theme, I can't comment on that. But I have seen using standard theme and left navigation, it appears under "Browse Space".
2. This is configuration issue.
By default, Plugin allows only user groups that follow this naming convention SPACEKEY-.+ so if your wiki spacekey is TEST, then it will only show any groups starting with name TEST- like TEST-users or TEST-admins etc.
This is done to restrict, Space Administrators to manage users for their wiki space. Else they can update any user-groups which can be security hole.
To test the things; you can configure Usergroups usage pattern as .*
Let me know how it goes.
Rajendra
Hi,
With regards to use with Builder theme, we added extended support for this plugin in Builder 2.0.8. Just add a new link to your menu (eg. Edit > Administration menu) for the user management as follows:
That will then show the link in the menu. You can of course add the link to any of the menus, or indeed anywhere else in the theme layout. If using it outside a menu, add the flat=true param to the menuitem macro.
Guy
http://www.openldap.org/ would be your best solution.
yep ... just found it now!
Will do setup and see how things go.
cheers,
Rajendra
Thanks Rajendra for replying to my comments,
First I made a couple of mistake using the plugin but everything's ok now.
That's awesome because I had been searching for this kind of plugin for a long while. There is only one stuff that could be great about group management : the ability to browse the group itself. Is it something coming soon in a new plgun's release?
David
Hi David,
Do you mean that you would like to know who are all users for given user-group ?
If that's the question then yes, I'm planning to add feature that very soon as I get time.
Rajendra
Hi Rajendra,
Yep, that was the question. I also found a pretty useful macro :
I got another customer request that could be interesting too. A lot of space admins are interested in getting the same user permission feature within group management. It might be a simple link to user permissions.
Thanks,
David
David,
Funny, we just implemented this as a workaround and I was coming here to post it. Great minds and all that!
Anyway, Rajendra, perhaps leveraging this existing macro is the way to go.
Peter
Peter / David,
User Groups can be browsed using this plugin.
Let me know if you have any difficulties.
thanks,
Rajendra
I tried this but when we click "View Users" an empty window pops up. I dropped it back to the original version for now, perhaps I missed something in installation.
Weird though...
You just need to update existing jar with latest one.
Hi Rajendra,
I've just tried the "users view" features/link in the plugin. Cool, that's what I needed.
Thanks,
David
There seems to exist a bug with this plugin and LDAP user management:
Basically it works fine. However, if I try to add multiple users a "space group" at once, I get the error message that one or more users do not exist (eg. for test1, test2):
* Some of the Users may not have been added to System.
Either following are invalid userids Or there is some issue with LDAP configuration.
Please verify with Confluence Administrator.
* List of not added Userids: test1, test2
Add test1 and test2 in two separate steps works fine.
Hi Michael,
When I developed this plugin, I couldn't able to test with user management delegated to LDAP. (Is that the way you folks are using?) as such setup is not available to me.
If you are able to add one user at a time, then adding multiple users should work too.
So just few questions to get more details:
1) Are you using the latest version of this plugin (it's also available through Repository Client!)
2) Can you please tell describe following settings for this plugin:
a) What's the value/setting for "User Manager Location:"
b) Are you using LDAP for User Authentication?:
regards,
Rajendra
Hi,
yes, I am using the latest version of the plugin (and Confluence 2.2.9).
Andy yes, I am using LDAP authentication. The user manager location is set to Confluence.
Hmm... that's bit strange then.
I can't think of any which should not allow to work.
If you have handson on code development, I can recommend turing on log and go through exceptions thrown. Else If it's possible (and ok?) may be I would like to see things live in action.
-
r
Having some trouble here. Hopefully I'm remembering this sequence of events properly.
For a space, I was experimenting with creating the groups that would be managed by space admins for my space and I seem to have hosed the permissions for that space completely . The space's key is DCP. I created the group dcp-user and gave it permissions in the space. when I looked as a space admin, however, the groups did not show up. So, I thought it might be case sensitive and went to the Adminstration console to delete dcp-user and add DCP-user.
If I try and delete the groups from the administration console, or edit the permissions for the space in question, or click on its Manage Users tab, I get this error (whether the plugin is enabled or not):
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:309)
at net.sf.hibernate.collection.PersistentCollection.initialize(PersistentCollection.java:201)
at net.sf.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:38)
Stack Trace: [hide]org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getGroupSpacePermissionsForSpace' in class com.atlassian.confluence.user.actions.RemoveGroupAction threw exception class net.sf.hibernate.LazyInitializationException : Failed to lazily initialize a collection
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:309).....
Can you help?
Updated by Jonathan Nolen
Aug 14, 2007 17:34
Hey Emily,
1. Yes group names are case sensitive that might be the reason, it didn't appear in "Manage Users" tab. By default only groups that will be displayed are of pattern SPACEKEY-.*
2. Regarding exceptions ... if you see the exception
caused by: net.sf.hibernate.UnresolvableObjectException: No row with the given identifier exists: 2747, of class: com.atlassian.confluence.security.SpacePermission
at net.sf.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:38)
It seems to be error thrown at SpacePermission.java.
3. Also one suggestion may be: you can try to play with other wiki space and add/associate user group with it.
Does that helps ?
-
Rajendra
Hey that fixed it! Thank you so so much!
We are using Confluence 2.3.1 and Jira 3.7.2 with user management is delegated to Jira. I have followed all the installation instructions but could not get the plugin to work.
It seems like many plugins "broke" when Jira 3.7 came out so I was wondering if this was one of them.
Hi Dennis,
I haven't tested this plugin with Confluence 2.3 and Jira 3.7.2 combination!
Currently we are using it with Confluence 2.2.4 and Jira 3.6.5 without any issue. Will look into it very soon!
regards,
Rajendra
This plug-in is working in an LDAP configuration on Confluence 2.4.5, except that the users are not being added automatically to the "confluence-users" group (only the selected space group.) The plug-in configuration setting for LDAP is set to YES. Suggestions?
Regards,
Bob
Hi Bob,
Sorry for late reply.
Yes plugin should be able to add user to confluence-users. If possible can you please explain me the detailed steps so that I can simulate situation where it's not adding.
thanks,
Rajendra
Are there any issues depolying this plugin in a clustered environment? (Wiki installed on 2 nodes)
Subir,
I myself has not tested in clustered environment as I don't have that setup.
My guess is it should be able to work. But best would be test it before you start working.
regards,
Rajendra
If I have an issue, I'll update this page.
Thanks,
Subir.
Hi Sherif,
Thanks for the feedback.
Right now I'm working with great folks from Duke University to extend this plugin (like delegating functionality of creating new user groups).
Issue here is, & a special character that being used as separator for parameter=value pairs. So in case selectedGroupName=d&d-users, selectedGroupName=d is one name value pair and other is d-users parameter.
We will see if encoding parameters can resolve this issue. Till then I guess it's best to avoid special characters in user group naming.
cheers,
Rajendra
This looks great and exactly what I need to delegate Space related group management. But. I have an LDAP directory that requires authentication to access. The rev 1.1 plugin does not allow the specifying of a bind user.
Related: why specify LDAP stuff anyway, its already in the osuser.xml file? I wrote some code to pull it out for the Confluence NTLM authenticator, perhaps that could be used to solve both issues? I'll have a hack anyway.
Cheers,
andy
I had trouble building the plugin with a general compile error (mvn 2.0.5 / sun150) , but after adding:
In the plugins section of pom.xml the build went ahead and I got my jar. Ive just integrated the LDAP code and am going to test.
Updated by Andy Brook
Jul 02, 2007 11:08
On deployment I had a problem with multiple commons-logging api's found. ? Not sure why the plugin got bundled with all the supporting JAR's (I'm a newb at confluence plugins), removing all the JAR's solved that problem but then after successful upload, trying to configure it got:
I had to search/replace "configure-usermgmt.vm" for "configure-plugin.vm"
Also, search/replace " actionmessages.vm" for "action-messages.vm"
That fixed it. But the Edit then broke. Im thinking trunk is in major flux right now. Any ideas when its going to be stable?
Hi Andy,
Right now we are working on few things like making this plugin:
Nice folks from Duke University are helping on adding this features. Hence source may not be stable then. Hopefully we will fix it soon.
Regarding LDAP parameter additions. Yes if we can get the details from osuser.xml that would be great. I will see how we can integrate. If you have any easy way to do it let's know.
cheers,
Rajendra
Updated by Subir Sud
Jul 23, 2007 17:44
Hi Rajendra,
The ability to create user groups associated with the space, by the space admin, would be very helpful. Do you have an ETA on this?
Thanks,
Subir.
We should have a release sometime towards the end of this month (July 2007).
v2.0 of the plugin has been developed by a few of us at Duke University and built upon Rajendra's work.
The current version (pre-v2.0) is currently available at http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/trunk/. Please note that trunk may be unstable, as there is still some work left to do on it. We will tag it and release it via this page and submit it to the central plugin repository sometime before the end of the month.
The only supported build available for the plugin is Maven 2 can be found in the README in the trunk dir. The Maven 1 build in trunk will be removed in the next few weeks. (Originally was going to keep it but there is no reason to.)
If used with normal "Confluence" user/group management option, the primary outstanding bug in the plugin is one that keeps the page from refreshing after a user is removed from a group. I'm looking into that currently. It has been tested with thousands of users in the Confluence database and uses Atlassian's PagerPaginationSupport and Pager classes to handle a lot of data reasonably well.
The "JIRA" user/group management option has not been tested since v1.1 and has been transitioned for now to a hybrid of using JIRA SOAP service for user/group management with the exception of using a JNDI datasource to read (list) groups from the JIRA database, since that functionality was not available in the SOAP service.
The code needs a lot of cleanup and needs some tests. We also need to remove Duke-specific references and move messages into i18n properties. We also want to change the directory structure to be a "normal" maven 2 layout. We will be updating a lot of it over the next week.
Also note, I would try it in a test environment before putting it into production. The configuration has changed so if you deploy it into an environment where v1.x was deployed, the plugin will not work until you update the configuration (but doing that should be straightforward because it is self-documenting).
We have a fairly large site with some 1000 users. This plugin is becoming the corner-stone of our effort to decentralize the user provisioning process.
Thanks for the effort.
It would extend the possible userbase of this plugin if the configuration allowed an LDAP user and password to be set against the following keys in the environment used to create the InitialContext:
user: Context.SECURITY_PRINCIPAL
pass: Context.SECURITY_CREDENTIALS
Without this, the plugin cannot be used on LDAP servers that disallow anonymous access.
Completely agree with this. We're about to turn off anonymous access to our LDAP servers for security purposes and I've got 100s of groups that are going to be dead in the water. Ouch!
I wonder, couldn't it be set to use the LDAP info already available in the atlassian-user.xml file?
Hi Peter,
In the past, Andy has given two classes which can be used to get the LDAP information from osuser.xml. I have to take closer look at it though.
Right now this plugin is getting major changes in whole UI and functionality. Alpa release should be available next week. Once we get stable release out, will start working in this direction.
thanks a lot for your interest in this plugin.
cheers,
Rajendra
Rajendra,
Thanks for the reply. We're really looking forward to the new functionality.
As for the anonymous LDAP piece, I've just been advised that anonymous LDAP access will be turned off in two weeks. Let me know if you'd like me to get one of my developers to give you a hand on updating that piece.
Peter
Hi,
The latest release is v1.1, but when I check the source out an build it I get a .2.0 jar ... are there any major changes between the two versions?
–
Dan Hardiker
Adaptavist.com Ltd
Yes, some pretty big changes in v2.0. Basically the changes are:
However, we ran into a few issues that we're still fixing. If we hadn't just gone live with it and had a bunch of clustering issues separate from the plugin, it would have been available by now.
Things left to do before alpha release:
Things that we need help from others in testing (mostly because we don't have time at the moment):
I will do my best to fit in the stuff around making LDAP support authentication, and the info you supplied takes me 95% of the way there (I just don't know how to get info from osuser.xml easily via the API yet, so I may just add that into config for now)
Ren, could you talk a little about the UI changes?
Form a UI standpoint we've split the the UI in to a basic (primary interface) and advanced (bulk editing). Here are a few of the features worth highlighting:
I can test the LDAP authentication piece for you.
Hi Peter,
As Gary mentioned, Alpha release is going to be available very soon. We need guys who can test the plugin in their environment. I myself will be testing the functionality over the weekend.
I hope we should be able to get things done before your two week deadline.
FYI: Any issues, bugs related to this plugin need to file here:
http://developer.atlassian.com/jira/browse/SUSR
cheers,
Rajendra
Right now the outstanding bugs with v2.0 in trunk are:
Am working on those this afternoon and will get a link to the jar posted to this page once completed. Note again that LDAP and JIRA functionality haven't been tested. We'll do our best to get the username,password configuration (optionally) into config for LDAP.
Rajendra has his environment ready to test JIRA (and maybe LDAP?) I think, so maybe he can tell me whether that is working fine or not. Anyone who wishes to test would be great. I'll go ahead and put a new project version into JIRA link above so you can write bugs against it.
Finally, please note that even though the v2.0 plugin may be exactly what you need, don't place your job security on it. I had to spend a good bit of time exploring poorly documented parts of the API and getting the paging and user-atlassian part of Confluence 2.5.4 API to behave and to work around bugs in it. Because of this, testing has mostly consisted of trial and error. Ren and I did have it working previously though with more than 45,000 users without it being slow (with exception of search which is unusably slow with that many users but that is optional in config and we're hoping that is because we haven't done the user/group schema upgrade to get off of the open symphony stuff as Atlassian suggested).
Will comment further as make progress. You are welcome to build trunk if you want to see where we are. See README for details on building.
Updated by Jonathan Nolen
Aug 14, 2007 17:33
(sigh of relief)
v2.0-alpha is now available at http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/releases/permission-management-2.0-alpha-1.jar
source is at:
http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/tags/2.0-alpha-1/
Bugs we knew of in the plugin have been fixed (but we still haven't tested with ldap and jira so if you can please test that too and let us know what happens).
Ren and I however noticed a new bug in confluence massive 2.5.4 that happens when multiple nodes in a cluster are doing group management at once:
org.springframework.orm.hibernate.HibernateSystemException: a different object with the same identifier value was already associated with the session: 46, of class: com.opensymphony.user.provider.hibernate.impl.HibernateGroupImpl; nested exception is net.sf.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: 46, of class: com.opensymphony.user.provider.hibernate.impl.HibernateGroupImpl
net.sf.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: 46, of class: com.opensymphony.user.provider.hibernate.impl.HibernateGroupImpl
at net.sf.hibernate.impl.SessionImpl.doSave(SessionImpl.java:852)
at net.sf.hibernate.impl.SessionImpl.saveWithGeneratedIdentifier(SessionImpl.java:790)
at net.sf.hibernate.impl.SessionImpl.save(SessionImpl.java:749)
at org.springframework.orm.hibernate.HibernateTemplate$12.doInHibernate(HibernateTemplate.java:492)
at org.springframework.orm.hibernate.HibernateTemplate.execute(HibernateTemplate.java:312)
at org.springframework.orm.hibernate.HibernateTemplate.save(HibernateTemplate.java:489)
at bucket.user.persistence.dao.hibernate.BucketGroupDAO.saveGroup(BucketGroupDAO.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:284)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:155)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:122)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
at $Proxy5.saveGroup(Unknown Source)
at com.opensymphony.user.provider.hibernate.HibernateAccessProvider.create(HibernateAccessProvider.java:52)
at bucket.user.providers.ChainedUserProvider.create(ChainedUserProvider.java:115)
at bucket.user.providers.CachingAccessProvider.create(CachingAccessProvider.java:81)
at com.atlassian.user.impl.osuser.OSUGroupManager.createGroup(OSUGroupManager.java:89)
at com.atlassian.user.impl.delegation.DelegatingListGroupManager.createGroup(DelegatingListGroupManager.java:162)
at bucket.user.DefaultUserAccessor.addGroup(DefaultUserAccessor.java:188)
at com.atlassian.confluence.user.DefaultUserAccessor.addGroup(DefaultUserAccessor.java:81)
have submitted that as support issue and will let you know status. Please test the plugin out though.
Updated by Jonathan Nolen
Aug 14, 2007 17:33
I just looked at the beta1 (cant raise a bug report, not registered with jira, yet). Installed ok, but got a stack when :-
Select Browse Space, Select Manage Users/Groups,
Was present with some lines of text saying I needed to do a few things, and that an admin had to configure it _here_, when clicking the _here_ link, I was asked to login again, following this, I got:-
com.opensymphony.xwork.config.ConfigurationException: There is no Action mapped for namespace /admin/plugins/custompermissionsconfig and action name config
at com.opensymphony.xwork.DefaultActionProxy.(DefaultActionProxy.java:72)
at com.opensymphony.xwork.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:45)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceAction(ServletDispatcher.java:227)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:199)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:117)
at com.atlassian.confluence.util.profiling.ProfilingPageFilter.parsePage(ProfilingPageFilter.java:137)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.atlassian.core.filters.ServletContextThreadLocalFilter.doFilter(ServletContextThreadLocalFilter.java:21)
...
I think I had some bad config setup, but going back to the plugin config and keying values until all were valid, seems to have solved this. I guess the configure_here route should work but doesnt ?
In the vm it does this:
The implementation of getting the root is:
Where settingsManager is of type com.atlassian.confluence.setup.settings.SettingsManager and is set by autowiring.
Woah!
Please don't use Base URL unless critically necessary as it results in an absolute URL rather than a relative URL. This can cause all sorts of problems with Confluence sites that can be accessed from multiple entry points – for example every site out there which can run over both HTTPS or HTTP, as well as ones which have multiple subdomains pointed to the same Confluence install.
Instead use the following VTL code in your vm:
Thanks, Dan! Will have this fixed in the alpha-2 release (fixed in trunk).
Released v2.0-alpha-2 of Custom Space User Management Plugin: http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/releases/permission-management-2.0-alpha-2.jar
This release includes:
Hi Gary, I've just completed the commons-digester based parser for atlassian-user.xml , hopefully should be integrated tomorrow. We could use some UI plumbing to choose which source to use as both files can exist with LDAP content...
Let me know and I can add that to the config. Be careful if you are putting stuff in trunk to svn up first... some major changes today around directory structure and package name.
looks maven2 standard, but not sure about top level package name
I still don't seem to have commit rights in any case. Not to worry. I'm almost there with non-Atliassian dependant parsing of osuser and atalssian-user files, given me another day or two to get Unit Tests in and commit setup and then we'll need a UI selection based on a list of 'providers'. It would be possible to have another provider, sourced from the atlassian-user module, but Im not sure how far back the API will be valid for (or forward), best to keep Atlassian dependencies to a minimum?
As a general question for the community... would people rather have the Jira SOAP username, password, and endpoint URL set in spaceusergroupmanagementplugin.properties (which you need to put somewhere on classpath on every node running confluence), or would you rather this simply be put into the UI for the configuration?
The only reason we chose to use a properties file, was because we thought there might be a security concern around storing a password in configuration. However, the bad side of using a properties file is that it is a pain to change values and could be a pain to use in a clustered environment since the properties file would have to be the same in all of the nodes (although this is usually a one-time setup unless you have to change the username/password/JIRA SOAP service endpoint URL).
my 2p: So long as the password isn't shown (is ***'d) in the UI it shouldn't matter). The passwords could be stored in encrypted (blowfish/3des etc) entered through the UI so as to avoid having plain-text passwords but of course, if the source is open, so is the decryption technique, making the whole thing moot-ish.
If a properties file were used, that would mean that non-clustered plugin-installers would not be able to use this direct, possibly through the plugin repository, which would be bad.
Why not do both, but go for the larger user-base of stand-alone systems and do it primarily through the UI, storing the result in a property file. If we incorporate a check for the existence of a given property file (and possibly disablement of the UI aspect), this will then allow custom cluster-installers to roll their own and to take advantage of that feature.
Note that I'm holding off on the alpha-3 build for a little while until we get more feedback. Trunk contains an LDAP fix. It got broken in alpha-2 because of a bug in my integration of Andy's LDAP code, which we aren't really setup to test with currently. Thanks to Rajendra for finding that.If you need the fix in the meantime, just build trunk.
FYI - I'll drop this into our test environment as soon as alpha-3 releases. The LDAP piece is what we're interested in and prefer the atlassian-user.xml pull or the UI entry. In our environment (Fortune 100) we've outsourced all support so making changes to properties files is a long process.
Updated by Gary S. Weaver
Aug 10, 2007 08:17
We are doing what we can to have an alpha-3 release this afternoon, and at the latest (depending on atlassian) we'll release alpha-3 early next week. Thanks to Andy and Rajendra for all of their hard work this week!
P.S.-anyone know when svn.atlassian.com is going to come back up again? Is hard to develop without source...
Sorry for the delay. svn.atlassian.com was not working for us until this morning.
2.0-alpha-3 release of the plugin is now available.
A number of bug fixes in 2.0-alpha-3. I got all of Andy's LDAP stuff in correctly with config for LDAP username, passwd, etc. Rajendra found a lot of bugs and sent in some patches we integrated, and I believe that Rajendra tested LDAP successfully (so it should in theory support both anonymous and authenticated LDAP). We also added support to keep users with personal spaces from being able to manage users/groups through the tab provided by this plugin.
It would be nice if you all could all test this out in a test environment and add some tickets to our plugin's JIRA project if anything is not working or is acting funny. Contact a JIRA administrator for access to JIRA. Comments to this page would be great also (it is just less messy to handle bugs in JIRA).
The LDAP piece isn't working right for us. Opened SUSR-24 although perhaps I should have opened two. Take a glance and let me know.
Peter
Hi Peter,
I committed updated LDAP code today, that addresses firstname/lastname, also solving an outsanding problem with Digester. If you can, test it out and let me know how it goes.
Thank you very much for providing such a nice plugin !
In our organization,we reached at one obstacle though, which we think is a security hole.
I have set the group patterns as ".*", so that all groups are available.
We have given the ability for personal space to all users.As they have the personal space,they also have the rights to access the Space Permissions for their personal space.So naturally,they can add any group to their personal space.The user with the personal space has access to "Manage Users" too , and hence can add/delete any user from any group.So, in a way, this facility is available to all the users(as everybody has a personal space), whereas we plan to give this only to the space administrators.
Thanks for the suggestion, Pranav! This feature is now in alpha-3, just released!
Thanks Gary ! I am waiting for the stable release..
Can definitely understand that. If you could set up a test instance though (even if it is just local) and give it a try, it would
really help to see what you think of it. (I believe it is almost fully functional. You may not even notice the parts that aren't working.)
Alpha-4 has just been released. This release should make the LDAP feature work. Please post comments, either way!
Looks like Alpha-4 succeeded in resolving the LDAP issues I reported. Still more to go, though, and I'll open a pair of issues now. Thanks for working so hard on this!
Rajendra, Andy, and I were just speaking offline about this and realized that it was unclear that the original (and still current) intent of the LDAP functionality within this plugin is for those running confluence instances that are NOT using LDAP for user authentication to be able to automatically provision users using information from LDAP when adding users to groups via the plugin. Prior to this, even though I could see that the plugin autoprovisions users this way when LDAP is configured in the plugin, I didn't realize that this was only for those that weren't using LDAP for authentication (although now it makes sense). All this is to say, if you are using LDAP for authentication in confluence, it sounds like you do NOT need to configure LDAP in the plugin (which sounds counterintuitive, so we'll need to document this in the plugin configuration and in the setup instructions for the plugin fairly well). It is pretty cool that it can do that, but I'm sure it was a point of confusion to others (because I didn't even know it).
Ok, wait, what, huh?
We use LDAP for user authentication. We use Confluence for group management. (Well, LDAP too but not so much.) We use this tool, current release version, to allow Space Admins to add users from LDAP to Confluence groups.
Given all that, are you saying I need to go back in and, uh, de-define the LDAP stuff to get it to work right in my environment?
Lost I am!
Captcha: awaked - your post awaked me to the fact that I may have been misunderstanding...
The LDAP config items within this plugin's configuration (not talking about confluence, osuser or atlassian-user config, only the plugin config) are currently only used to autoprovision users in confluence if they don't already exist in confluence (and they would already exist if you were using LDAP in confluence itself for user authentication, I'd think).
So in brief, if you are using LDAP for confluence user authentication, then you don't need to configure LDAP within the plugin configuration itself. I created a ticket a little while ago for us to make it abundantly clear in the plugin config and in the documentation above that this is the case. Thanks to Andy for pointing this out and to Rajendra for clearing it up.
Ok, I'll remove the LDAP stuff from the Plugin by setting "LDAP Authentication Used?" to No and see what happens. Won't be able to test until SUSR-32 is resolved, though.
So now you've got me wondering why I have LDAP information defined in the current release version of the plugin...
Captcha: framers - people who build structures
Hi Peter,
Not sure if I understood you correctly.
But here is the thing: When you are associating given users, if Confluence user account is not available for those users; CSUM will use LDAP to get their details, create user account and then add those users into mentioned groups.
Does this helps,
Rajendra
Alrighty, now you're confusing me and slightly contradicting Gary. So you're saying that if a Space Admin goes to add a user that's not already in Confluence, which happens, then CSUM does need to have the LDAP information so that it can go look up the account, add it to Confluence* and then to the group?
Given that last, then, where am I supposed to be entering my LDAP authentication information? And if the answer is that it picks it up from atlassian-user.xml, my follow up question is why I have to define anything in CSUM at all since it's all in atlassian-user already?
Difficult, aren't I?
*One hopes it honors our settings that any account added to Confluence be added to "confluence-users" as well.
Captcha: stages - I'm starting to grasp the new settings to this plugin in stages
The following are outstanding dev requests to Atlassian related to this plugin if you'd like to vote on them...
Hi.
I followed the instructions for installing the plugin (conf 2.5.5-std) and did it via the file upload.
It was recognized and as I was configuring it, it failed to save the configuration.
We are using an oracle backend for the db and shibboleth for the sign-in methodology (similar to Gary's environment I believe).
I can see the tab in the space admin area and when I visit it, I see this error:
How can I force the settings to be saved???
Thanks !
Chris.
Chris,
When you go to configure the plugin settings and click the update button at the bottom, are there any messages (in red) over any of the fields in the form? If so, the settings weren't saved. The error that you got was due to the "User Manager Location" in the config not being saved (the radio button where you choose Confluence or Jira user management).
Glad to know someone else is using Shibboleth (now I don't feel so lonely) although for the purposes of the plugin it shouldn't matter what authenticator you use.
Thanks!
Gary
I was able to get it to work finally. Looks like the only thing different (that I can tell) is I chose to have the plugin enabled and added a downtime message to the configuration.
I committed the changes and I finally saw them.
Thanks very much for the quick turn around on the replyto this issue. I'll probably have questions in the future, but will tinker around with what we have right now.
Is there a way to bulk load/create groups through SOAP/XML-RPC calls? I'm being asked how to synchronize course 'groups' in certain areas of the wiki and this seems like an interesting place to hang the feature off of.
Yes you can do that, there are also plugins that purport to do bulk upload but they've never worked for me, I chose the 'just in time' solution of using the ConfluenceGroupJoiningAuthenticator. Please expand on 'synchronize' and where your users are registered.You can use CSUM to add a list of csv list of userids, if you have configured LDAP correctly (or not as required!) they can be pre-created and added to a given group (space specific group). Of course, there is nothing stopping you using that same group in another space.... hence, what are you synchronizing?
Chris,
There is a Confluence SOAP API and XML-RPC API and you can also write a plugin that can use the Confluence API itself to add groups and users (see UserAccessor and our source for an example).
However, what I'm really interested to know is what are planning to try to sync (blackboard course "groups", grouper groups, etc.?). I think that there would be enough external interest from universities such that whatever you are thinking of might be a good idea to do as a new plugin, and if it is something Duke University could benefit from, I'd be happy to talk offline about helping start up another plugin for this.
alpha-5 is on hold for now. Was planning on releasing this afternoon, but having some difficulty integrating with the new LDAP library. Hopefully will be available in the next few days.
ldaputil 1.0.4 fixes all known LDAP bugs, I get green lights configuring CSUM with my atlassian-user config - Ive tested the osuser with a separate plugin (Ill try and test osuser with csum tomorrow).
Unfortunately still not working in our environment (atlassian-user, LDAP). So close...
Even though Andy ended up fixing a few more things in LDAP in the last several days, the problems I was having with LDAP were my own (I had a bad atlassian-user.xml usernameAttribute). Going to run through another round of testing and release alpha-5. Thanks, Andy!
v2.0-alpha-5 released! Please let us know how it goes. LDAP stuff is much better now (thanks, Andy!), bugs worked out of user search to show users even after add/delete, other bugs fixed, javascript validation added (thanks, Ren!).
Dropped into my QA environment and ran some quick tests. Working very nicely. Again, good job!
Oh, a question for you, one which I could probably look up but will ask here instead for the benefit of all as it pertains to how the plug-in operates:
Does a Space Admin also need to be a member of the group in order to administer the group?
Thanks!
No Space Admin doesn't need to be member of a groups associated to wiki space. We do check to make sure that given user has a Space Admin permissions or not.
hope this helps,
Rajendra
2.0-beta-1 is now available. Please use this instead of previous versions. alpha-5 had a bug in bulk-edit that kept anyone from using it. It should soon be available via the plugin repository also (I updated it and am awaiting the metadata at the top of this page to show it is available).
Yea. The metadata in the page finally updated. You can now download the plugin via the metadata at the top or possibly via "Administration->Plugin Repository" (although the latter for me causes the javascript alert "TypeError: exception has no properties" in Firefox and "TypeError: undefined value" in Safari, but maybe you will have better luck than me... waiting to hear back from support on that).
On install from admin plugins I get: TypeError:Exception has no properties
Installed Manually, reloaded the admin|plugins area, set the configuration, now it works
This is incredible, I have been needing space-based user administration forever! Thank you!
Mark, thanks and we're really glad that you like it and find it useful!
Jonathan Nolen figured out the plugin metadata issue that was causing the "TypeError: undefined value" and "TypeError:Exception has no properties" issues. The url in the plugin's repository metadata.xml has some whitespace around it. When Jonathan removed it, the repository manager picked that change up (many minutes later) and now you can also get the plugin from the Plugin Repository. Woohoo!
Just checking in... Has anyone had any problems, or is all going fine? Please use the Issue Tracking link at the top now if you have any trouble, but please feel free to comment instead if you can't get a Jira account in short order. Thanks!
Hey Gary, just tested beta1 loaded from the repo, works a treat for me (tm).
Updated by Gary S. Weaver
Sep 18, 2007 14:49
2.0-beta-2 released with fixes from Rajendra and Ren. Should be available via Plugin Repository shortly (I've already submitted it).
The following modifications have been made:
I'd recommend using Plugin Repository instead, but if you must know the jar is located at: http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/releases/permission-management-2.0-beta-2.jar
Hey everyone... have a quick question about LDAP... Specifically, for those of you using full LDAP integration with Confluence (for auth, groups, etc., not just for the csum plugin), when you create groups in the CSUM plugin, is it creating groups in LDAP? As far as I knew, LDAP was read-only to Confluence, but maybe I understood that incorrectly.
If it is not the case that the csum plugin can already create groups in LDAP, does everyone think it is a good idea to add an option in the csum plugin so that it could add (bind) groups in LDAP? If so, is there anyone that would like to get involved in the development of that feature?
Thanks!
Gary
Hey Gary, given the bind command is required to write to ldap 'find . -name "*.java" | grep bind' over the 2.5.6 sourcecode yielded two results relating to import/export. To me this means there is no LDAP write support in Confluence. Someone shoot me if I get this wrong
Struggling to get CSUM working on 2.6.0 - has anyone else seen an issue? The plugin just fails to install 2.0 (beta2), either from the repository or via upload and 1.1 gives a system error.
-pc.
Thanks, Paul. We're looking into this currently. There are a lot of rumblings about 2.6.0, so I don't know that I would recommend it for production anywhere if you need plugins to be compatible.
Sincere apologies,
Gary
Thx Gary.
2.6 is only on our test server at the moment, so not really giving us any headaches.
-pc.
Updated by Gary S. Weaver
Oct 02, 2007 16:05
Custom Space User Managment 2.0-rc-1 released (release candidate 1). Should be available on this page and via Administration -> Plugin Repository within hours for those using Confluence versions pre-2.6.0.
Note that both this release and the final release of csum 2.0 that is planned within a few weeks or sooner will NOT support Confluence 2.6.0 (because building against earlier versions of Confluence breaks the plugin in 2.6.0 for some reason). However, almost immediately after we release csum 2.0 final, we are planning to release the first alpha version of csum 2.1 which partially works for Confluence 2.6.x. What I mean by "partially works" is that I got a pre-alpha 2.1 version of the plugin to load in 2.6.0 after some tweaking, and so far it can create groups and add/remove users, but unfortunately it can't remove groups (at least in my dev environment) without a system error. The painful thing there is that it appears to be a bug in Confluence's API (the only difference was what version of confluence I built it against), so Atlassian needs our team to help define what is wrong, and we must rely on them for a fixed version of 2.6 if that is the case. I've logged this as: http://jira.atlassian.com/browse/CONF-9623 (the pre-alpha Confluence 2.6.0 semi-compatible version of csum plug is attached to that bug here - please ignore the fact that it is 2.0-SNAPSHOT instead of 2.1-SNAPSHOT )
I'm sure all of that will turn out ok, but for now it is a headache.
Since it hasn't shown up in Plugin Repository yet (although I'd suggest you wait on it) if you really want to you can download it and install manually. Here is the link: http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/releases/permission-management-2.0-rc-1.jar
Also, I tried it again today and noticed that the 2.0-rc-1 jar is just as runnable in 2.6.0 as the 2.1-alpha jar I was talking about, and it was built against Confluence 2.5.3 (note: it also builds against 2.3 which is the earliest version of Confluence in repository.atlassian.com). This makes sense, but I did have to restart Tomcat in order for it to take (before that would get error on load). Very strange stuff. Since it is still semi-broken in 2.6.0 though, I'm going to leave the 2.0 releases' as incompatible with anything after 2.5.7. Note: there is a Confluence 2.5.8 coming out, so we'll need to update the metadata once we find out what that build number will be.
 Thanks! I just ugpraded to 2.6, and noticed this plugin wasnt working. Thanks for the quick responce.
Garry - just noticed you cant delete a group. It crashes. Here is what I get:
Cause:
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:405)
Thanks for testing it out, Sherif! Yes, you are correct. This appears to be a bug in 2.6.0. I logged a jira ticket with Atlassian to fix and have now asked for a workaround. Please vote on it/watch it at http://jira.atlassian.com/browse/CONF-9623
Atlassian has been rather responsive the last few days so I know they are working hard to resolve issues like this. I would strongly suggest testing out things in 2.6.0 to make sure any other plugins you rely on also work and letting the plugin authors know if they don't. There were significant changes in 2.6.0 and from talking with David Peterson it seems like the norm over the last several releases is for plugin authors to stop supporting older versions when major changes come out like this.
Also - a quick update on csum 2.0 final release: we wanted to get this release out right away, but ran into some issues that Andy is working hard to fix. I think we're hoping that will be resolved and we'll have the final release done within a week or two. It is possible that once Atlassian figures out their delete group bug that the 2.0 final release will work in Confluence 2.6.1+ as well (but don't quote me on that).
Thanks Gary. Consider it as totalVotes=totalVotes+1;
Sherif
Hi there, Can I just add that we're seeing similar problems deleting groups in Confluence v2.5.4
Anne Marie,
If you have time to add a bug in our issue tracking system, that might be best since you could attach more description of the error and perhaps some debug log there: http://developer.atlassian.com/jira/browse/SUSR
Without any more information, I'm not sure what to say. We started developing v2.0 of the csum plugin against 2.5.4 originally and as far as I remember removing groups worked then, but I haven't personally tested recent versions of the csum plugin against Confluence 2.5.4. Something I always have wondered about is whether someone who has integrated Confluence with LDAP for groups (or integrated with some other read-only system-of-record for groups) might have problems with group addition and deletion in csum. If that is the case here, there is an option in the csum config that lets you turn off group add/remove functionality as a temporary workaround, and perhaps at some point if someone was interested they might add the functionality into the csum plugin to be able to add/remove those groups if possible.
Hope this helps. If not, please let us know.
Gary
Custom User Management Plugin v.2.0-rc-2 released and submitted to Plugin Repository (I have no idea when it will be updated in plugin repository, because for some reason the last release didn't take either- will email Jonathan about that).
Fixes:
Can be downloaded from: http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/releases/permission-management-2.0-rc-2.jar
2.0 final will be available after we've had time to test rc-2 and fix any bugs that come as part of that final testing.
Gary,Thanks for getting this version out so quick!
Tested on mine and it fixed one main issue I was having - If a group was already assigned to the space, and I clicked 'manage users' tab - it didnt pickup there were any groups there. This seems resolved now -thanks. (I still can't delete a group - But Im that wasnt fixed in this version was it)
Thanks again
Sherif
Sherif,