Personal Stream of one user is editable by another user.
Hello ,
I have a short question regarding the permissions in DNG/GC where one user's personal stream is editable by another user.
Currently both the users have "Author" role in DNG and "Contributor" role in GC PA, The risks expected are :content intended for review is unintentionally changed and might be overseen before delivery to public stream happens
So, Is there any way to stop/restrict this ? Like restricting the permissions of personal GC streams from another user? Or Is this the expected behavior and we cannot do anything about this ?
Kind regards,
Srajan.
2 answers
The personal GC stream is to allow different configurations for that person, i.e. including Change Sets on ERM configurations, to be part of the 'standard' GC stream. This is required for linking from artifacts in one component stream to artifacts in another component stream (both must be in the same GC stream).
If you want to have some degree of 'security', to prevent people from making conflicting edits, there are several strategies you could use, the most common being:
- Enforce change set use in the ERM component streams - this encapsulates changes but other people with Author role in the component can still make edits in any change set (even if you think it's personal). Note, the more people who have Author role and the more open change sets you have at any point in time the more likely you are going to have to merge edit conflicts.
- Separate components into different project areas. The roles apply to all component streams within a project area - if you want to limit who can edit component streams (and change sets) you need to control who has Author role in the project area. The easiest way to limit the people who get edit rights to certain components is to create multiple project areas and split the components across them according to who should have edit rights (Author role).
Comments
Hello Haw,
Thanks for the info, but my usecase is a little different one :
Here lets assume User1 has created a changeset in GC context so this is a Personal Stream of User1 & User2 has somehow got this personal stream link(may be at the time of review process), So now as the User2 have the access to the changeset of User1 ,he/she can edit the module or add any artifacts or modify the state of the artifacts as these two users are from the same team area and have "Author" access to the component/stream.
May be locking entire module or all the artifacts inside the module may help but its a lot of manual effort.
So for this usecase do we have any permissions from IBM where we can limit the User2 operations from editing the module of User1.
Kind regards,
Srajan
May be locking entire module or all the artifacts inside the module may help but its a lot of manual effort.
So for this usecase do we have any permissions from IBM where we can limit the User2 operations from editing the module of User1.
Kind regards,
Srajan
@Srajan,
I understand your problem - the answer is maybe.
Permissions are allocated to roles and if user2 has a role in that ERM project area so that they can edit/save artifacts and links they can do that in any component stream/change set in that ERM project area (it has nothing to do with GCM permissions).
So the 'maybe' part of the answer is to give user2 a role, such as Commenter, that does not allow them to make any data changes BUT that permission applies to the entire project area, so if they need to edit in a different component stream in the same project area they will be blocked from working (as they can now only read & add review comments as a Commenter), therefore my point about splitting your components across multiple project areas.
The solution my be more or less work for you, depending on your use case.
This is by design. ELM is a server-based solution and while source code in EWM can be checked out and modified, requirements do not work this way.
This allows multiple users to see change sets in DOORS Next.
Think about a change set as "proposed changes" in DOORS Next. Change sets also are the audit trail! I can see the history of a requirement and all the change sets that touched it. If I don't have read access to every change set, then I can't do an audit, and I don't know what changes happened in what grouping!
There are permissions that can be enforced so that only the user who created the change set can deliver it (along with admins, natch) but there are also gating mechanisms with EWM if so desired.
In any case, this is one of those "careful what you wish for" type of scenarios. Proposed changes need to be visible by all so they can be reviewed, and then those change sets themselves need to be auditable, both before and after delivery.
Kevin Murphy
IBM Champion