[ 
https://issues.apache.org/jira/browse/AIRAVATA-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Christie updated AIRAVATA-2787:
--------------------------------------
    Description: 
Create a GatewayGroups thrift model and backend to store the ids of the 
"Admins", "Read Only Admins" and the default "Gateway Users" group.  The 
"Admins" and "Read Only Admins" group will be used in the API server to 
automatically grant access to WRITE and READ to those groups, respectively, for 
newly created entities.  The default "Gateway Users" group will be used by 
migrations (to keep track of previously migrated "Gateway Users" group and to 
share resources that are being migrated to group-based auth) and also to 
pre-populate the list of groups to share a new Group Resource Profile or 
Application Deployment with in UIs (but can be changed by the user).

The AiravataDataMigrator should use the presence of this model to determine if 
the gateway groups should be created or not.

TODO
* [x] add GatewayGroups model and entity to Registry
* [ ] add create/read methods for the GatewayGroups to the Registry and API 
services
* [x] Create the GatewayGroups in the migration script by calling the Registry
* [ ] add an API service DB event handler to create the GatewayGroups when a 
new gateway is created

Deferred
* add feature to sharing registry to mark certain groups as being undelete-able
* add feature to sharing registry to specify a certain group as one that should 
be added as admin of all groups created (so gateway admins can edit all groups 
created in a gateway)

  was:
Create a GatewayGroups thrift model and backend to store the ids of the 
"Admins", "Read Only Admins" and the default "Gateway Users" group.  The 
"Admins" and "Read Only Admins" group will be used in the API server to 
automatically grant access to WRITE and READ to those groups, respectively, for 
newly created entities.  The default "Gateway Users" group will be used by 
migrations (to keep track of previously migrated "Gateway Users" group and to 
share resources that are being migrated to group-based auth) and also to 
pre-populate the list of groups to share a new Group Resource Profile or 
Application Deployment with in UIs (but can be changed by the user).

The AiravataDataMigrator should use the presence of this model to determine if 
the gateway groups should be created or not.

TODO
* [x] add GatewayGroups model and entity to Registry
* [ ] add create/read methods for the GatewayGroups to the Registry and API 
services
* [ ] Create the GatewayGroups in the migration script by calling the Registry
* [ ] add an API service DB event handler to create the GatewayGroups when a 
new gateway is created

Deferred
* add feature to sharing registry to mark certain groups as being undelete-able
* add feature to sharing registry to specify a certain group as one that should 
be added as admin of all groups created (so gateway admins can edit all groups 
created in a gateway)


> GatewayGroups model for storing adminsGroupId, readOnlyAdminsGroupId and 
> defaultGatewayUsersGroupId
> ---------------------------------------------------------------------------------------------------
>
>                 Key: AIRAVATA-2787
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-2787
>             Project: Airavata
>          Issue Type: New Feature
>            Reporter: Marcus Christie
>            Assignee: Marcus Christie
>            Priority: Major
>
> Create a GatewayGroups thrift model and backend to store the ids of the 
> "Admins", "Read Only Admins" and the default "Gateway Users" group.  The 
> "Admins" and "Read Only Admins" group will be used in the API server to 
> automatically grant access to WRITE and READ to those groups, respectively, 
> for newly created entities.  The default "Gateway Users" group will be used 
> by migrations (to keep track of previously migrated "Gateway Users" group and 
> to share resources that are being migrated to group-based auth) and also to 
> pre-populate the list of groups to share a new Group Resource Profile or 
> Application Deployment with in UIs (but can be changed by the user).
> The AiravataDataMigrator should use the presence of this model to determine 
> if the gateway groups should be created or not.
> TODO
> * [x] add GatewayGroups model and entity to Registry
> * [ ] add create/read methods for the GatewayGroups to the Registry and API 
> services
> * [x] Create the GatewayGroups in the migration script by calling the Registry
> * [ ] add an API service DB event handler to create the GatewayGroups when a 
> new gateway is created
> Deferred
> * add feature to sharing registry to mark certain groups as being 
> undelete-able
> * add feature to sharing registry to specify a certain group as one that 
> should be added as admin of all groups created (so gateway admins can edit 
> all groups created in a gateway)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to