GabrielBrascher commented on a change in pull request #145:
URL:
https://github.com/apache/cloudstack-documentation/pull/145#discussion_r468536864
##########
File path: source/adminguide/projects.rst
##########
@@ -32,17 +32,38 @@ You can configure CloudStack to allow any user to create a
new project,
or you can restrict that ability to just CloudStack administrators. Once
you have created a project, you become that project’s administrator, and
you can add others within your domain to the project. CloudStack can be
-set up either so that you can add people directly to a project, or so
-that you have to send an invitation which the recipient must accept.
-Project members can view and manage all virtual resources created by
-anyone in the project (for example, share VMs). A user can be a member
-of any number of projects and can switch views in the CloudStack UI to
-show only project-related information, such as project VMs, fellow
-project members, project-related alerts, and so on.
-
-The project administrator can pass on the role to another project
-member. The project administrator can also add more members, remove
-members from the project, set new resource limits (as long as they are
+set up to either add people directly to a project, or to send an
+invitation which the recipient must accept. Project members can view
+and manage all virtual resources created by anyone in the project
+(for example, share VMs). A user can be a member of any number of projects
+and can switch views in the CloudStack UI to show only project-related
information,
+such as project VMs, fellow project members, project-related alerts, and so on.
+
+From CloudStack 4.15 onwards, it is possible for a project to have
+multiple project administrators and to add/invite specific users of
+an account to a project in addition to adding accounts. By means of
+Project Roles associated with a user or an account of the project,
+it is possible to restrict access of users in a project, i.e., in
+addition to account-level roles, one can further restrict access to
+operations (or APIs) by associating a project-level role to the
+user or account. However, If an account has already been added, one will not
+be able to associate a role a specific user of that account.
+
+**NOTE:** Project Roles work over Account level Roles. If a user/account is
+added to a project without a project role, it would imply that the
+user / account added will have access to all APIs that are made available
+by the Account level role. If there are no specific deny rules in the
+project role, it would again fallback onto the account-level role to decide
+whether the user has permissions to perform a specific action. It is also to be
+noted that Project roles are restricictive in nature, i.e., to say that, one
may
Review comment:
restricictive :arrow_right: restrictive
##########
File path: source/adminguide/projects.rst
##########
@@ -32,17 +32,38 @@ You can configure CloudStack to allow any user to create a
new project,
or you can restrict that ability to just CloudStack administrators. Once
you have created a project, you become that project’s administrator, and
you can add others within your domain to the project. CloudStack can be
-set up either so that you can add people directly to a project, or so
-that you have to send an invitation which the recipient must accept.
-Project members can view and manage all virtual resources created by
-anyone in the project (for example, share VMs). A user can be a member
-of any number of projects and can switch views in the CloudStack UI to
-show only project-related information, such as project VMs, fellow
-project members, project-related alerts, and so on.
-
-The project administrator can pass on the role to another project
-member. The project administrator can also add more members, remove
-members from the project, set new resource limits (as long as they are
+set up to either add people directly to a project, or to send an
+invitation which the recipient must accept. Project members can view
+and manage all virtual resources created by anyone in the project
+(for example, share VMs). A user can be a member of any number of projects
+and can switch views in the CloudStack UI to show only project-related
information,
+such as project VMs, fellow project members, project-related alerts, and so on.
+
+From CloudStack 4.15 onwards, it is possible for a project to have
+multiple project administrators and to add/invite specific users of
+an account to a project in addition to adding accounts. By means of
+Project Roles associated with a user or an account of the project,
+it is possible to restrict access of users in a project, i.e., in
+addition to account-level roles, one can further restrict access to
+operations (or APIs) by associating a project-level role to the
+user or account. However, If an account has already been added, one will not
Review comment:
`However, If` :arrow_right: `However, if`
##########
File path: source/adminguide/projects.rst
##########
@@ -32,17 +32,38 @@ You can configure CloudStack to allow any user to create a
new project,
or you can restrict that ability to just CloudStack administrators. Once
you have created a project, you become that project’s administrator, and
you can add others within your domain to the project. CloudStack can be
-set up either so that you can add people directly to a project, or so
-that you have to send an invitation which the recipient must accept.
-Project members can view and manage all virtual resources created by
-anyone in the project (for example, share VMs). A user can be a member
-of any number of projects and can switch views in the CloudStack UI to
-show only project-related information, such as project VMs, fellow
-project members, project-related alerts, and so on.
-
-The project administrator can pass on the role to another project
-member. The project administrator can also add more members, remove
-members from the project, set new resource limits (as long as they are
+set up to either add people directly to a project, or to send an
+invitation which the recipient must accept. Project members can view
+and manage all virtual resources created by anyone in the project
+(for example, share VMs). A user can be a member of any number of projects
+and can switch views in the CloudStack UI to show only project-related
information,
+such as project VMs, fellow project members, project-related alerts, and so on.
+
+From CloudStack 4.15 onwards, it is possible for a project to have
+multiple project administrators and to add/invite specific users of
+an account to a project in addition to adding accounts. By means of
+Project Roles associated with a user or an account of the project,
+it is possible to restrict access of users in a project, i.e., in
+addition to account-level roles, one can further restrict access to
+operations (or APIs) by associating a project-level role to the
+user or account. However, If an account has already been added, one will not
+be able to associate a role a specific user of that account.
+
+**NOTE:** Project Roles work over Account level Roles. If a user/account is
+added to a project without a project role, it would imply that the
+user / account added will have access to all APIs that are made available
+by the Account level role. If there are no specific deny rules in the
+project role, it would again fallback onto the account-level role to decide
+whether the user has permissions to perform a specific action. It is also to be
+noted that Project roles are restricictive in nature, i.e., to say that, one
may
+not allow a user to perform an operation that is NOT allowed at Account level.
Review comment:
NOT allowed at Account level :arrow_right: NOT allowed at **the**
Account level
##########
File path: source/adminguide/projects.rst
##########
@@ -32,17 +32,38 @@ You can configure CloudStack to allow any user to create a
new project,
or you can restrict that ability to just CloudStack administrators. Once
you have created a project, you become that project’s administrator, and
you can add others within your domain to the project. CloudStack can be
-set up either so that you can add people directly to a project, or so
-that you have to send an invitation which the recipient must accept.
-Project members can view and manage all virtual resources created by
-anyone in the project (for example, share VMs). A user can be a member
-of any number of projects and can switch views in the CloudStack UI to
-show only project-related information, such as project VMs, fellow
-project members, project-related alerts, and so on.
-
-The project administrator can pass on the role to another project
-member. The project administrator can also add more members, remove
-members from the project, set new resource limits (as long as they are
+set up to either add people directly to a project, or to send an
+invitation which the recipient must accept. Project members can view
+and manage all virtual resources created by anyone in the project
+(for example, share VMs). A user can be a member of any number of projects
+and can switch views in the CloudStack UI to show only project-related
information,
+such as project VMs, fellow project members, project-related alerts, and so on.
+
+From CloudStack 4.15 onwards, it is possible for a project to have
+multiple project administrators and to add/invite specific users of
+an account to a project in addition to adding accounts. By means of
+Project Roles associated with a user or an account of the project,
+it is possible to restrict access of users in a project, i.e., in
+addition to account-level roles, one can further restrict access to
+operations (or APIs) by associating a project-level role to the
+user or account. However, If an account has already been added, one will not
+be able to associate a role a specific user of that account.
+
+**NOTE:** Project Roles work over Account level Roles. If a user/account is
+added to a project without a project role, it would imply that the
+user / account added will have access to all APIs that are made available
+by the Account level role. If there are no specific deny rules in the
+project role, it would again fallback onto the account-level role to decide
Review comment:
fallback :arrow_right: fall back
##########
File path: source/adminguide/projects.rst
##########
@@ -32,17 +32,38 @@ You can configure CloudStack to allow any user to create a
new project,
or you can restrict that ability to just CloudStack administrators. Once
you have created a project, you become that project’s administrator, and
you can add others within your domain to the project. CloudStack can be
-set up either so that you can add people directly to a project, or so
-that you have to send an invitation which the recipient must accept.
-Project members can view and manage all virtual resources created by
-anyone in the project (for example, share VMs). A user can be a member
-of any number of projects and can switch views in the CloudStack UI to
-show only project-related information, such as project VMs, fellow
-project members, project-related alerts, and so on.
-
-The project administrator can pass on the role to another project
-member. The project administrator can also add more members, remove
-members from the project, set new resource limits (as long as they are
+set up to either add people directly to a project, or to send an
+invitation which the recipient must accept. Project members can view
+and manage all virtual resources created by anyone in the project
+(for example, share VMs). A user can be a member of any number of projects
+and can switch views in the CloudStack UI to show only project-related
information,
+such as project VMs, fellow project members, project-related alerts, and so on.
+
+From CloudStack 4.15 onwards, it is possible for a project to have
+multiple project administrators and to add/invite specific users of
+an account to a project in addition to adding accounts. By means of
+Project Roles associated with a user or an account of the project,
+it is possible to restrict access of users in a project, i.e., in
+addition to account-level roles, one can further restrict access to
+operations (or APIs) by associating a project-level role to the
+user or account. However, If an account has already been added, one will not
+be able to associate a role a specific user of that account.
Review comment:
What do you think of changing:
> one will not be able to associate a role a specific user of that account
:arrow_right: _one will not be able to associate a role **to** a specific
user of that account_
or maybe **of** instead of **to**, but I think that **to** is the right one
for the context
##########
File path: source/adminguide/projects.rst
##########
@@ -32,17 +32,38 @@ You can configure CloudStack to allow any user to create a
new project,
or you can restrict that ability to just CloudStack administrators. Once
you have created a project, you become that project’s administrator, and
you can add others within your domain to the project. CloudStack can be
-set up either so that you can add people directly to a project, or so
-that you have to send an invitation which the recipient must accept.
-Project members can view and manage all virtual resources created by
-anyone in the project (for example, share VMs). A user can be a member
-of any number of projects and can switch views in the CloudStack UI to
-show only project-related information, such as project VMs, fellow
-project members, project-related alerts, and so on.
-
-The project administrator can pass on the role to another project
-member. The project administrator can also add more members, remove
-members from the project, set new resource limits (as long as they are
+set up to either add people directly to a project, or to send an
+invitation which the recipient must accept. Project members can view
+and manage all virtual resources created by anyone in the project
+(for example, share VMs). A user can be a member of any number of projects
+and can switch views in the CloudStack UI to show only project-related
information,
+such as project VMs, fellow project members, project-related alerts, and so on.
+
+From CloudStack 4.15 onwards, it is possible for a project to have
+multiple project administrators and to add/invite specific users of
+an account to a project in addition to adding accounts. By means of
+Project Roles associated with a user or an account of the project,
+it is possible to restrict access of users in a project, i.e., in
+addition to account-level roles, one can further restrict access to
+operations (or APIs) by associating a project-level role to the
+user or account. However, If an account has already been added, one will not
+be able to associate a role a specific user of that account.
+
+**NOTE:** Project Roles work over Account level Roles. If a user/account is
+added to a project without a project role, it would imply that the
+user / account added will have access to all APIs that are made available
+by the Account level role. If there are no specific deny rules in the
+project role, it would again fallback onto the account-level role to decide
+whether the user has permissions to perform a specific action. It is also to be
+noted that Project roles are restricictive in nature, i.e., to say that, one
may
+not allow a user to perform an operation that is NOT allowed at Account level.
+Even if a rule is added at the project level, allowing such an action, it will
not
+have any effect as the action will be prohibitted by the Account Role.
Review comment:
prohibitted :arrow_right: prohibited
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
