The organisation concept
The organisation concept in MINT is a way to have separate, private spaces for each mine action programme, operator, or any other actor using MINT. Each organisation has its own data sources, reports, dashboards, etc. that only users belonging to that organisation can access (depending on their specific permissions). For example, users from the organisation MAC1 cannot access objects from the organisation MAC2. An exception to this are organisations in parent-child relationships. For example, the organisation MAC1 could have a sub-organisation named Regional MAC1. In this case, users from the parent organisation MAC1 can access the objects of the child organisation Regional MAC1, but not the other way round.
The organisation name needs to be provided when logging into MINT. There is no drop-down list of organisations, so users need to know the exact spelling of their organisation.
|Before creating a multitude of nested organisations, it is recommended to make a stakeholders (future MINT user groups) mapping and think about the requirements of each group. Based on that, it can be decided whether it is best to create several sub-organisations or manage the different groups through specific permissions. Contact your GICHD IM advisor for advise.|
|Administrators of an organisation can create sub-organisations. The initial parent organisation has to be created by the global MINT administrator though. This is done when a programme / actor decides to get started on MINT.|
Administrators of a parent organisation can create sub-organisations. To do so, the following steps are required:
- On the top menu, select Manage → Organizations
- In the left-hand pane named Organizations, select/highlight the organisation for which a sub-organisation should be created (there can be a hierarchy of organisations)
- Click on Add Organization...
- Provide a name, an ID and an alias for the new organisation. The name is displayed in the folder structure; the ID is a unique identifier that cannot be changed; the alias is the name to be used on the login page, and hence the one to communicate to users of that organisation.
- Click on Add Organization to <Parent Organisation Name>
|Only Administrators can manage roles.|
The page to manage roles can be accessed via Manage → Roles in the top menu. The following roles exist by default after the installation:
- ROLE_ADMINISTRATOR: User assigned to this role are administrators of the system, i.e. they can manage sub-organisations, users and roles, as well as create/rename/delete folders in the repository and assign permissions.
- ROLE_ANONYMOUS: Users assigned to this role do not have any permission to view any objects or perform any actions in the system, unless explicitly defined.
- ROLE_USER: Users assigned to this role can view and schedule reports, i.e. use the system as end users, but not perform any administrative tasks such as managing users and roles, and manipulating folders.
To add a role, click on the Add Role button in the top left corner of the role management interface. Only a name needs to be provided. There are two ways of assigning users to roles:
- From the role management interface, by selecting a role and clicking on Edit in the right-hand pane: users from the list of available users can be dragged to the list of assigned users, or removed from that list.
- From the user management interface, by selecting a user and clicking on Edit in the right-hand pane: roles from the list of available roles can be dragged to the list of assigned roles, or removed from that list.
|Only Administrators can manage users.|
The page to manage users can be accessed via Manage → Users in the top menu.
Adding a User
In order to add a user, click on the Add User button in the top left corner of the users interface. A pop-up window appears in which the following information is prompted:
- User name: user name assigned to the new user. This name will be displayed in the application and can be displayed on reports.
- User ID: this is the actual ID that needs to be provided in the login window.
- Password: password for the user ID. This can and should be changed later by the actual user, when he or she first logs in.
- Optional - Email: if an email notification system is set up, an email address can be provided for automatic notifications.
The user is finally added by clicking on the Add User button on the pop-up window.
A user can later by edited by clicking on the Edit User button on the main user management interface. The following properties can be changed:
- Password - this is how an administrator can reset a user's password.
- Email address
- Enable/disable a user - if a user is disabled, it will not be able to log in to the system anymore.
- Assign and remove roles (see the section below on managing roles)
Changes need to be saved before they are taken into account.
Changing a Password
|Administrators can change/reset all user's passwords, and every user can change his/her password.|
Users can change their password by clicking on the Change password link under the login box on the login page.
Managing the folder structure
The MINT repository is in fact a folder structure, as in a file system on a computer. To add a folder somewhere in the hierarchy, right-click on the parent folder (for which a child folder should be created) and click on Add Folder. Provide a name and an optional description and click on Add.
|By default, only administrators (user with the role ROLE_ADMINISTRATOR) can create folders. However, an administrator can allow specific roles and/or users to add folders, by granting them Read+Write permission on the parent folder. This is described in details here.|
When an organisation is created in MINT, the following following folders are automatically created:
This structure is just a suggestion. However, it is recommended to group objects by type (e.g. one folder for data sources, one for domains, etc.) The parent folder always corresponds to the organisation; no objects should directly be placed there.
Managing permissions on objects
Different users and roles may have different permissions on folders and objects. Permissions can be one of the following:
- No Access
- Administer - in this case, a user or role that got the Administer privilege granted can in turn manage permissions of this folder/sub-folder/object
- Read Only
- Read + Write
- Read + Delete
- Read + Write + Delete
- Execute Only - this can apply to a report or dashboard
In order to set permissions on a folder or object, right-click on that folder/object and select Permissions.... Permissions can either be set per role or per user.
To switch between the two, click on View By: User/Role.
While the user-based permissions allow for very specific grants/restrictions, it is recommended to use role-based permissions for most cases. The reason is that they are better manageable - for example, if a new user is created that should have the exact same permissions as an already existing one, it is very easy to just assign the right role to that new user (and the permissions come with it automatically).
|Before creating many specific role or user-based permissions, it is recommended to think about a structure.|