User Setup

Introduction

Mifos system users must be unique in the system. Uniqueness is confirmed by their government ID, if available, or their name and date of birth. All users are assigned to a specific office. Users that belong to branches can be identified as either non-loan officers or as loan officers, which impacts their data scope (enter link). Users are allowed to perform activities in Mifos based on their user role, which is a collection of permissions. Only users in an Active state can access the system.

At each office, any user with the required permissions can create, view and manage other users in his/her data scope, through the Define new system user link on the Admin tab. A user is created with the following attributes, some of which can be modified after creation.

Attributes for User Creation

s no.	attribute name/th>	data type	range	default	mandatory for active state	editable after active state	can be modified by user from the my setting section	description/notes
1.	First Name	Alphanumeric	N/A	None	Yes	Yes	Yes	For details, see Name.
2.	Middle Name	Alphanumeric	None	None	No	Yes	Yes
3.	Second Last Name	Alphanumeric	None	None	No	Yes	Yes
4.	Last Name	Alphanumeric	None	None	Yes	Yes	Yes
5.	Office	Click and select	As per data scope of logged in user.	None	Yes	Yes	No	This is selected from a list of offices. The values in the list are dependent on the data scope as per office hierarchy.
6.	User Title	Drop-down	Options defined by HO	None	No	Yes	No	This is the personnel's actual title in the office, like CFO, Accountant, and Sr. Loan Officer. These titles are defined by the MFI.
7.	User Hierarchy	Drop-down	Loan Officer; Non-Loan Officer	None	Yes	Yes	No	User hierarchy and the office level define the data scope of the user. Refer Data Scope The Loan Officer user hierarchy exist only at the BOs. Users at other office levels are all non-LOs. Note: Clients can be assigned to LOs only. Clients and LOs must belong to the same branch.
8.	Email	Alphanumeric	N/A	None	No	Yes	Yes
9.	Roles	Drop-down - Multi- select	All Defined Roles	None	No	Yes	No	One or more roles can be selected from a list of membership roles. For more details, see Roles.
10.	Government ID #	Alphanumeric	N/A	None	As per configuration	No	No	Government ID can be configured as mandatory or optional.
11.	DOB	Date	N/A	None	Yes	Yes	Yes	Age calculated as per the DOB is mentioned in the Preview and User Details page.
12.	Gender	Drop- down	Male; Female	None	Yes	Yes	Yes
13.	Language Preferred	Drop- down	English and others defined in configuration file	MFI language	No	Yes	Yes	NOTE: This feature does NOT work. One language can be designated as preferred. If left blank, system assumes MFI language as the user preferred language.
14.	Address 1	Alphanumeric	N/A	None	Yes	Yes	Yes
15.	Address 2	Alphanumeric	N/A	None	No	Yes	Yes
16.	Address 3	Alphanumeric	N/A	None	No	Yes	Yes
17.	City	Alphanumeric	N/A	None	Yes	Yes	Yes
18.	State	Alphanumeric	N/A	None	Yes	Yes	Yes
19.	Country	Alphanumeric	N/A	None	Yes	Yes	Yes
20.	Postal Code	Alphanumeric	N/A	None	No	Yes	Yes
21.	Telephone	Alphanumeric	N/A	None	No	Yes	Yes
22.	Question Groups	Mix	N/A	None	Configurable	Yes	No	For details, see Question Groups.
23.	Username	Alphanumeric	N/A	None	Yes	No	No	This is the ID with which this user accesses the system. System verifies and ensures that no two users have the same username.
24.	Password	Alphanumeric	6 to 20 characters	None	Yes	Yes	Yes	Used to authenticate the users when they attempt to access the system. A password generator is out of scope. Admin has to specify the new password while resetting password for a user. The user is required to change the password after the first login. For details, refer Passwords. The passwords can be edited from the User Details page. Users can change the passwords from their My Settings section.
25.	Confirm Password	Alphanumeric	6 to 20 characters	None	Yes	Yes	Yes	The passwords entered in Password and Confirm Password fields should match.
26.	Date of Joining MFI	Date	N/A	Current date	No	No	No
27.	Date of leaving last office	Date	N/A	None	No	No	No	This is the system-generated date of leaving the last branch. This is recorded by the system when the user is transferred to another office.
28.	Date of joining office/branch	Date	N/A	None	N/A	N/A	No	System generated. This is the date when user record was created.
29.	Status	Drop-down	Active; Inactive	None	N/A	N/A	N/A	Before a Loan Officer can be marked as Inactive, all the clients, groups, and centers must either be transferred to another Loan Officer or should be Closed/Cancelled.
30.	Notes	Alphanumeric	N/A	None	No	Yes	No
31.	Marital Status	Drop-down	Options defined by HO	None	No	Yes	Yes

