Web app example: Create and manage service accounts

[jattasNI]

We would like to create a new example app to help users create and manage service accounts.

Background

We recently added a new type of user to the SystemLink UserService. In addition to human users with type="user" there are now "service account" users with type="service". These are intended for executing automated actions with reduced privileges. In most SystemLink UIs we hide the service account users and only display the regular users.

If you have sufficient privileges, you can list, create, and delete service account users using the UserService APIs. We would like a custom web app to expose that functionality.

Functionality

1. List all service account users in a table. It should show relevant metadata like their name (firstName, lastName), id (niuaId), and policies (policies).
2. Include a way to delete one or more service accounts. For example, the table could enable multiselect and expose an action menu or a button above the table to delete the currently selected accounts. There should be a confirmation dialog before actually deleting to confirm the action. e.g. "Are you sure you want to delete the selected 23 service accounts? "
3. Include a way to add a new service account. Users should be encouraged to follow these guidelines, perhaps via placeholder text or instructions:
   • Both firstName and lastName should be non-empty and use sentence casing.
   • firstName should be a short descriptor that indicates the purpose/job/scope of the account.
   • lastName should be "Service Account", optionally followed by a parenthesized purpose/scope detail.
   • Names should not encode/include terms for the sake of programmatic logic. Properties should be used for that purpose.
   • Readability is the priority, but it is OK to look "internal". GUIDs may be used but are not recommended. Semi-unique or unique-by-convention names are preferred (i.e. role name, routine name, org-specific qualifier).
4. Include a way to set the policy when creating a service account and to modify the policy of an existing service account. Policies are an array of ids.
   • the ids map to objects in the AuthService /policies route.
   • objects in the AuthService /policies response include a mapping from a user id and a workspace id to a policy template id
   • each of those ids map to objects in either the AuthService or UserService
   • ideally we'd find a UX that resolves all of those IDs and allows users of the app to select workspaces and policy templates by name and apply them to a given service account user
5. Include a way to set the properties of a service account. Properties are an array of arbitrary key-value pairs.
6. Include a way to set the keywords of a service account. Keywords are an array of arbitrary strings.

Corner cases to consider

• not all users of the app will have the required privileges to create or delete a service account user. We should provide useful feedback within the app when this is the case

Technical considerations

• Like all example apps this one should use Nimble and aim for visual / interaction design alignment with built in apps and other web apps in this repo.
• The choice of UI framework is less important for this app. The purpose is less about customers inspecting the example code and more about customers deploying and using the app in their environment.
• This app requests a lot of functionality. As much as possible should be built in an incremental way with small PRs that each add individual small features. Component logic should be separated from API calling logic.