Restrict a role from adding Part items to a change

I am working on a config update that splits create/modify privileges for users in our Agile system into roles for PARTS and for DOCUMENTS.
I have created a new role and moved all the privileges that apply to parts to this new role. So far so good. Users without the new Part role cannot Create/SaveAs/Modify parts.
They can however add it to a change and route it, though they would not be able to make any changes/redlines to the item.

I want to prevent them from being able to add Parts to a change altogether if I can, or if not, prevent them from assigning a WF whenever a part is added as Affected Item.

I have tried to do this from a high level SM Criteria, basically duplicating the existing SM for all Change Ordes / Change Requests / Lifecycle Changes and creating one applied to Parts and one applied to Non-Parts (resulting in 6 instead of 3 SM criteria).

However, the system does not allow Modify Privileges applied to Affected Item/Part Type at that level (The new criteria are simply not visible for the modify privilege).

Does that mean I need to go at it the individual change subclasses (we have 2 for CO, 2 for CR and 3 for LC) which would result in a lot of new criteria.
Or is there a more elegant solution?

Thanks as always for the shared wisdom!

Add Comment
4 Answer(s)

Hi Runemeijer,

have you thought about to create/modify a change’s modify privilege? If you remove the properties regarding to change affected items attributes, you’ll disable the ability to modify the affected items tab.
Does it make sense?

My best
Carlos

Agile Angel Answered on February 9, 2017.

Hi Carlos,

Thanks for your reply.

I believe what you are describing is similar to what I wrote in my question.

The issue is that I don’t want to prevent users from modifying the Affected Items tab of a change. i want to ensure that a user who has a Document-Champion role can only add documents to a change and a user with a Part-Champion role can add Parts to a change.

Agile prevents me from assigning criteria on the change class to modify privileges, so it looks like it will need to be built on the change subclass level which will result in a lot of criteria and privileges to differentiate between Part and Document roles for all the change types/subclasses.

I was hoping there would be a simpler/more elegant solution than that.

Create rights were very much bundled before, so this is new for us (new requirements for master data management)

Thanks again,

Rune

on February 9, 2017.
Add Comment

Hi, Rune,

If I understand correctly, your requirement, is: a Part should not be allowed to be added as an Affected Item on a Document-related Change/Workflow, and vice–versa, right??

Although it seems to me that Agile does not prevent you to add any routable object to any Change, you could develop a sanity check on the worflow itself  (supposing you have different workflows and Changes, for Parts and for Documents) by creating a Criteria Usage on the Criteria window of the Pending Status where you would indicate which object type is allowed to participate on the workflow.

Please correct me if  I’m wrong

Best regards,

Agile Talent Answered on February 9, 2017.

Thanks Clovis,
After some deliberation I also saw that it would need to be controlled at the workflow level, which makes sense but also involves some consequences for the way changes are handled. Ideally the roles would be hierarchical and the users with Part creation roles would be able to create and route changes for both parts and documents.
Thanks again for your input!
Rune

on February 9, 2017.
Add Comment

The simplest way to take care of your issue is to create a change object for parts and one for documents.  Then you could very easily segregate the two functions without worry that someone with doc privileges can route a change for parts and vice versa.  This would definitely be the cleanest path.

Agile Angel Answered on February 9, 2017.

that would be very clean indeed!
In an ideal world, with a new system 🙂

Now at least I have something to go back to the business with; either have a process that allows parts to be routed on changes where the change privileges govern what a user can do to them
or go back and re-draw the way changes are handled in the system.

Thanks so much for your reply Patrick!

on February 9, 2017.
Add Comment

“I want to prevent them from being able to add Parts to a change altogether if I can, or if not, prevent them from assigning a WF whenever a part is added as Affected Item.”

I might be missing something here, but you should be able to prevent users from selecting a workflow based on affected item type through the Matching Criteria and Workflow Matching Criteria Type on the Workflow itself.

I.E.
Matching Criteria = “Change Orders with Document Affected Items” 
Workflow Criteria Matching Type = Same 

The Matching Criteria here would only allow the workflow to be selected if there is a Document on the Affected Items Tab
The Matching Criteria Type would prevent Parts AND Documents being added as all affected items have to meet the same matching criteria.  

Agile Angel Answered on February 9, 2017.

Hi Danny,

Thanks for your reply.

I think your comment is right on the mark and confirms the discussion above, in that it is possible to restrict parts or documents to be added to a particular workflow, when the individual WF determines whether or not it can route parts and/or documents.

I was looking for a way to control it based on user role, allowing me to leave the workflows alone as they are.

Having removed the ‘part’ related privileges from the the ‘documents’ role I can see the user can no longer create new/saveas/checkin/checkout any part items. When on a change, these privileges affect the ‘Redlines’ section of the affected items tab. The actual Affected item section is controlled by the change privileges and it looks like Agile won’t allow me to restrict the ItemType attribute there…

Cheers,

Rune
 

on February 10, 2017.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.