Edgewall Software
Modify

Opened 12 years ago

Last modified 2 years ago

#2456 new enhancement

Implement API for user management

Reported by: Emmanuel Blot Owned by:
Priority: normal Milestone: next-major-releases
Component: general Version: 0.9.2
Severity: major Keywords: user
Cc: wkornewald, ilias@…, danny.adair@…, r.sokoll@…, crippledcanary@…, gt4329b@…, silk@…, xgravity@…, lafeuil@…, catalin.balan@…, ThurnerRupert, mladen@…, d.grellscheid@…, tolsen@…, itamarost@…, felix.schwarz@…, leho@…, mmitar@…, franz.mayer@…
Release Notes:
API Changes:

Description

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:

Attachments (15)

userdir-for-r2637.diff (9.4 KB ) - added by brad <brad@…> 12 years ago.
patch 1 for UserDirectory plugin
userdir-for-r2659.diff (9.8 KB ) - added by brad <brad@…> 12 years ago.
patch 2 for UserDirectory plugin
userdir-for-r3271.diff (10.0 KB ) - added by brad <brad@…> 12 years ago.
patch 3 for UserDirectory plugin
user.py (6.5 KB ) - added by wkornewald 11 years ago.
first suggestion
user.2.py (8.6 KB ) - added by wkornewald 11 years ago.
now with User object, still completely untested
user.3.py (8.9 KB ) - added by wkornewald 11 years ago.
now with User object, still completely untested
user_API.diff (21.2 KB ) - added by wkornewald 11 years ago.
patch against trunk (0.11)
user_API.2.diff (27.0 KB ) - added by Waldemar Kornewald <wkornewald> 11 years ago.
don't expose email address (users want privacy!), optimizations for huge numbers of users (no more email_map)
user_API_r4501.diff (23.4 KB ) - added by Waldemar Kornewald <wkornewald> 11 years ago.
updated patch for show_email_addresses option. added a generic attribute mapper.
userdir-for-r4673-0.10-stable.diff (5.4 KB ) - added by Brad Anderson <brad@…> 11 years ago.
updated patch for 0.10 branch, untested
userdir-for-r4673-0.10-stable2.diff (10.6 KB ) - added by Peter Dimov <peter.dimov@…> 11 years ago.
The previous patch does not create trac/userdir.py and does not patch trac/notification.py this one does…
user_API_r4938.diff (22.8 KB ) - added by Waldemar Kornewald <wkornewald> 11 years ago.
resolved conflicts with most recent refactorings. also, we now use get_users_with_permission() which simplifies the code
user_API_r5898.diff (22.5 KB ) - added by Morris 10 years ago.
patch for r5898 — I have lots of other mods, so here's hoping that I filtered them all out of this patch…
user_API_r5898.1.diff (22.4 KB ) - added by Morris 10 years ago.
deprecates user_API_r5898.diff (which removed 2 lines from trac/notification.py in error)
user_API_r6033.diff (22.0 KB ) - added by Morris 10 years ago.
User API patch for trunk (0.11dev) r6033

Download all attachments as: .zip

Change History (72)

comment:1 Changed 12 years ago by 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?

Changed 12 years ago by brad <brad@…>

Attachment: userdir-for-r2637.diff added

patch 1 for UserDirectory plugin

Changed 12 years ago by brad <brad@…>

Attachment: userdir-for-r2659.diff added

patch 2 for UserDirectory plugin

Changed 12 years ago by brad <brad@…>

Attachment: userdir-for-r3271.diff added

patch 3 for UserDirectory plugin

comment:2 Changed 11 years ago by brad <brad@…>

Milestone: 0.12

comment:3 Changed 11 years ago by wkornew

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

comment:4 Changed 11 years ago by 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?

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by wkornew

Cc: wkornew added

comment:7 Changed 11 years ago by anonymous

Cc: gunnar@… added

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.

comment:8 Changed 11 years ago by anonymous

Cc: gunnar@… removed

comment:9 Changed 11 years ago by wkornewald

Cc: wkornewald added; wkornew removed

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?

Changed 11 years ago by wkornewald

Attachment: user.py added

first suggestion

comment:10 Changed 11 years ago by 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.

comment:11 Changed 11 years ago by 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).

comment:12 Changed 11 years ago by 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?

Changed 11 years ago by wkornewald

Attachment: user.2.py added

now with User object, still completely untested

Changed 11 years ago by wkornewald

Attachment: user.3.py added

now with User object, still completely untested

Changed 11 years ago by wkornewald

Attachment: user_API.diff added

patch against trunk (0.11)

