Event listener: Restrict task status updates

[Lucas Correia]

Hi,

I've created an example event listener which can be used to restrict which users should be allowed to set certain statuses. I thought it would be useful for the rest of the community and wanted to share it here. Let me know if you have any questions or feedback.

 

You can find the snippet on bitbucket.

 

Event listener: Restrict task status updates

The event listener can be used to limit which users are allowed to set certain statuses. When a status is changed in the ftrack interface, the event listener will check if the status is restricted, and if the user is member of the group with users that are allowed to set to those statuses. If not, the status will be reverted to the old value, and a message will inform the user that the operation was not permitted.

 

Configuration

To use the event listener, first set the two variables at the top:

RESTRICTED_STATUSES
    A list of task status names that are restricted, only the members of a
    group will be allowed to change these.

ALLOWED_GROUP_NAME
    The name of the group in ftrack which contains the users that are allowed
    to set the restricted statuses.

Quote

The API user running the event listner must be a member of the group, otherwise it might end up in an infinite loop when changing between two restricted statuses.

 

Running the event listener

You can run the event listener from the command line::

python restrict_task_status_listener.py

You can also register the event listener as a plugin. For more information, see the links below.

Quote

You can use something like Supervisor or Monit to monitor and ensure the event listener is always running.

 

Read more

Find more information in our documentation:

* Developing: Events
* Event: Action - trigger interface
* Event: Update
* Managing statuses
* Organizing users into groups
* Python API: Configuring plugins
* Python API: Environment variables

[Martin Pengelly-Phillips]

Looks interesting! 

However, do you think it will be possible in future to validate the change in-line and actually block it from happening at all?

My concern with the current approach of resetting values after the fact is that the revert is easily missed by the user and it also introduces race conditions with other event listeners (that might do something based on the original change).

 

[Lucas Correia]

Thanks Martin,

It is certainly a possibility that we add these restrictions "properly", but it is not something that we have planned at the moment.

The event listener communicates back to the user using the new ftrack.action.trigger-user-interface event, but I agree that it's still not as a good experience as if this had been fully supported. Should you want to, you can use the form or widget types instead to display a modal dialog which has to be dismissed by the user. 

Regards,
Lucas

[Martin Pengelly-Phillips]

Ah - interesting about the modal dialog.

However, that would still leave the more difficult issue of other actions firing as a result of the event even though it would be reverted. A way to have tighter integration would make sense (a validate event?).  I guess performance would be the main concern here, but that could be up to us to manage if it was an optional configuration.