When the administrator adds a user to Mifos, a user account is created in an active state. User accounts are in either an Active or Inactive state, and there is no limit to the number of times a user state can be changed. A user must be Active to access the system. Loan officers can be made Inactive only if there are no clients assigned to them.

User accounts are assigned a username and password, which the user enters to log in to Mifos. After initial login, the user is required to create and confirm a new password consisting of 6-20 alphanumeric characters. A user can change the password after login. The user is prompted for the following before confirming the password change:

Old Password
New Password
Confirm New Password

Security features

Security is ensured through the following functions:

Password encryption
All passwords are stored in the database in an encrypted format. If a user forgets his password, he can ask the administrator to reset it. The administrator resets the password and communicates it to the user through a method external to Mifos (for example, verbally). The user can change the password at the next login.
Locking accounts after 5 unsuccessful login attempts
If the user enters an incorrect password five times consecutively, then the account is locked. The user then needs to contact the administrator to unlock the account and get a new password. If the account is locked, the status remains Active, but the user cannot access the system.
Last login time display
Each time a user logs in, his last login time is displayed, which the user should check for accuracy, for security purposes. If a user is already logged in to another machine, the last login time still displays the latest login time of the user. Last login time is not dependent on whether the user has logged off or not.
Session time-out
If the user has logged in to the system, but is inactive for a period of time specified by the admin, the session times out and the user needs to login again. Any unsaved data gets lost when a session times out. The session timeout duration is configurable by the administrator at the web server level; the default is set to 30 minutes. Multiple sessions can run simultaneously on the same or different machines.

User data scope

A user’s data scope defines the set of data that a user can view and access and to which a user’s permissions (like edit and create) apply [link to permissions]. The data scope is determined by both the office hierarchy and the user hierarchy.

Limiting the scope by office hierarchy: The data scope of any user is limited to his/her office and the respective child offices. For example, a user at the HO can view all clients across the organization. If he has Modify permission, he can modify any client in the system. A user at an Area Office has access to all the client records in all the BOs under that Area Office.
Limiting the scope by user hierarchy: In addition to office hierarchy, data scope is controlled by a two-level user hierarchy: loan officer and non-loan officer. Because loan officers exist only at the branch level, only branches contain both hierarchy levels. By default, users in all other office levels belong to the non-loan officer hierarchy.
- If a user belongs to the loan officer hierarchy, then his data scope is limited to his own clients and he can only view and access these clients. For example, if he has Modify client data permissions, he’ll be able to edit only his own clients. He will not be able to view or access those assigned to other loan officers.
- If the user at belongs to non-loan officer hierarchy, the data scope is limited to the user’s office and other child offices. That is, a non-loan officer at a branch can view and edit all clients within that branch.

User roles and permissions

The way in which users can interact with Mifos is specified by their user role or roles, which are defined by the MFI. Roles are specified based on predefined system activities and permissions, as follows:

Activity. An activity is any action performed in the Mifos system, such as creating a new entity, changing the state of an entity, creating a fee type, waiving a fee, etc.
Permission. Permissions are defined for each single activity or group of activities that can be performed in Mifos. Critical system activities are assigned individual permissions while those less critical are assigned group permissions. Read or view permissions are granted by default, depending on a user’s scope [link]. For example, loan officers can only view the details of those clients assigned to them.
Role. Roles are groups of permissions which are created, defined, and named by the MFI and used throughout the organization. Mifos ships with a predefined role, called “admin”. The admin role has all permissions and can be used to create other roles.

A user can be assigned any number of roles and will be granted the permissions of each. For example, if one role gives a user a Create permission for a particular record and another gives him Modify permission for that record, he’ll be able to both create and modify the record.

Permissions cannot be granted outside a role. If a user needs permissions outside a role, a new role can be created to give him those permissions.

Role modification. Permissions associated with a role can be modified. If a role is modified, all users associated with the role inherit the change. A role can also be deleted. When this happens, all users assigned to that role will lose permissions associated with that role on their next login. However, if a user has the same permission granted through another role that is still Active, he retains the permission.