UI/UX for Application Sharing

[chrsamp]

As a developer integrating a BC Government API, I want to be able to share an application that I have configured in the API Services Portal with other users, so that others can continue to administer the application in my absence.

Acceptance Criteria

• Prototype changes to "Edit application" modal that afford the owner of an application the ability to add or remove one or more additional application owners
• Prototype updates to the "My Applications" page so that when the details for an application are shown (disclosure caret is expanded) the owners of the application are displayed next to the Authorized API access and description of the application

Out of scope

• User roles (i.e. all owners have the same permissions)

[odyeung]

@ikethecoder bump! questions from nathalia...

[nathaliamorales]

im meeting with Devs today to discuss whats technically possible from the backend before heading with the mockups.

[odyeung]

@ikethecoder bump again -- @nirajCITZ nathalia is going to reach out to you just in case you can help unblock her

[nathaliamorales]

I spoke @nirajCITZ and he will run some tests to give advice on what would be the best way to share app ownership. If we can support sharing with more than 1 user at the time, max 2, or once at a time.

[nirajCITZ]

Checked keycloak and postgrace db to check how application is maped with the user but it requires some more investigation to verify whether it's feasible to share application with another user

[odyeung]

@ikethecoder @Jonesy need you to see what is being called!

[nathaliamorales]

Background: From a conversation I had with Chris last week to understand this ticket, he said that ideally we would allow sharing an application with multiple users at the same time. He suggested me to consult the development team to check if there was any preference/restriction that would prevent the app sharing with multiple users. For example if it would be more viable to allow sharing with only 1 more user (app owner + someone else) OR if it would be more viable to have ONLY 1 user at a time (in this case it would be transferring not sharing).

As @ikethecoder has been with low availability, i checked with @nirajCITZ to see if i could get some answer. Niraj checked but said he is not sure if with the current architecture, an application can be shared with others (he needs to check with @ikethecoder). Niraj suggests to create the design according on what is needed so the team can build the architecture to allow what is required.

Action required: @ikethecoder when you have availability, please let me know if we can proceed with the app sharing with multiple users, or if you have any other suggestion for this.

[ikethecoder]

I don't think whether it is one extra or many, makes any difference as far as technical complexity. Perhaps a question is how complex do we make the authorization? I am leaning towards not having any kind of multi-role/permission support (basically only an "owner" role - no "view/read" role") and that you are just able to add/remove owners. Another question is do we have to introduce the concept of a Team - if someone is managing 100 Pharmacy locations and each one represents an Application, is a Team needed to simplify the administration? Initial thought is to try and avoid introducing a Team concept. But depends on requirements.

[nathaliamorales]

@ikethecoder yes chris mentioned that we wont have different roles. Everyone would be "owner" and all have the same rights.

Im not sure what the concept "team" implies and how it would simplify the administration or if its needed.

[nathaliamorales]

Designs ready to review with Aidan. invite sent for this thursday

[nathaliamorales]

im reviewing with Aidan some ideas he has around the way we share permission in and org level. We are taking a step back and Aidan is helping me understand the current APS structure and an example of how users interact with the portal on different stages. the outcome will be something similar to a "mental map"

[nathaliamorales]

Met with Aidan to understand the API creation process, now im editing the "map". This "map" can help new team members to understand this process, as an alternative of the "API user journey" which is more technical, content heavy, and way more detailed. "Map" will be shared when finished. We are having continuation for the App. sharing conversation on Thursday.

[nathaliamorales]

I met with Aidan today to get feedback on the 'application sharing' designs. As a result of this meeting, I will be doing some modifications to the designs considering:

• Ownership will be shared as an invite (an email with a one time use link) that will have certain time (for now it was discussed 2 days) for the recipient to login the APS portal in order to accept it.
• We cant make sure the recipient received the email, we can only confirm it was sent
• The only validation we can make it's if the value has or not an email format (standard email validation)
• We wont show "[application name] updated" success message as we do when the user changes the application name or description. This is because when the invite its sent it doesn't mean they now are owners. they need to accept by logging in. The success message will be more specific (something more like "invites sent"). For now the generic success message for other changes will remain as is.
• 'Invites' will have 3 states: waiting, accepted, expired. Thinking about adding a re send button.
• Nathalia to consider separating the invite sharing from the 'edit application modal'. Probably it will make the interaction easier. Needs to define if sharing ownership is considering an edition to the application, or if its separate. If its separate, then a 3rd option will be added to the "more action" button (the 2 dots)

[nathaliamorales]

I met with Aidan, Virgina, James and Josh for the last round of feedback. These were the agreements:

1. Emails need to be provided in order to send the invitation links. For expired or waiting for response status, we will show the email of the person. When users accept the invitation, we will show the information we can get when the user clicks on the link and log in, which could be a different email from the invite or a display name. This is because users can receive the invite to a specific email but then accept the invite and loging in with different credentials. If we can get the email the user used to login/accept the invite we will show it. If the user doesnt login with an email then we will show the display name.

2. We will allow deleting an item with the first clic on the delete button. we will add a undo banner similar to gmail or outlook to allow users recover from error without adding more clics to show a modal confirmation

3. i will create the flow for the recipient who wants to accept the invite

