...
Because the set of Admin App users are managed by Admin App for use against all the ODS databases, new user administration features will appear under the "Global" top level navigation.
See WIP: User Management for Admin App (Multi-Instance Mode) for technical design of the users/roles/permissions aspects of Multi-Instance. At a high level, administrators should be able to define the list of known ODS databases, create and manage user accounts, and associate users to their approved list of Districts.
First-Time Setup
See Multi-Instance First Time Setup for the design of the First-Time Setup aspects of Multi-InstanceOf the many things that take place during First Time Setup, two steps are critical to this discussion:
- Admin App enlists itself as a client application in the Application/Vendor/ApiClients tables.
- Admin App defines views for the purposes of reporting.
In a multi-instance scenario, this work needs to happen per instance. Because instance databases may be enlisted by an administrator over time after logging into Admin App for the first time, we need to begin to separate those First Time Setup steps from the Instance-Setup steps.
When a new instance database is registered, at that time we will perform the instance specific steps.
By creating a dedicated Application per instance database, we'll have an appropriate dedicated key/secret per database. As a user interacts with the Descriptors screen for a selected District, for instance, Admin App will be able to use the right key/secret to ensure the requests route to the right database.
Subsequent Enhancement: Once that's implemented, the First Time Setup process could be enhanced to cut down on the initial setup of the already-present District databases: if the list of existing database can be inferred or queried (they correspond with EdOrg Ids afterall), First Time Setup could attempt to register them automatically. Then, an admin would only have to register an instance if a new database were to be set up for the collaborative.