Select user reading rights at subproject level

[SophieKettler]

In the current version of TB, whenever a new workflow item is being created, one has to assign the different user rights (again). This is timeconsuming and complex. There should be a possibility to assign reading rights to all relevant users of a subproject at once ...

[mathiashoeld]

@SophieKettler for this usecase we introduced the feature of "batch editing", i.e. you can select multiple workflow items and set all the rights you need.

[SophieKettler]

Hi @mathiashoeld : I am aware of the "Batch editing" fonction - and it works fine when you create workflow items at the beginning of a project. However, during project implementation you will need to add a new workflow item. If you then have to use the "Batch editing" every time you create a new workflow item to assign different user rights, it's timeconsuming and not user-friendly. (This is the feedback from the user tests... and we discussed it in ydays Dev Call)

[Stezido]

Hi @SophieKettler, you are right, the "Batch editing" feature isn't the right feature for your issue. It's only useful when creating multiple workflowitems. In your case you want to grant multiple permissions for multiple user on one workflowitem. To address multiple user the group feature can be used, but multiple permissions can only be granted separately. On workflowitem level there are view, assign, update close, show, grant and revoke permissions.

So the fastest way to create a workflowitem with view permissions on multiple user is (current workflow):

1. Define a group containing all user (once)
2. Create a workflowitem
3. Grant view permissions to the previous created group

The solution may not hide events executed in the background. Means if a workflowitem shall be created and additional events shall happen like granting permissions, the user has to be informed about these events. So a confirmation dialog is needed to create a workflowitem with inherited view permissions.

So the updated workflow looks like this:

1. Create a workflowitem and check a checkbox saying "Use subprojects view permissions"
2. After clicking on create a confirmation dialog opens which shows a list of granting view permission events happening after confirmation.

I am not sure if the updated workflow is more efficient than the old one in case of granting view permissions. The advantage of the updated workflow is that

• no group has to be created
• the group/multiple user hasn't to be known by the workflowitem creator but can be checked in the confirmation list
• granting more than only view permissions (write, admin) would be less time consuming or complex.

@SophieKettler What are your thoughts? Is the updated workflow less time consuming/ complex in your case? Did i miss or misunderstand anything?

[mathiashoeld]

@Stezido nice summary, thanks.

[SophieKettler]

Hi @Stezido & @mathiashoeld, thanks for the explanation. Will contact you on Wednesday morning to discuss it.

[Stezido]

As it turns out granting permissions to a group is not working as expected. The current workflow is only time-consuming if groups are working properly. I raised an Issue (#440) to fix this group issue.

[Stezido]

Issue #440 was fixed by #443. It was released with v1.8.0. @SophieKettler Is the current workflow described earlier sufficient for your needs including the bugfix?

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity for 30 days. It will be closed if no further activity occurs. Thank you for your contributions.