User System Proposal

Current proposal status: Requirements analysis and discussion.

Currently (0.12), Trac lacks awareness to the concept of a user as an entity in the system, and where it does - it relies on the session store information along with permission tables.

The purpose of this proposal is to make Trac core recognize a user as a basic entity in the system in an extensible manner (see #2456), as well as groups of users.

General Requirements

1. A user should be an entity in the system, independent of session-related information; For instance, a user might exist in the system without an actual session for that user.
2. The user entity consists of various attributes, with an extension point that allows plugins to hook on the user attribute system (change listeners, custom attributes, etc.)
   1. Some attributes to include in core: Username, Trac nick (#3737, #7339), repo-alias-tuples (reponame, repo-alias) (to support different logins between Trac and VCS backends), full name, email address, image, role (see #AttrSets below for advanced use-case related to "role"), contact information, language / locale, user-specific preferences and settings (#2182, #3360, #150, #9616, #9673), tags / keywords (as in tickets).
   2. Possible extras: employee-ID, birthday.
3. Groups should also be recognized as entities in the system; A group is defined as a collection of users, and should also have attributes (e.g. group name, description).
   1. A user may be a member of multiple groups, or no groups at all.
   2. Groups may have users (zero or more) or other groups (zero or more) as members.
4. Actual user-data access and manipulation (via an IUserStore interface) should be decoupled from user management API (via an IUserDirectory interface).
   1. Trac core should include a default UserStore component in the env-DB (possibly separate from session data).
   2. Plugins may replace the default user-store with an alternative UserStore component, and an option in the TracIni (similar to the permission_store option for the permission system).
   3. Additional UserStore components to consider inclusion in core: Trac-proxy (e.g., in multiple-environments use cases, have one environment store users in its DB, and all other environments go through that one environment), LDAP.
5. User attribute values should support change-tracking, and keep history of changes (who changed what and when, with comments - similar to tickets).
   1. I'm not LDAP expert, but I'm not sure how this can be achieved with LDAP-backend. Possibly a special LDAP-schema is required here?
6. Permissions related to user-management should be introduced (e.g. CREATE_USER, DELETE_USER, MODIFY_USER, MODIFY_USER_SELF, VIEW_USER, similarly for GROUPs, …)
7. A user realm should be introduced, with usernames and groups as resources within the realm, and user profile (or user page) and group profile rendered for existing users and groups under the realm (extension of #8335, #4588).
   1. User / Group profile may be accessed via hierarchy of groups (e.g., if user1 is member of group2, which is member of group3, then the profile of user1 is /user/user1, /user/group2/user1, and /user/group3/group2/user1).
   2. Accessing a non-existing resource should be similar to behavior of wiki-pages - suggest similar existing resources, and a link to user / group creation (if permission allows).
   3. Possible collisions between usernames and group-names may be handled similarly to MultiRepos collisions between repository-names and nodes in the default repository.
   4. User / Group profile should also include a link to editing the attributes (according to permissions).
   5. Possible details to include in default user profile (possible reuse from ​UserManagerPlugin): the user attributes, group-membership, permissions, user activity (wiki, tickets, changesets, etc. - probably only most recent), history of attribute modifications.
   6. Possible details to include in default group profile: the group attributes, members and memberships, group-wide permissions, most recent history of group-members, history of attribute modifications.
8. Rendering and linking of user/group names / IDs:
   1. User-related fields in tickets (reporter, owner, cc) should be of type user list, and accept values as usernames / IDs / nicks etc. (I imagine auto-completion, and support for Ctrl+K-like-behavior from MS-Outlook in user-fields).
   2. User-related fields should be rendered using one of the available attributes (defaults to Trac nick, configurable from TracIni, overridable by user-preference). Possibly, different rendering contexts result different lists (from one-liner comma-separated list with some max-length for ticket view (think about how MS-Outlook lists recipients when there are many of them), to detailed tabular displays).
   3. Occurrences of user nicks / names should link to the user profile (#4588). This should be easy when the data appears in fields with user list type, but it is also desired that free-text occurrences (in wiki, comments, etc.) of user names / nicks will be recognized and rendered accordingly (I imagine a plugin that shows a floating user card when hovering over a username in wiki).
9. The UserSystem should be query-able, like the TicketSystem.
10. Some basic macros related to user & group information should be shipped with core (e.g. [[UserProfile(name)]], [[GroupMembers(group)]], etc.).
11. Administration: Given the wiki-like model within the user-realm, that should support actions like creating, editing, renaming and deleting users and groups, I think there's no need for dedicated administration panels.
12. Batch operations:
    1. It should be possible, from a user profile, to remove multiple group memberships or assign multiple group memberships.
    2. It should be possible, from a group profile, to remove multiple members or add multiple members.

Advanced use-cases

This section describes several advanced use-cases for the user-management systems that should be considered for further design and implementation.

Attribute-sets

(not even sure how to give a more descriptive title for this..)

The use-case is best described using a user story, revolving around the user bob:

• from jan-2000 bob was QA in proj-A.
• starting jan-2002 bob joined proj-B as a developer.
• in dec-2005 bob left proj-A.
• starting jan-2010, bob was promoted to team-leader in proj-B.

The UserSystem should be able to represent this transitional information, including the history, in a good way.

I would expect bobs profile to show details of current role(s) that bob has, including recent activity (maybe grouped by the different roles), but also show some reference to past roles.

In addition, I can imagine a future plugin that builds above this user-system to generate project-team structure and history, which should show that proj-B currently has bob as team-leader, but in the past had bob as developer, and similarly for proj-A, including the time-spans. Maybe also with a time-bar that allows visualizing the project team structure over time, and other time-span related statistics and charts (team size over time, commit / ticket activities from users over time, etc.).

I titled this use-case "Attribute-sets" since practically such behavior may be achieved by grouping several attributes-values together as a "set" (in the above story- a set includes the attributes (proj, role, start_date, end_date)) and assigning special semantics / model-behavior to the concept of "set".

Relation to GenericTrac

The dedicated reader might have noticed that many of the described requirements above include model-related stuff similar to existing wiki and ticket models.

Since the UserSystem doesn't already exist in Trac, and might introduce the most complex model so far, it might be a good candidate for the first system implemented above a GenericTrac infrastructure that may later also replace the existing models.

References

• The ​User Manager Plugin on trac-hacks.org.
• ​This thread on the Trac-Dev mailing list.

Related Tickets

closed status tickets:

#12

Write protected wiki pages

#222

'Assign to' as popup list

#1198

User filter for Timeline

#4497

AttributeError: 'long' object has no attribute 'astimezone'

#7339

[Patch] Display full user names instead of user login

#9311

MyTickets report fails on non authenticated anonymous users who have their email set in the preferences

#9514

Support list of users as options list in ticket custom field (copy of #8069 for 0.12)

#1347

remove old authenticated user sessions

#3107

Search Result Should Not Show Macros' Source

#3478

notification.py does not appear in trac 0.9.6

#3571

username and authname on wiki commit

#4266

Provide a list of users a ticket can be assigned to

#5242

[PATCH] Author filter on Timeline page

#5532

Login / User Admin

#6458

Timeline unnecessarily populates email_map from all known users

#6742

Failed to create environment. FATAL: Ident authentication failed for user "tracuser"

#7149

Improve TicketQuery and query: traclinks to allow insertion of logged in username

#7729

Group Managment

#7821

grouping doesn't work in default_query

#8057

Internal error after clicking user link

#8449

InterfaceError: Error binding parameter 0 - probably unsupported type.

#10683

AuthzPolicy does not handle non-ASCII encoded usernames

#12206

Notifications should use full name when [trac] show_full_names is True

#13634

cache invalidation for Environment::get_known_users can cause DB temp space exhaustion with MySQL backend

#1467

Custom Query should support a dynamic $USER variable

#4964

User filter for timeline

#7966

Provide default report for Tickets Reported By Me

new status tickets:

#4245

[PATCH] Tickets are slow with large amount of users and permissions

#4588

User Page: trac links to these pages

#5648

DefaultPermissionGroupProvider not doing its whole job

#9574

add filters to TicketQuery from query string arguments

#150

User-centric storage. Last-viewed information and 'intelligent' followup

#1804

[Patch] Strip off realm from usernames when using Kerberos

#2456

Implement API for user management

#2662

assign tickets to multiple users

#3737

login-id, trac-nick

#8335

Create People page with user profiles and status of who's doing what.

#8559

New Report: Tickets of Interest

#9740

Impossible to CC a username with spaces

#10736

env.get_known_users() should also return session.last_visit

#12210

Show username and email in tooltip when hovering over a full name

#2194

Make user credentials available to IPermissionStore & IPermissionGroupProvider component

#8681

[PATCH] Allow adding usernames to a ticket CC list