Update to # 1: After the meeting i spoke with aidan regarding the use of email vs display name. The problem of not preserving the original email where the invite sent and show a different email or display name (depending how the user accepted the invite) is that users may not recognize the person who appears in the list as accepted. For example Jane sends an application ownership sharing invite to jhon@gmail.com. When Jhon opened the link, he logged in using username and password, and his user name is darthvaderallmighty. When Jane goes to the ownership sharing options for her application, she would see that "darthvaderallmighty" accepted the invite but she has no idea who that is. And since Jhon loggedin without email, we cant get his email. It would be also problematic for Jane if for example Jhon loggedin with an email different than jhon@gmail because it could be totally different and not have hints of his identity on it (darthvaderallmighty@gmail.com) Private Zenhub Image

For this reason, I advised keeping the original invite always visible. Private Zenhub Image

This will also require an effort to keep track of the invite activity in the gateway activity page. E.g. "Jane Lucas invited jhon@gmail.com to share ownership"

This will continued on sprint 85

[nathaliamorales]

@ikethecoder how the recipient's flow looks like? I imagine something like: the person receives an email that has a login button/link which take them to the portal. Right after they login i guess there would be a message saying you are now co-owner of application 123. If the user goes to my applications they will see the application there. I guess they will see exactly the same as the user who invited them, when clicking on "manage application". They will see the list of owners, the option to resend, remove and add more owners. Can you confirm if this is right? or how this flow would be? I hope I can map that flow this week before I leave :o

[ikethecoder]

Yes, that is correct. The comment "This will also require an effort to keep track of the invite activity in the gateway activity page. E.g. "Jane Lucas invited jhon@gmail.com to share ownership"" - this is not quite true though as the My Applications does not have anything to do with a Namespace/Gateway, so there is no Activity. I think we had said that we would display the invitation email on the Manage Ownership dialog so that they are tied together (?)

[nathaliamorales]

1. @ikethecoder when you say "that is correct" you refer to the recipient's flow i mentioned in the comment below right?
2. About the track in the activity. I dont fully remember but i think we mentioned something about having the track in the activity, but if the application is not related to a gateway then it shouldn't be there. So i will remove this point form the developer notes i left in the figma file.
3. Yes we said we will keep always the email used for the invite to avoid confusion. First it was said we would take whatever info the invited person used to login (which could be a username or a different email) an accept the invitation. But then i recommended to always keep visible (in the manage ownership modal) the same email used for the invite, EVEN if the person logged in with different email or with username. Are we on the same page here?

[ikethecoder]

Re point 1 - yes Re point 3 - will the manage ownership show both the original email and the accepted user's info? Thinking that over time, updated user info will come from the identity provider (BCSC, IDIR, Github, etc) so that should be visible somewhere.. the original email will be irrelevant over time.

[nathaliamorales]

After our collaborative discussion earlier today, we have decided to revert to the original plan mentioned on November 16th: "For expired or waiting for response status, we will show the email of the person. When users accept the invitation, we will show the information we can get when the user clicks on the link and log in, which could be a different email from the invite or a display name. This is because users can receive the invite to a specific email but then accept the invite and loging in with different credentials. If we can get the email the user used to login/accept the invite we will show it. If the user doesnt login with an email then we will show the display name."

During today's discussion, we explored two possible solutions to prevent users from getting confused in case the email to which the invite was sent differs from the information when the invite is accepted:

Add an option somewhere on the 'edit owner' list element to view the original email to which the invite was sent and when. Introduce an activity page for each application (similar to the one in namespaces) where users can review all activities related to the application sharing, such as who was invited, when, by whom, deletions, etc. While this could be considered a sophisticated feature, it may be highly desired by users, as Aidan mentioned. Implementing an additional info button for mouse-over to display the email and date when the invite was sent may clutter the element, considering we already have an icon (to indicate the state), a resend button, and a delete button. To maintain a clean interface, my recommendation, for now, is getting the provider identity, and once implemented and in use we can gather feedback from real users to assess:

• Whether it is confusing to see the invite identity changing or not.
• Whether an activity page would be a desired feature.

[nathaliamorales]

Designs are finished. Find the screens and the development notes in the figma file, in the 'ready for development page'. This ticket can be closed or assigned to a developer for implementation :)

[veep-22]

RocketChat request from Willem Mulder on May 15 2024 - emerging requirement for SAWSx and DriveBC

I am working on the new DriveBC site and as part of that we are pulling in weather data from SAWSx through the gateway. I used my IDIR to login to the API Services portal and created an application + requested access with my account. My question is, what happens if I were to move to another role and would no longer be managing that API connection? Is there a way for me to share my application with others? Should we be using a service account to set up this connection? What is the best practice?

Aidan Cope @aidan.cope Owner 11:28 AM Hi Willem Mulder, at the moment the only option is for the person replacing you to go through creating an application and requesting new credentials again. But we have completed the UX work on this change ("Application Sharing") and the development work is in our backlog (see https://github.com/bcgov/api-services-portal/issues/127). cc'ing our product owner Virginia Vella for prioritization review.Aidan Cope @aidan.cope

Virginia Vella @virginia.powell 1:28 PM hi Willem, this is on our roadmap for next quarter. If you'd like, we can let you know when it's available. If you have any further requirements related to service accounts or "application sharing" as we call it, please let us know and we'll include them in our backlog 🙂

willem.mulder Willem Mulder @willem.mulder 3:18 PM Thanks Aidan Cope and Virginia Vella If you can let us know when it's available that would be great! My only suggestion at this point, would be to look at what they do with the Common Sign on Service where you can create a Team and give people certain roles in that team (Admin or Member)

**- consider for sprint 92, 93 or 94 depending on team capacity

• definition of done includes letting Willem know the feature is ready
• in approach, consider Williem's suggestion of replicating the Common Sign on Services' feature where the user can create a team and assign roles**