Appearance
Organisations, users and access
NOOSAdmin combines organisation membership, role-based access control and permissions assigned through user groups. These capabilities let a team arrange access around the people who administer the platform, maintain its data flows and use its results.
Organisation membership
A user can belong to one or more organisations. This supports applications in which someone participates in several organisational contexts, such as a contributor working with multiple project teams.
Access planning should consider each organisation separately. Membership establishes the user's participation in that organisation; roles and group permissions describe their responsibilities and access to its resources.
Administrative responsibilities
The global administrator role includes managing all users and responsibility for backups. Organisation administration provides an organisation-level area of responsibility. NOOSAdmin also identifies roles for particular functional areas.
The following table describes the role areas named in the platform overview. It is not an exhaustive permission matrix.
| Role area | Responsibility area |
|---|---|
| Global administrator | Management of all users and backups. |
| Organisation administrator | Organisation administration. |
| Ingress administrator | Administration of data ingress. |
| Data administrator | Data configuration, including table definitions, customised explorers, dashboards and information pages. |
| Data explorer role | Data exploration. |
| Data runner administrator | Administration of data runners. |
| Scheduling administrator | Administration of scheduled operations, referred to as cron administration in the platform overview. |
A data administrator can create and edit table definitions, including names, fields and relationships. The same documented role can create customised explorers and dashboards, and pages containing dashboards. Portal page creation is described separately as a portal administrator responsibility.
The exact combination of roles and entity permissions depends on the configured application. The categories above should not be read as a statement that one role automatically includes another.
User groups and entity permissions
Each organisation can have one or more user groups. Groups can receive fine-grained permissions on NOOSAdmin entities, including data, ingress, data runners and scheduled operations.
This provides a way to arrange resource access around a shared task or audience. For example, an application team could define a group for people who inspect measurements and another for people who manage collection. The names and resource assignments would be choices made for that deployment.
When planning groups, identify the resources each audience needs and the responsibilities it carries. An audience that reads results has different needs from a team that maintains table definitions or configures incoming data.
Access to pages and portals
Information pages containing dashboards can be made available to groups. A portal can also be accessible to one or more groups, allowing the team to assemble a relevant set of pages for a defined audience.
Resource permissions and presentation should be planned together. Decide which entities the group needs to access, then select the explorers, dashboards, forms or runner actions that belong in its experience. Portal access alone should not be interpreted as a documented grant of every underlying entity permission.
Illustrative access arrangement
For the equipment-monitoring example, the team might plan the following division of responsibilities. These are proposed audiences, not additional built-in NOOSAdmin roles.
| Audience | Work to support | Access to plan |
|---|---|---|
| Application administrators | Maintain data structures and configure information views. | Relevant administrative roles and entity permissions. |
| Data collection team | Maintain the mechanisms that receive or retrieve measurements. | Ingress administration and the relevant ingress entities. |
| Analysts | Inspect readings and use analysis functionality. | Relevant data, explorers and any required runners. |
| Operational users | Consult summaries through a portal. | The relevant groups, portal pages and underlying resources. |
One person may carry more than one responsibility. The useful starting point is the work each audience needs to perform, followed by the corresponding role and group assignments.