Changes between Initial Version and Version 1 of TracDev/Proposals/UserSystem

Timestamp:

Oct 16, 2010, 12:49:13 PM (14 years ago)

Author:

Itamar Ostricher

Comment:

Initial proposal (requirements analysis) for UserSystem

TracDev/Proposals/UserSystem

@@ +1 @@
+[[PageOutline(2-3)]]
+= 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.
+1. 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).
+ 1. Possible extras: employee-ID, birthday.
+1. ''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.
+ 1. Groups may have users (zero or more) or other groups (zero or more) as members.
+1. 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).
+ 1. 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).
+ 1. 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.
+1. 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?
+1. Permissions related to user-management should be introduced (e.g. `CREATE_USER, DELETE_USER, MODIFY_USER, MODIFY_USER_SELF, VIEW_USER`, similarly for `GROUP`s, ...)
+1. 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`).
+ 1. 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).
+ 1. Possible collisions between usernames and group-names may be handled similarly to MultiRepos collisions between repository-names and nodes in the default repository.
+ 1. ''User / Group profile'' should also include a link to editing the attributes (according to permissions).
+ 1. Possible details to include in default ''user profile'' (possible reuse from [th:UserManagerPlugin]): the user attributes, group-membership, permissions, user activity (wiki, tickets, changesets, etc. - probably only ''most recent''), history of attribute modifications.
+ 1. 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.
+1. 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).
+ 1. 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).
+ 1. 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).
+1. The !UserSystem should be query-able, like the !TicketSystem.
+1. Some basic macros related to user & group information should be shipped with core (e.g. `[[UserProfile(name)]]`, `[[GroupMembers(group)]]`, etc.).
+1. 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.
+1. Batch operations:
+ 1. It should be possible, from a ''user profile'', to remove multiple group memberships or assign multiple group memberships.
+ 1. 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 #AttrSets
+(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 [TH:UserManagerPlugin User Manager Plugin] on trac-hacks.org.
+- [http://groups.google.com/group/trac-dev/t/3625ea16c2876825 This thread] on the Trac-Dev mailing list.
+
+=== Related Tickets
+[[TicketQuery(group=status,order=priority,col=summary|component|milestone,format=default,keywords=~user)]]