What is it?

FlexibleAssignTo finally gives long-suffering 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.

Key features:

• 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 -- FlexibleAssignTo abstracts the nastiness of building 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've never logged in and set their preferences.

• optional get_known_users() replacement that changes Trac's 'known users' concept such that users' name & email data is retrieved from the session_attribute table (designed to work in concert with the 'ensure_user_data' capability).

• FlexibleAssignTo processing can be selectively disabled for individual workflow states

• Example plugin implementation included (SampleValidOwnerProvider.py)

Installation

How do I install it?

Just like any other Trac (0.11) plugin.
Build the .egg file following the plugin packaging instructions ​here. If you already have setuptools (v0.6+) installed, your command is

python setup.py bdist_egg

Once you've built the .egg, copy it into your Trac environment's plugin directory. You still need to activate the plugin -- in trac.ini, add this line to the components section:

[components]
flexibleassignto.* = enabled

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' under 'How do I use it?' below).

Prerequisites

• Trac 0.11+ (built and tested against 0.11dev trunk r6047)
• Python 2.5+ (I can't confirm that Python 2.5 is actually required -- but it's the version I developed under and the only one I've tested with. If you successfully use this plugin with another version of Python, please update this wiki with your notes. - Morris)

How do I use it?

1. Try out the demo

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

1. 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.
2. 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 jump in and get your hands dirty, go check out the source for SampleValidOwnerProvider.py.
3. 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 like this:

   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 -- it's 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 (or do whatever else you need to do) to get back a list of user information -- in this case, (presumably) return the users who are members of either the "Admins" or "Development Managers" group. Each user's info should be packed into an instance of SimpleUser (or a subclass). 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). Again, see SampleValidOwnerProvider.py for a hopefully straightforward example. Note that individual workflow states can be disabled; see item 4, "Enable/disable individual workflow states", below.
4. the SimpleUser class
   There are three fields in SimpleUser that you *must* set. Not having these set (e.g., left as their default, None) will lead to assert exceptions from FlexibleAssignTo:

   SimpleUser.username 
   SimpleUser.option_value
   SimpleUser.option_display
   

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

Bugs/Feature Requests

Existing bugs and feature requests for FlexibleAssignToPlugin are here.

If you have any issues, create a ​new ticket.

Download

Download the zipped source from [download:flexibleassigntoplugin here].

Source

You can check out FlexibleAssignToPlugin from ​here using Subversion, or browse the source​ with Trac.

Example

See the 'How to install section' above for details. For an example of how to implement IValidOwnerProvider, see the included sample plugin SampleValidOwnerProvider.py.

Recent Changes

16706 by rjollos on 2017-07-12 15:53:02

FlexibleAssignTo 0.8.13: Fix export of interface and cleanup setup.py

Refs #13233.

16704 by rjollos on 2017-07-11 11:17:06

FlexibleAssignTo 0.8.13: Conform to PEP8

Refs #13233.

16703 by rjollos on 2017-07-11 11:06:16

FlexibleAssignTo 0.8.13: Default to leaving ticket owner unchanged

Patch by ash.

Fixes #13234.

(more)

Author/Contributors

Author: rfmorris (aka gt4329b)
Contributors: