Implement API for user management

[eblot]

I'm adding this ticket to keep track of the on-going discussion about creating a new 'user detail' interface to Trac.

The new interface would be something like:

class IUserProvider(Interface):

  def get_known_users(attrs=('name', 'email'), limit=None):
      pass

  def get_user_attribute(user, attr):
      pass

  def get_supported_attributes():
      pass

Related ML thread:

• http://lists.edgewall.com/archive/trac/2005-December/005771.html

[brad <brad@…>]

I have attached a preliminary patch that is at least working for my needs. There is some hard-coding around user attributes, and my Python skills are not that strong, so another set of eyes would be great. Hopefully it's a good start based on the discussion in the mailing list. Feedback is welcome.

Also, there are development notes and questions here: http://trac.dsource.org/projects/test/wiki/UserDirectory - should we use that wiki or this bug?

[brad <brad@…>]

patch 1 for UserDirectory? plugin

[brad <brad@…>]

patch 2 for UserDirectory? plugin

[brad <brad@…>]

patch 3 for UserDirectory? plugin

[wkornew]

Why don't you want to add this as an officially supported feature? I doesn't disturb anyone.

[eblot]

wkornew: I'm not sure to understand your point: if we introduce the IUserDirectory interface, Trac engine needs to be modified so that it retrieves the user properties from a IUserDirectory implementation, rather than from a current direct access to the user session data.
Can you elaborate?

[anonymous]

The user session data is independent of the user's login when using the DbAuth? plugin, for example. It would be very nice to have email notifications use the email address stored in the user's database. Also, the real name could be retrieved from the DB, too. We need a unified single interface for this. Session data is not a good solution when requiring registration+authentication. Unfortunately, you are using a very open model, by default, so you probably don't see a need for it, but big projects must have this.

[anonymous]

Is there any timeline when 0.12 will be eventually out of the door?

I'm planning a migration from StarTeam? to Subversion for our company by the end of this year. We also need a new tracking system. But this is one of the big issues that makes it really hard for me to keep Trac on the list.

I need to be able to read full names and email addresses from LDAP/Active Directory automatically at logon. The users shouldn't even be able to change it.

[wkornewald]

What is needed to get this working? I might want to hack on this a little bit next month.

Is anything missing? Does more Trac code need to be changed? For example, I could imagine that the session UI should be removable.

Do you not like the interface? What should the interface look like?

[wkornewald]

first suggestion

[wkornewald]

Guys, is the API in attachment:user.py good enough? Please take a look. IUserStore is similar to AccountManager?'s IPasswordStore. I don't want to waste time on this and then be told that you won't accept anything.

[Manuzhai]

