Permissions problem during linking GitHub commits to IBM EWM workitems
Hello,
I want to allow only those users who have relevant roles and permission in IBM EWM project area to link the Git commits to IBM EWM Work-items.
But user is still able to link the commits to IBM EWM Work-items in below cases:
1. Has no access to that project area
2. Has Access to project area, but not the right role to make commits
I see there is a precondition on IBM EWM side call "Prevent Work Item linking if Author is not owner." even this seems to be not working.
Does anyone tested this behavior ? Any hints on how I can avoid user from linking Git commits if he don't have right role / permissions in IBM EWM ?
Thanks
3 answers
Hi Rakesh
The pre-conditions only works when using Git pre-receive and post-receive hooks for integration on Github Enterprise
In case you are using https://github.com and have configured webhooks for the integration, then the preconditions wont work.
Thanks and Regards
Shubjit
Comments
Hi Shubjit,
Thanks for your feedback. I have a question: In my case, I have GitHub Enterprise over cloud and I am using GitHub Actions runner instead of WebHooks (because IBM ELM server is over on-prem network).
Do you have some clues whether it works fine for my configurations ?
Thanks
Rakesh
Hi Rakesh
For the pre-conditions to work you would have to use the hooks provided by our Git-integration-tool-kit. You can look at the pre-receive hook in our toolkit "Git-Server-Toolkit-7.0.2/server/hooks/examples/githubee"
Download toolkit - https://jazz.net/downloads/workflow-management/releases/7.0.2/Git-Server-Toolkit-7.0.2.zip
I am not sure if this works with the Actions runner. Our instructions talks about having access to the Github EE administrative shell. hooks https://www.ibm.com/docs/en/elm/7.0.2?topic=operations-creating-pre-receive-hooks
Thanks and Regards
Shubjit
In almost all cases where I have seen allegations that mysterious behavior with respect to operational behavior and permissions has been claimed to be spotted, it was related to a lack of understanding of how operational behavior and permissions really work in EWM.
The most important articles would be:
Note: user usually has multiple roles.
If the user has not access to the project area, there is no way for them to be able to create a link to the work Item. The user simply has not even read access to the work item in such a case. The user has no access to the project area would mean that the access to the project area is guarded e.g. access restrictions are configured by access groups or project area membership etc...
This is assuming that the GIT integration does not delegate the operation to a technical user for the link operation, in which case the link would not be created by the user. At the moment my assumption is that the real user performing the operation is used and not a technical user.
I do not know the precondition. In the past I have seen a lot of issues with understanding how to configure those and when they execute.
There is not a lot of real data above that would prove the claims. I would suggest
I do not know the precondition. In the past I have seen a lot of issues with understanding how to configure those and when they execute.
There is not a lot of real data above that would prove the claims. I would suggest
1. Provide more configuration details or
2. To reach out to support.
When you register the Git repository you can select the Controlling Process Area, which lets you set which project area or team area is in control.
In addition you can map Git branches to teams in order to manage which team is allowed to check into a branch - that's under Mapped Git References.
You can also set the Controlling Process Area as the default for any unmapped Git references.
Once this is set up, you can then add the Git Push precondition "Prevent Associations to External Work Items", which will:
"Allow Git commits to be pushed only if the process area that governs the Git repository and the project area for associated IBM Engineering Workflow Management work items are the same or in the same project area hierarchy. To further restrict associations to the same team area, select Restrict work item linking to team area."
If users aren't members of the team area they won't be able to access the work item to push against it