Behavior of Update Action for Stored-Procedures in CLI

Stored Procedures require that all the roles be declared with the same CRUD operation.

For instance: A declaration such as anonymous: read and authenticated: create is invalid. Valid declaration would be both anonymous and authenticated roles having either read or create operation.

At the moment, PR #1062 removes the above check from CLI, to allow updating the CRUD operation to any role. Without this, updating the action for any of the roles is not possible.

But, just updating the action of one of the roles without others leaves the config is an invalid state.

One way to prevent this could be to carry the same update to all the roles. For instance: There are two roles anonymous and authenticated configured with read action. anonymous: read, authenticated: read

If the developer wants to update the action for authenticated role to create, then running the CLI can result in a final configuration like this (where all the roles have the same CRUD operation) anonymous:create, authenticated: create

Since stored procedures should have all roles with the same CRUD operation defined, this could be one way to achieve that.

@yorek @sajeetharan @Aniruddh25 Please share your thoughts

[seantleonard]

As mentioned by @abhishekkumams in #1070 we need to clarify how permissions should be used with stored-procedures with respect to the PUT and PATCH operations. for REST, these HTTP operations require both the create and update permissions because PUT and PATCH either update or create an object. You either have all permissions needed to perform those actions, or are not allowed to perform those operations at all.

[severussundar]

This issue tracks the CLI changes needed for 1) Introducing execute operation for stored procedures 2) Introducing new elements methods and operations within rest and graphQL respectively in the schema. Both of them are ways of the developer to specify the exact set of REST/GraphQL actions that is exposed for the stored procedure.