Administrating MINT: Difference between revisions

From IMSMA Wiki
Jump to navigation Jump to search
Evinek (talk | contribs)
No edit summary
No edit summary
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{TOC right}}
{{TOC right}}
{{Under construction| This page is under construction}}


==Managing organisations==__NOEDITSECTION__
==Managing organisations==__NOEDITSECTION__
{{Note | Organisations only exist in MINT, there is no equivalent in lightMINT.}}
===The organisation concept===
===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'' 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.
Line 10: Line 8:


[[File:MINT_login_box.png|center|200px]]
[[File:MINT_login_box.png|center|200px]]
{{Note | 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 [[Information Management Team|GICHD IM advisor]] for advise.}}


===Adding sub-organisations===
===Adding sub-organisations===
Line 15: Line 15:


Administrators of a parent organisation can create sub-organisations. To do so, the following steps are required:
Administrators of a parent organisation can create sub-organisations. To do so, the following steps are required:
# On the top menu, select '''Manage → Organizations'''
<ol>
# 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)
<li> On the top menu, select '''Manage &rarr; Organizations'''</li>
# Click on '''Add Organization...'''
<li> 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)</li>
# 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.
<li> Click on '''Add Organization...'''</li>
[[File:MINT_create_suborganisation.png|center|350px]]
<li> 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>'''
[[File:MINT_create_suborganisation.png|center|350px]]</li>
[[File:MINT_suborganisations.png|center|850px]]
<li> Click on '''Add Organization to <Parent Organisation Name>'''
[[File:MINT_suborganisations.png|center|850px]]</li>
</ol>
{{Note | When a new organisation is created two users are created by default: jasperadmin (an administrator) and joeuser (a user) with the respective passwords jasperadmin and joeuser. '''It is recommended to immediately change the password of jasperadmin, and delete the joeuser user.'''}}


{{Note | When a new organisation is created, by default it has two users: jasperadmin (an administrator) and joeuser (a user) with the respective passwords jasperadmin and joeuser. '''It is recommended to immediately change the password of jasperadmin, and delete the joeuser user.'''}}
<onlyinclude>
==Managing roles==__NOEDITSECTION__
{{Note|Only '''Administrators''' can manage roles.}}
The page to manage roles can be accessed via '''Manage &rarr; 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.


==Managing roles==__NOEDITSECTION__
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.


==Managing users==__NOEDITSECTION__
==Managing users==__NOEDITSECTION__
{{Note|Only '''Administrators''' can manage users.}}
The page to manage users can be accessed via '''Manage &rarr; Users''' in the top menu.
=== Adding a User ===__NOEDITSECTION__
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.
[[File:LightMINT_add_user.png|center]]
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.
[[File:LightMINT_edit_user.png|center|700px]]
=== Changing a Password ===__NOEDITSECTION__
{{Note|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==__NOEDITSECTION__
==Managing the folder structure==__NOEDITSECTION__
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'''.
[[File:MINT_add_folder.png|center]]
{{Note | 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 [[Administrating MINT#Managing permissions on objects|here]].}}
When an organisation is created in MINT, the following following folders are automatically created:
[[File:MINT_default_folder_structure.png|center]]
This structure is just a suggestion. However, it is recommended to group objects by type (e.g. one folder for [[Creating Data Sources in MINT|data sources]], one for [[Creating MINT Domains|domains]], etc.)
The parent folder always corresponds to the organisation; no objects should directly be placed there.


==Managing permissions on objects==__NOEDITSECTION__
==Managing permissions on objects==__NOEDITSECTION__
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.
[[File:MINT_permissions_roles.png|center]]
To switch between the two, click on '''View By: User/Role'''.
[[File:MINT_permissions_users.png|center]]
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).
{{Note | Before creating many specific role or user-based permissions, it is recommended to think about a structure.}}
</onlyinclude>


{{NavBox Business Intelligence}}
[[Category:NoPublic]]
[[Category:VIE]]
{{NavBox Hub}}

Latest revision as of 20:09, 20 February 2020

Managing organisations

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.

Adding sub-organisations

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:

  1. On the top menu, select Manage → Organizations
  2. 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)
  3. Click on Add Organization...
  4. 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.
  5. Click on Add Organization to <Parent Organisation Name>
When a new organisation is created two users are created by default: jasperadmin (an administrator) and joeuser (a user) with the respective passwords jasperadmin and joeuser. It is recommended to immediately change the password of jasperadmin, and delete the joeuser user.


Managing roles

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.

Managing users

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.

Template:NavBox Hub