User privileges

0

Hi Joanna,

When it comes to privileges - you can set them in three kinds of 'global' scopes:
* System
* Process
* Workflow/Form
Those are pretty well summed up in built in documentation (attached screenshot)

If you will not give user/group permissions to read all documents in any of global scopes, then by default user receives read permissions when you assign him task on a document. It will last untill you will explicitly remove it with action (if i remember correlty). But i don't think this one will be enough here though.

You can also use add/remove privileges action as described here: https://community.webcon.com/posts/post/the-addremove-privileges-action/254/18.

If users shouldn't see all instances, then don't give them permission through any global scope to read documents.
On the project update process (it seems to me more like a workflow in some projects process, a small suggestion) you will need some way to choose who should get specific privileges, to what project.

I'll assume that Project is the parent workflow, and Project Update is sub workflow - configuration might look something like attached screenshot.
Consider checkbox 'Should privilege expire after using a path'.

Setting permissions with actions might become messy so give it a moment to test how it works :)

Hi Joanna,
I don't know if I understood the described assumptions correctly, but in general, if you set the group: Software Engineer, with all users as a group with permission to read all elements on a process or on a form type, it will always have overriding right and all members of this group all elements of a given process , the type of form they will see. To manage the permissions to read the form, remember that the author, the person to whom the task will be assigned, will get the permission to read a given element and these permissions for this element will remain, unless you use the "revoke permission" action and you will revoke these permissions from them. permissions for an item can be checked in the table: select * from WFSecurities
and you can check the permission level in select * from DicSecurityLevels

Here, when creating a new element/project, you can manage who to revoke and grant permissions to the element. (you can e.g. remove all and give only the ones you need, the permissions of the overriding process/form type will not be removed).

You can also create a BPS group action for each project when creating a project and also add and remove members with actions. and the group itself, when registering, set the action as a group with read permissions for a given wfd_id, a given element. (here it is also necessary to take care to properly remove the permissions granted by someone being the author or having an assigned task, it is important not to take away the permissions from people who are assigned a task to perform)

As for filtering, you can create, for example, a one-step workflow without paths, not registered, only after clicking on the tile you can choose filtering attributes, e.g. project, user, and sql grid, in which you display a list of users from WFSecurities, plus if you operate through a group, a list of members groups for the item, and the necessary information from the process as a sql statement.

If you want to use the webpart/report, you should take care to update these people to some technical field, such as a picker, or a list of items, and then you will be able to narrow down/filter the report after these fields.