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.

 

 

last modified 2009-12-16 07:27

0
Your rating: None
Posted by edcable on July 26, 2010 at 1:47pm