While I agree that it would be nice to have this functionality (but then I'm not a Trac developer), I don't particularly like your patch. Seems to me that it allows too many variations. A Trac-like approach would be more convention, less configuration, I think: supporting a small fixed set of operations on users. Also the get_attribute, set_attribute and del_attribute are smelly, since Python just has getattr, setattr and delattr (as well as property()s, by the way).

[wkornewald]

I based the API on the AccountManager? plugin. The has_user operation could be removed. The rest of the operations are necessary because I want the API to not only provide existing user information, but also allow for real user management. It should be the backend for all user modules (DbAuth?, LDAP, .htaccess, etc.). The current IAuthenticator interface is too complicated and duplicates code for cookie handling and the login dialog.

Trac must finally get real user registration and management support.

What exactly did you want to have? I'm thinking about moving most of the UserManager? code into a User class, so UserManager? only has get_usernames() => string array, create_user(username, password) => User, and get_user(username) => User. The user object then has all the other methods (attributes, password, deletion). Would that be better?

[wkornewald]

now with User object, still completely untested

[wkornewald]

now with User object, still completely untested

[wkornewald]

patch against trunk (0.11)

[wkornewald]

Please try this patch. I've tested it on my local machine in authenticated and unauthenticated state. It seems to work without any bugs, now.

The only issue I have is that every component must implement the supports_xxx methods. Since it's a two-liner, by default, it's probably not such a big problem. Any suggestion for an elegant fix?

[Waldemar Kornewald <wkornewald>]

don't expose email address (users want privacy!), optimizations for huge numbers of users (no more email_map)

[Waldemar Kornewald <wkornewald>]

updated patch for show_email_addresses option. added a generic attribute mapper.

[Waldemar Kornewald <wkornewald>]

While it would be nice to have an admin interface, I think this is a task for 0.12. It would be very useful to have the user API for 0.11, though. This way, people could update their plugins before 0.12 is out. This is already important functionality. The rest can come with 0.12. Could you please commit the patch?

I wish you a Happy Christmas!

[cboos]

Replying to Waldemar Kornewald <wkornewald>:

Could you please commit the patch?

Well, not directly in that form, but we agreed to create a sandbox branch for fine tuning the patch, please get in contact with jonas for svn commit access.

[Waldemar Kornewald <wkornewald>]

Replying to cboos:

Replying to Waldemar Kornewald <wkornewald>:

Could you please commit the patch?

Well, not directly in that form, but we agreed to create a sandbox branch for fine tuning the patch, please get in contact with jonas for svn commit access.

I'm a much too busy right now, but maybe in the holidays (around mid-February) I could do some more work. What exactly did you want to have changed?

[Waldemar Kornewald <wkornewald>]

BTW, I'm on the dev list, so you can also contact me there.

[Brad Anderson <brad@…>]

updated patch for 0.10 branch, untested

[Peter Dimov <peter.dimov@…>]

The previous patch does not create trac/userdir.py and does not patch trac/notification.py this one does...

[Waldemar Kornewald <wkornewald>]

resolved conflicts with most recent refactorings. also, we now use get_users_with_permission() which simplifies the code

[Waldemar Kornewald <wkornewald>]

The code is untested, but it should work since I didn't do any big changes. *crossing fingers* :)

[Morris]

Anyone working on this?

I'm in dire need of the ability to go grab an email address from an LDAP/AD server, querying by Trac username (as sAMAccountName, in my case). I've posted to the ML ...and was referred back to this ticket -- which I had already discovered and actually had open in the next tab while writing my ML post :D

If I can get past my (hopefully) last hurdle, I'd be more than happy to package up my hack -- which is much humbler in scope than the IUserProvider concept -- and stick it on Trac-Hacks, as a temporary gap-filler until the fuller IUserProvider functionality is up. Jump in the thread on the users ML (Getting email address from LDAP/AD) if you'd like to monitor/contribute to this gap-filler effort...

[Morris]

Welp, since no one seems to be active on this at the moment - and I need it - I suppose I'll start fumbling around with it. I've got a patch/diff that brings it up to r5898; if anyone wants it, lemme know.

[r.sokoll@…]

Replying to Morris:

Welp, since no one seems to be active on this at the moment - and I need it - I suppose I'll start fumbling around with it. I've got a patch/diff that brings it up to r5898; if anyone wants it, lemme know.

I'm very interestet in your patch - can you post it here? Also, it would be great if someone with write permissions to t.e.o could apply your patch to sandbox/testing.

[ThurnerRupert]

is there a relationship to #3737, or is it even the same?

[Morris]

patch for r5898 -- I have lots of other mods, so here's hoping that I filtered them all out of this patch...

[Morris]

This is a replacement for the patch user_API_r5898.diff -- the original version of that patch erroneously removes two lines from trac/notification.py that leads to the [notification] ignore_domains being ignored. This updated patch shouldn't remove those lines.

If you've already applied the original user_API_r5898.diff patch, you can by-hand add the following lines back in to trac/notification.py:182 (the very end of the NotifyEmail.__init__ method):

        domains = self.env.config.get('notification', 'ignore_domains', '')
        self._ignore_domains = [x.strip() for x in domains.lower().split(',')]

Sorry for the inconvenience.

[Morris]

deprecates user_API_r5898.diff (which removed 2 lines from trac/notification.py in error)

[Morris]

User API patch for trunk (0.11dev) r6033

[Morris]

OK -- I've revisited this concept. Development on IUserDirectory is currently slated for 0.12, but I needed more flexibility now.

What I needed was a way to allow specification of the users available in the "Assign To" dropdown, customizable on a per workflow-state basis -- so I've created a plugin that enables just that. The general idea is that after installing this plugin, which I'm calling FlexibleAssignTo, you write your own plugin that implements a getUsers() method that is itself called by FlexibleAssignTo (FlexibleAssignTo implements a new extension point, IValidOwnerProvider). Your own getUsers() method can get a user list from wherever it needs to -- in my case, that's LDAP/AD, but you could write your getUsers() to return users from wherever.

As luck would have it, trac-hacks is down -- so until it's back up and I've got a proper plugin page in place, check out the FlexibleAssignTo thread on the trac-users list for a full overview of the plugin's functionality.

[catalin.balan@…]

Hi,

I've just posted on Trac-Hacks.org a new plugin named TeamRosterPlugin. This plugin tries to solve some 'requirements' mentioned here(user details), but it's more focused on user's "meta data" and less on authentification/permissions/etc, because I'm using it in combination with Account Manager plugin, combination which proved to be a very bad one because workspace admins need to use at least +3 "screens" in order to setup one user(very very confusing for them).

I'm sorry that I didn't know about this ticket until now(which is strange since it's is 2 years old), but, since we're trying to solve the same problem, the apis are somewhat similar(or ... "great minds think alike" :) ).

Since we are trying to do the same thing, I would like to 'synchronize', somehow, my api with this one(r6033) and hopefully, at some point, solve the +3 "screens" problem, but also I would like to point out some features that my plugin has, like:

• Multiple User Providers(~UserAttributesProviders?) one UserStore?, which basically means that workspace admins can select a user from various "data sources"(ldap, another workdpace(s).... ) and add to UserStore? by a single click.(and customize that profile for the current workspace).
• Why delete users, why not just disable them since they already interacted with the environment.

Waiting for your feedback.

Best regards,
Catalin BALAN

[ThurnerRupert]

would your plugin also allow to solve #3737, i.e. providing a login-id used for authentication, and a nick for entering in cc, assign, reassign, ...? or would this require a "login-plugin"?

[anonymous]

Replying to ThurnerRupert:

would your plugin also allow to solve #3737, i.e. providing a login-id used for authentication, and a nick for entering in cc, assign, reassign, ...? or would this require a "login-plugin"?

Well, my plan is to have one think that can solve "everything" related to user management. And yes, I think that #3737 can also be solved with my plugin.

[anonymous]

You Akismet is way too strict. I had to add this comment after it would allow me to just add myself in the cc column.

[catalin.balan@…]

Hi

Just wanted to let you know that I've posted a new plugin on Track-Hacks named UserManagerPlugin. (I'll add screenshoots soon)

Waiting for your feedback.

-- Catalin Balan

[anonymous]

Wow! 3 years to implement such a simple feature.

This truly sucks!