- Objective: Create a framework and provide support for building multi-tenancy apps
- Users can create accounts for themselves.
- Users can create organizations (namespaces) themselves. Call them namespace admins
- Namespace admins can add people to these namespaces themselves (and manage them)
- Users can create projects / datasets (call them project owners) that they can share with access control, within and across organizations
- None of the above requires intervention by the app developer (self-service)
- App developers can build such apps on Gramex with a consistent framework
- Terminology
- Gramex: Base platform for all apps
- App: E.g. Insight Tree, Cluster, SlideSense, ...
- Namespace: E.g. Accenture, Dell, Sales, Anand, Sandeep, ...
- Project: E.g. Sales data, Customer data, ...
- Roles:
- App developer: E.g. Annamalai who builds SlideSense
- Namespace admin: E.g. Dell IT Admin
- Project owner: E.g. Dell Sales Manager for Sales data
- Base URL structure:
APP.gramener.com/NAMESPACE/PROJECT/
- The URL can have any structure that uses
/NAMESPACE/PROJECT/ in the middle. The structure below is recommended
APP.gramener.com/ is the app landing pageAPP.gramener.com/NAMESPACE/ is the namespace landing pageAPP.gramener.com/NAMESPACE/PROJECT/ is the project landing pageAPP.gramener.com/settings is for the app developer to specify app settings (e.g. default clustering algorithm)APP.gramener.com/NAMESPACE/settings is for namespace admin to edit namespace-level configAPP.gramener.com/NAMESPACE/PROJECT/settings is for project owner to edit project config
NAMESPACE/settings are stored in a common storelocation.settings in gramex.yaml with the schema:
app -- app for which we're defining settingsnamespace -- namespace for which we're defining settingsproject -- project for which we're defining settingspath -- the location where the org's data is storedlicense -- license type (e.g. enterprise / free) or license settings (JSON)settings -- the settings (JSON)
- Role definitions stored in a common
storelocation.roles in gramex.yaml with the schema:
app -- need a sensible default (where 1 Gramex instance, like UAT, serves multiple multi-tenancy apps)namespace -- the namespace for which the role is defined (e.g. a namespace)project -- the project for which the role is defined (e.g. a project)user -- the user ID for whom we're looking up the rolerole -- each person may have 1 or more roles in a fnmatch-like hierarchy "dataset/excel", "dataset/csv", "doc/pdf", "dataset/*" that we can SQL query by, and the most recent permission overriding the previous ones
- Permissions are stored in a common
storelocation.permissions in gramex.yaml with the schema:
role: the role for which we're defining permissions. 1 role per rowpermission: the permissions allowed for this role. 1 permission per row
- App level permissions for namespaces
- Namespace level permissions:
- read-all-projects
- update-all-projects
- create-project
- list-namespace
- update-namespace (edit) all project settings, roles, permissions
- delete-namespace
- Project level permissions:
- read-project
- update-project (edit) the project settings, roles, permissions
- delete-project
- Will be available in handler.current_user.roles (
roles can be changed to something else via a config)
- Structure: { roles: [role, role, ...], permissions: [permission, ...]}
- Editing
- Revised version of FormHandler table
- How to allow users to create standard values (e.g. standard permissions / settings)?
- Org setup flow
- App developer can import the Org setup app at an endpoint, etc
/setup
- The
app, org, path, license fields are pre-filled
- The app accepts a set of configurations (flat key-value pairs) as YAML settings, with defaults
- This has a single page that displays the configurations and allows the owner to edit them
- On submit, it created the entry in the org definitions AND role definitions (creating the owner for the app)
@jaidevd @shraddheya -- do take a look. Thanks!
APP.gramener.com/NAMESPACE/PROJECT//NAMESPACE/PROJECT/in the middle. The structure below is recommendedAPP.gramener.com/is the app landing pageAPP.gramener.com/NAMESPACE/is the namespace landing pageAPP.gramener.com/NAMESPACE/PROJECT/is the project landing pageAPP.gramener.com/settingsis for the app developer to specify app settings (e.g. default clustering algorithm)APP.gramener.com/NAMESPACE/settingsis for namespace admin to edit namespace-level configAPP.gramener.com/NAMESPACE/PROJECT/settingsis for project owner to edit project configNAMESPACE/settingsare stored in a commonstorelocation.settingsin gramex.yaml with the schema:app-- app for which we're defining settingsnamespace-- namespace for which we're defining settingsproject-- project for which we're defining settingspath-- the location where the org's data is storedlicense-- license type (e.g. enterprise / free) or license settings (JSON)settings-- the settings (JSON)storelocation.rolesin gramex.yaml with the schema:app-- need a sensible default (where 1 Gramex instance, like UAT, serves multiple multi-tenancy apps)namespace-- the namespace for which the role is defined (e.g. a namespace)project-- the project for which the role is defined (e.g. a project)user-- the user ID for whom we're looking up the rolerole-- each person may have 1 or more roles in a fnmatch-like hierarchy "dataset/excel", "dataset/csv", "doc/pdf", "dataset/*" that we can SQL query by, and the most recent permission overriding the previous onesstorelocation.permissionsin gramex.yaml with the schema:role: the role for which we're defining permissions. 1 role per rowpermission: the permissions allowed for this role. 1 permission per rowrolescan be changed to something else via a config)/setupapp,org,path,licensefields are pre-filled@jaidevd @shraddheya -- do take a look. Thanks!