PGA Enhancements and Bug Fixes

[Sneha Tilak <sn...@gmail.com>]

Hello dev,

I have a created a PR for the changes made to the PGA portal -
https://github.com/apache/airavata-php-gateway/pull/58. The list of fixes
that were resolved are mentioned in the comment. Since there were many
changes with respect to the PGA portal, I created a single PR.

There has been a change in the Gateway request flow. It involves the
following steps:


   1. The user creates account and logs in.
   2. The user can then request a Gateway by just mentioning the Gateway
   Name, Gateway Contact Email and Public Project Description. (GATEWAY
   STATE - REQUESTED)
   3. Once the Gateway is requested, an email is sent to the PGA Admin
   about a new request.
   4. The Admin can then engage in an out of band communication with the
   user (using the Gateway Contact Email provided) incase they need some
   clarification regarding the request. The Admin can also modify the request
   as needed.
   5. Once satisfied with details provided, the Admin can either
approve (GATEWAY
   STATE - APPROVED) or deny (GATEWAY STATE - DENIED) the request. Note:
   Approving the Gateway will not create the tenant.
   6. If the Gateway is approved, the User is asked to update other Gateway
   information through a form. All the fields of the form are required.
   7. The Admin or the provider can edit any detail of the Gateway (through
   a form) as long as the Gateway is in APPROVED state. The User can also
   choose to cancel the request. (GATEWAY STATE - CANCELLED)
   8. Every time the details are edited, admin gets an email
   9. Once all the Gateway details are filled, the Admin can verify them
   and create the Gateway. The User and Admin can only view the Gateway
   details now. (GATEWAY STATE - *CREATED*)
   10. When the Gateway is created, the Keycloak auth keys are generated
   and available for the provider to use or they can wait for the Admin to
   deploy the Gateway.
   11. In case the provider wants the Admin to host the Gateway, the Admin
   then manually deploys the gateway. (GATEWAY STATE - DEPLOYED)
   12. If at all the Gateway is not in use, the Admin can deactivate it.
   (GATEWAY STATE - *DEACTIVATED*)
   13. Every time there is a change in the Gateway details or the Gateway
   state, both the provider and the Admin receive a mail.


The Gateway ID is created by converting the characters of the given Gateway
Name to lower case and replacing any space or special character with a
hyphen.

Suggestions are welcome. Have a great weekend!

Regards,
*Sneha Tilak*

Re: PGA Enhancements and Bug Fixes

["Christie, Marcus Aaron" <ma...@iu.edu>]

Sneha,

That’s a good write up of the state transitions for the new gateway request process.  Thank you for your pull request implementing these changes.  This will improve the gateway request process both for users requesting gateways and for admins creating gateways.

I’ve merged your pull request now to the develop branch.

Thanks,

Marcus


On Jun 30, 2017, at 2:23 PM, Sneha Tilak <sn...@gmail.com>> wrote:

Hello dev,

I have a created a PR for the changes made to the PGA portal - https://github.com/apache/airavata-php-gateway/pull/58. The list of fixes that were resolved are mentioned in the comment. Since there were many changes with respect to the PGA portal, I created a single PR.

There has been a change in the Gateway request flow. It involves the following steps:


  1.  The user creates account and logs in.
  2.  The user can then request a Gateway by just mentioning the Gateway Name, Gateway Contact Email and Public Project Description. (GATEWAY STATE - REQUESTED)
  3.  Once the Gateway is requested, an email is sent to the PGA Admin about a new request.
  4.  The Admin can then engage in an out of band communication with the user (using the Gateway Contact Email provided) incase they need some clarification regarding the request. The Admin can also modify the request as needed.
  5.  Once satisfied with details provided, the Admin can either approve (GATEWAY STATE - APPROVED) or deny (GATEWAY STATE - DENIED) the request. Note: Approving the Gateway will not create the tenant.
  6.  If the Gateway is approved, the User is asked to update other Gateway information through a form. All the fields of the form are required.
  7.  The Admin or the provider can edit any detail of the Gateway (through a form) as long as the Gateway is in APPROVED state. The User can also choose to cancel the request. (GATEWAY STATE - CANCELLED)
  8.  Every time the details are edited, admin gets an email
  9.  Once all the Gateway details are filled, the Admin can verify them and create the Gateway. The User and Admin can only view the Gateway details now. (GATEWAY STATE - CREATED)
  10. When the Gateway is created, the Keycloak auth keys are generated and available for the provider to use or they can wait for the Admin to deploy the Gateway.
  11. In case the provider wants the Admin to host the Gateway, the Admin then manually deploys the gateway. (GATEWAY STATE - DEPLOYED)
  12. If at all the Gateway is not in use, the Admin can deactivate it. (GATEWAY STATE - DEACTIVATED)
  13. Every time there is a change in the Gateway details or the Gateway state, both the provider and the Admin receive a mail.

The Gateway ID is created by converting the characters of the given Gateway Name to lower case and replacing any space or special character with a hyphen.

Suggestions are welcome. Have a great weekend!

Regards,
Sneha Tilak