Implement API for user management

[Emmanuel Blot]

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.

[Emmanuel Blot]

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!

[Christian Boos]

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!

[Ralph Bean]

I am also in need of the enhancement described here. (bump)

[Remy Blank]

#4231 asks for user aliases to cope with different usernames between Trac and repositories.

[Itamar Oren]

Replying to 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

The need for "richer" user-management for my organization is growing, which made me look into various tickets related to the issue, as well as into the ​UserManagerPlugin mentioned here.

As it stands, the ​UserManagerPlugin is a good start, but just a start. I am wondering what should be the preferred way to proceed - work on enhancing the plugin as a plugin, or work on implementing features in core (based partially on the plugin)?

Advice / thoughts appreciated.

And, of course, nice work with the plugin, Catalin.

[lkraav <leho@…>]

i am also interested in putting in some work on this, especially with ldap connectivity. just chatted with cbalan about it yesterday as well. i just msg'd you irc, let's talk. anyone else interested?

[Christian Boos]

Replying to itamaro:

Replying to 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

The need for "richer" user-management for my organization is growing, which made me look into various tickets related to the issue, as well as into the ​UserManagerPlugin mentioned here.

As it stands, the ​UserManagerPlugin is a good start, but just a start. I am wondering what should be the preferred way to proceed - work on enhancing the plugin as a plugin, or work on implementing features in core (based partially on the plugin)?

In core please, but I briefly had a look at ​TH:source:usermanagerplugin/0.11/tracusermanager/api.py, while well done, please not yet another invention of a model class… we already have too many, time to get this down to one.

[nielx]

Notes on Groups

Groups are a hack of the permission table now. They currently cannot be used in any of the other components as they are purely a data construction. During the cleanup of the user section, we might as well also clean out the group system and put a real group object in place.

Question 1: Will groups be a core concept, or are they more for a plugin?

One might argue that for very simple Trac installations, groups are really more of an extra feature than a core necessity. If you have only four developers, giving them the extra permissions on a user basis is feasible. The default groups, could turn into trac.ini parameters (see Question 2). At the other hand, as soon as the user base grows, group permissions are very flexible and clean up the user permission table a lot.

Question 2: How flexible will groups be?

Is it necessary to allow for other plugins to be able to provide groups to the system? One might already think of the SystemGroupProvider (for the anonymous and authenticated groups) and the DatabaseGroupProvider, however, the first one can also be handled as a trac.ini entry. Furthermore, if groups get permissions, then how to handle permissions that are given to for example ldap based groups. Will ldap have to store these? Or will it have to do the accounting for the group permission table? At the other side … how many use cases are there? If any component provides groups, they might as well use the database group system to store them.

Question 3: Will users and groups keep permissions?

With the current hack, both users and groups get permissions. In the new system, we might choose to have only groups have permissions. Users will then get assigned into groups (or roles, as an alternative term). This is for example how Drupal does it. It will save a table, and a PermissionPolicy, and it might make the system less confusing for first time users.

[Christian Boos]

Replying to nielx: To complement your requirements, I'd like to point to the refactoring already discussed in #5648.

[lkraav <leho@…>]

mozilla services team is starting to heavily build on python (pyramid) and ldap. this seems trac-pplicable: ​ldappool: a simple pool for python-ldap

i did an "ldap" search on tickets and really couldn't find a better place to note this down. i'm not up to date with the ldap plugins on trac-hacks right now, but i'm pretty sure it can help one of the existing plugins as well.

[lkraav <leho@…>]

since this thing doesn't seem to move at all without some added stimuli (which i'm not entirely certain what that should be, thoughts welcome), i'd like to announce that i'm willing to contribute some triple-digit euro number for a bounty. is there someone else following this ticket who finds enough value in the goal to contribute to the pot? suggestions for choosing a platform to manage the bounty would also be nice; maybe ​http://gun.io?

[framay <franz.mayer@…>]

Wouldn't adding a separate user table, fix some problems (see #7339) and enhance Trac. In a first step it wouldn't have been a swiss army knife. Maybe storing name, email and some "easy data" (like phone number, department as free text) would do it. When having the user table the handling could be improved bit by bit (linking to permisson, department and role, etc.).