Customize the 'assign to' field on tickets
This plugin gives Trac admins a way to easily customize the 'assign to' field on tickets. It provides several base classes for you to override and implement your own methods for providing lists of valid users. You can even customize valid users for each state in your workflow.
- Adds new Extension point, IValidOwnerProvider, for plugging in your own components.
- Provides SimpleUser base class and helper methods (getlist, getbool) to streamline implementation of your IValidOwnerProvider component(s).
- Data source agnostic: this plugin removes the need to build a customized 'assign to' select box. All your custom code has to do is decide what users are valid for a particular state and then return them.
- Optional 'ensure_user_data' capability so that users who appear as valid 'assign to' targets get their key data (username, fullname, email) stored in the Trac session_attribute table. The motivation for this was so notification emails could be sent to these users, even if they have never logged in and set their preferences.
- Optional get_known_users() replacement that changes Trac's 'known users' concept such that users' name and email data is retrieved from the session_attribute table, designed to work in concert with the 'ensure_user_data' capability.
- Processing can be selectively disabled for individual workflow states.
- Example plugin implementation SampleValidOwnerProvider.py is included.
Note: The plugin by itself doesn't do anything. You have to write your own plugin/component that implements IValidOwnerProvider, see Create your IValidOwnerProvider component.
Note: The framework does not modify the fields on the "New Ticket" page. It only operates on the fields as rendered on existing tickets. This is a common misunderstanding and has in fact been filed as a bug/feature request (#2634). Make sure to verify your install is working by installing the included SampleValidOwnerProvider plugin and examining an existing ticket.
If you have any issues, create a new ticket.
Download and Source
- latest/trunk rev: download the zipped source from here.
- Binaries: all zips include sample plugin SampleValidOwnerProvider.py:
This plugin requires Trac 0.11+, and it was built and tested against 0.13dev-r10668 on Python 2.7.1.
To install this plugin:
Activate the plugin either with WebAdmin or by editing your trac.ini as follows:
[components] flexibleassignto.* = enabled
1. Try out the sample plugin
Once you've installed the base FlexibleAssignTo plugin, copy the SampleValidOwnerProvider.py file from the install package into your Trac environment's plugin directory alongside the FlexibleAssignTo .egg. Restart your server and note the new (bogus) entries in your 'assign to' dropdowns.
2. Create your IValidOwnerProvider component
- Create a .py file in your Trac environment's plugins directory
This module is where you'll write your own class that implements the IValidOwnerProvider Extension point provided by FlexibleAssignTo. This is where your custom logic goes for deciding what users should appear as valid 'assign to' targets for each state, whether that logic involves querying a database, searching an LDAP directory, or getting some sort of data from your custom-built array of highly trained homing pigeons. See the SampleValidOwnerProvider.py module included with this plugin for a simple example on how it works.
- Implement IValidOwnerProvider component requirements
This module must contain a class that:
- declares that it implements IValidOwnerProvider
- provides a getUsers method that takes a 'next_action_obj' as it's sole param and returns a list of instances of SimpleUser (or a subclass) representing valid owners of that next state. Keep reading for details on the getUsers() method and the SimpleUser class. If this sounds confusing and/or you just want to experiment, go check out the source for SampleValidOwnerProvider.py.
- the getUsers() method
The sole param to getUsers(), next_action_obj, represents a workflow state that is available from the current ticket state AND that implements the "set_owner" operation (if you really want to get into the nitty gritty, next_action_obj is identical to the objects in the ConfigurableTicketWorkflow.actions list in trac/ticket/default_workflow.py). next_action_obj is provided to getUsers for the sole purpose of providing a way to look up custom workflow state params. For example, if you had a workflow state defined in your trac.ini:
mystate = oldstate -> mystate mystate.name = my whoopass state mystate.operations = set_owner mystate.permissions = TICKET_MODIFY ; .valid_user_groups is a param that you add and is not part of the default Trac workflow syntax mystate.valid_user_groups = Development Managers, Admins
Then in your getUsers method your code would look something like this, to retrieve these values from this workflow state:allowed_groups = getlist(next_action_obj, 'valid_user_groups')
You could then use the 'allowed_groups' list to query a database to get back a list of user information; in this case, return the users who are members of either the "Admins" or "Development Managers" group. Each user's info should be packed into an instance (or subclass) of SimpleUser. The final return from getUsers() should be a *unique* list of SimpleUser instances. No checks for uniqueness are guaranteed to be performed on the list of returned users. See SampleValidOwnerProvider.py for an example. Note that individual workflow states can be disabled; see item 4, "Enable/disable individual workflow states", below.
- the SimpleUser class
There are three fields in SimpleUser that you *must* set. Not having these set, eg left as their default None, will lead to assert exceptions from FlexibleAssignTo:
SimpleUser.username SimpleUser.option_value SimpleUser.option_displayThere are standard get/set methods for these; see the SimpleUser class for specific method prototypes.
Note: the format of username values *must* match the format of usernames for logged-in users: if John Doe logs in with the username "jdoe", then a SimpleUser instance representing John Doe should get its username attribute set to "jdoe". If you don't do this, FlexibleAssignTo will not work correctly.
3. Configuration options
The following options should be specified in the [flexibleassignto] section of your trac.ini.
Defaults to false.
FlexibleAssignTo also provides functionality to ensure that key user data (username, fullname, email) is added to the trac session_attribute table as said user data is retrieved for "assign to" use, so that ticket assign/modification emails will be sent to the assigned user's email address.
Note: this feature will not overwrite session_attribute data already present.
Defaults to false.
Overrides the default get_known_users capability provided by default Trac (trac.env) method of the same name: whereas the Trac default get_known_users returns info only for those users who have logged in, this method returns info for every user who has data in the session_attribute table and is flagged authenticated, eg session_attribute.authenticated = 1. This functionality was designed to work in concert with the "ensure_user_data" feature, which auto-populates user email & name in the session_attribute table. Generates one tuple for every user, of the form (username, name, email), ordered alphanumerically by username.
Note: Changes to this setting require a server restart to take effect.
Note: You should also enable the ensure_user_data option if you use this method, otherwise the behavior will be superficially no different than the default Trac get_known_users functionality.
Here is the section that should be added to your trac.ini:
[flexibleassignto] ensure_user_data = false use_custom_get_known_users = false
4. Enable/disable individual workflow states
Finally, note that by default FlexibleAssignTo operates on every state in your workflow, replacing the "assign to" field for every state with a "set_owner" operation. To disable FlexibleAssignTo for particular states without having to disable the entire plugin, add the following key to your workflow state:mystate.use_flexibleassignto = false
For an example of how to implement IValidOwnerProvider, see the included sample plugin SampleValidOwnerProvider.py.
- 10083 by gt4329b on 2011-04-14 20:33:48
- added 0.13 rev; no major functional differences from 0.11 other than modernization of the DB API interactions, using the recommended forms for 0.13 from http://trac.edgewall.org/wiki/TracDev/DatabaseApi
- 10067 by gt4329b on 2011-04-11 16:12:41
- updated version to 0.7.13
- 10066 by gt4329b on 2011-04-11 16:01:42
- updated flexibleassignto.py core to work properly with 0.11release+ versions of Trac (thanks chris!)
- updated AUTHORS to note contribution from chris on #3494
- updated README version compatibility notes
(12.9 KB) -
added by gt4329b 9 years ago.
Zip containing FlexibleAssignTo-0.6-py2.5.egg and SampleValidOwnerProvider.py
(18.1 KB) -
added by gt4329b 5 years ago.
Contains FlexibleAssignTo-0.7.13-py2.7.egg and the SampleProvider plugin
- FlexibleAssignTo-0.8.13-py2.7.zip (18.3 KB) - added by gt4329b 5 years ago.
Download all attachments as: .zip