comment:13 Changed 11 years ago by 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?

comment:14 Changed 11 years ago by ilias@…

Cc: ilias@… added

Changed 11 years ago by Waldemar Kornewald <wkornewald>

Attachment: user_API.2.diff added

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

Changed 11 years ago by Waldemar Kornewald <wkornewald>

Attachment: user_API_r4501.diff added

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

comment:15 Changed 11 years ago by 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!

comment:16 in reply to:  15 ; Changed 11 years ago by 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.

comment:17 in reply to:  16 Changed 11 years ago by 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?

comment:18 Changed 11 years ago by Waldemar Kornewald <wkornewald>

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

Changed 11 years ago by Brad Anderson <brad@…>

updated patch for 0.10 branch, untested

Changed 11 years ago by Peter Dimov <peter.dimov@…>

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

comment:19 Changed 11 years ago by danny.adair@…

Cc: danny.adair@… added

comment:20 Changed 11 years ago by r.sokoll@…

Cc: r.sokoll@… added

Changed 11 years ago by Waldemar Kornewald <wkornewald>

Attachment: user_API_r4938.diff added

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

comment:21 Changed 11 years ago by Waldemar Kornewald <wkornewald>

Summary: Define IUserDirectory interfaceImplement API for user management

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

comment:22 Changed 11 years ago by anonymous

Cc: crippledcanary@… added

comment:23 Changed 10 years ago by Morris

Cc: gt4329b@… added

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…

comment:24 Changed 10 years ago by 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.

comment:25 in reply to:  24 Changed 10 years ago by 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.

comment:26 Changed 10 years ago by ThurnerRupert

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

Changed 10 years ago by Morris

Attachment: user_API_r5898.diff added

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

comment:27 Changed 10 years ago by 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.

Changed 10 years ago by Morris

Attachment: user_API_r5898.1.diff added

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

comment:28 Changed 10 years ago by anonymous

Cc: silk@… added

comment:29 Changed 10 years ago by anonymous

Cc: xgravity@… added

comment:30 Changed 10 years ago by Christian Boos

Keywords: user added

comment:31 Changed 10 years ago by anonymous

Cc: lafeuil@… added

Changed 10 years ago by Morris

Attachment: user_API_r6033.diff added

User API patch for trunk (0.11dev) r6033

comment:32 Changed 10 years ago by 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.

comment:33 Changed 10 years ago by catalin.balan@…

Cc: catalin.balan@… added

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

comment:34 Changed 10 years ago by ThurnerRupert

Cc: ThurnerRupert added

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"?

comment:35 in reply to:  34 Changed 10 years ago by 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.

comment:36 Changed 10 years ago by anonymous

Cc: mladen@… added

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.

comment:37 Changed 10 years ago by 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

comment:38 Changed 9 years ago by d.grellscheid@…

Cc: d.grellscheid@… added

comment:39 Changed 9 years ago by Christian Boos

Severity: normalmajor
Type: taskenhancement

comment:40 Changed 9 years ago by anonymous

Milestone: 0.130.12
Priority: normalhighest
Severity: majorcritical

Wow! 3 years to implement such a simple feature.

This truly sucks!

comment:41 Changed 9 years ago by ebray

Milestone: 0.120.13
Priority: highestnormal
Severity: criticalmajor

comment:42 Changed 9 years ago by tolsen@…

Cc: tolsen@… added

comment:43 Changed 8 years ago by Ralph Bean

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

comment:44 Changed 8 years ago by itamarost@…

Cc: itamarost@… added

comment:45 Changed 7 years ago by Felix Schwarz

Cc: felix.schwarz@… added

comment:46 Changed 7 years ago by Remy Blank

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

comment:47 Changed 7 years ago by lkraav <leho@…>

Cc: leho@… added

comment:48 Changed 7 years ago by Mitar

Cc: mmitar@… added

comment:49 in reply to:  37 ; Changed 7 years ago by Itamar Ostricher

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.

comment:50 Changed 7 years ago by 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?

comment:51 in reply to:  49 Changed 7 years ago by 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.

comment:52 Changed 7 years ago by 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.

comment:53 in reply to:  52 Changed 7 years ago by Christian Boos

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

comment:54 Changed 6 years ago by 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.

comment:55 Changed 6 years ago by 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?

comment:56 Changed 6 years ago by framay <franz.mayer@…>

Cc: franz.mayer@… added

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.).

comment:57 Changed 2 years ago by Ryan J Ollos

Owner: Jonas Borgström deleted

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences .

 
Note: See TracTickets for help on using tickets.