[
https://issues.apache.org/jira/browse/CLOUDSTACK-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270077#comment-15270077
]
ASF GitHub Bot commented on CLOUDSTACK-8562:
--------------------------------------------
Github user jburwell commented on the pull request:
https://github.com/apache/cloudstack/pull/1489#issuecomment-216734107
@rhtyd I am trying to understand how reordering should work. User creates
a role with rules ordered as follows:
1. Rule A
1. Rule B
1. Rule C
1. Rule D
1. Rule E
1. Rule F
When the user creates this role, the API guarantees that these six rules
and their order will be persisted atomically. Later, the user wants to reorder
the rules as follows:
1. Rule A
1. Rule D
1. Rule B
1. Rule C
1. Rule E
1. Rule F
As I understand the API, the following discrete API calls are required to
affect this change:
1. ```updateRolePermission(roleId: "Rule D", parentUUID: "Rule A")```
1. ```updateRolePermission(roleId: "Rule B", parentUUID: "Rule D")```
1. ```updateRolePermission(roleId: "Rule C", parentUUID: "Rule B")```
Assuming my understanding regarding the API usage is correct, I have the
following concerns about this approach:
1. **Operation Interleaving**: Since each API call can only provide a
guarantee the persistence of a single list mutation, it is possible for two
users to change the order of rules for permission simultaneously. The result
of this operation interleaving would leave the order of the rules in an
indeterminate order.
1. **Client Complexity**: It places a burden on clients to track the
mutations to the list of rules rather than simply tracking the current order of
the list. This additional complexity could lead to more error prone client
code.
As a user my expectation would be to reorder all rules associated with a
permission in one atomic operation rather than a series of atomic mutation
operations.
> User Definable Roles
> --------------------
>
> Key: CLOUDSTACK-8562
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8562
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Reporter: Paul Angus
> Assignee: Rohit Yadav
>
> Static command.properties moved to database and made user definable
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
