Implement Portfolio Access Control - Part 2

[stevespringett]

Ticket #140 describes the initial support for Portfolio ACLs (beta) and covers the majority of cases. However, there are known gaps and these gaps will be implemented in this ticket.

Known gaps include:

• AnalysisResource
• NotificationRuleResource
• PolicyResource
• SearchResource
• ViolationAnalysisResource

In addition, all resources where ACL logic is performed, should include a notification in the audit log for tracking purposes. This will be implemented as part of this enhancement.

[stevespringett]

Moving out a release to (hopefully) get feedback from the ACL logic introduced in v4.3. So far, no positive or negative feedback.

[Carsten-Berndt]

First tests look good.

I noticed, that if access control is enabled and a user has the PORTFOLIO_MANAGEMENT permission, they can create a new project but are not automatically added to its ACL and therefore cannot interact with it.
As it currently stands a user that needs to create projects has to also have the ACCESS_MANAGEMENT permission when access control is enabled or ask a user with that permission to alter the ACL for the new project.
To fix this I propose, that the user should be enabled to provide one or more of their teams that should be added to the projects ACL at creation.

I also think it would be useful to add a project owner. That project owner would then be given ACCESS_MANAGEMENT within the scope of their project as proposed by @nibiwodong . The initial project owner would be the creator of the project.
That would move the responsibility to manage project access away from the system administrator to the project responsible.
As a nice side effect it would also provide an easy way to identify the information owner, which is a requirement in some corporate environments.