User interface manual

There are several types of users that can have access to the system:

• Admin users with unrestricted access.
• User users that cant access global configs.
• User read-only users that cant save any changes to the menu and screen layouts.
• Hosted users that have access only to the object hierarchy they are assigned to.
• Hosted read-only users that have access only to the object hierarchy they are assigned to and cant save any changes to the menu and screen layouts.
• Any of the above users that have an User access rule assigned, which will additionally restrict access to some objects, parameters, or tables.

Please see further sections below for more information.

Please refer to descriptions of the Config menu and the In-cell edit menu for information on how to edit configuration tables.

There are three types of user roles in this table:

• An Admin role, that will grant access to all screens, including the Config screen with system-wide config tables.
• A User role, that will allow access only to statistical screens and the Manual.
• A User read-only role, that will additionally prevent users from saving any changes they make to their environment.

User read-only users will always have the same screen after refresh or re-login. Also, there is no limit to number of such users that can connect with the same credentials at the same time. These accounts might be useful if you want to give access to lots of people in the company that need to see only some limited info you pre-arranged for them.

When a new user is created, it will be based on one of the two default system templates, depending on whether the user has an Admin or User role. You may, however, create a separate user environment that you will further use as a template to clone its screens to newly created users. If you press the blue Screens link in the Users table, you will have the following options for the user, which link was pressed ("the user modified"):

• Append data screens of the user chosen in the box on the left to the user modified. Screens under the "Received screens" folder are not added.
• Replace ALL screens of the user modified with the screens of the user in the box on the left.
• Delete data screens of the user modified. Systems screens/folders like "Manual", "Received screens", "Configs" are never deleted.

Please note, that even though the Replace action looks like a combination of the Delete and then the Append, the results are not quite the same. When screens are replaced - the exact replica is created, preserving the screen order and the "Received screens". When screens are appended - they end up at the bottom of any existing screens of the user, and the "Received screens" (the folder and anything under it) are not copied. User names, logins, and passwords have restrictions on their lengths, if the restrictions are not met, the system will warn you and ask for corrections.

This table currently may only be used by customers with the MVTS II switch from Aloe, as it has a built-in hosted mechanism. If you wish to limit users with restrictions as to which objects or parameters they may see, you may use the User access rules described below.

For MVTS II switches, Hosted users table is intended for the users that are associated with a certain customer/vendor in a switch config, thus allowing these users to only view objects belonging to this customer/vendor in a hierarchical tree. You may additionally choose to collect subtotal statistics for the top object of the hosted user. For instance, if there is a customer with ID "01.08" and name "Supercom" in MVTS II, enabling the Collect total option will create a new artificial object with ID "01.08.TOTAL" and name "Supercom TOTAL" that will keep the total stats for this top customer, summing up underlying children customers, vendors, equipment, etc.

Each user may be assigned an access rule, that will determine which objects, parameters or tables this user can see and which action buttons or floating window options are allowed/blocked for him/her. Access rules bind together the 5 access groups described below:

• Object groups
• Parameter groups
• Table groups
• Table edit groups
• Option edit groups

Please have a look at the following presentation explaining the main concepts of the access rules:

5gVision Access rules



Every time you change an access rule, assigned to a user, this user is getting a warning that his/her screen will be refreshed, and then it is refreshed in order to prevent a user from continuing to access the system with the old credentials that have already been changed.

Objects that each user will see in the interface can be restricted individually or by types. There are several types of objects in 5gVision, please refer to Objects.

When you include certain object types - ONLY the types included will be visible. For instance, if you included c and a, the user with this rule assigned will see Customers/Vendors and Areas, nothing else.

However, when you include objects individually, a different principle works: any object type that has included objects will show only these objects. All other types will show ALL objects with no restrictions. For instance, if you included objects c125 and c126, the user with this rule will see only these two Customers/Vendors, but will still see all the Areas, Equipment, Nodes, SNMP devices, etc. When you exclude an object type or an object, all objects will be visible, except for the excluded. Exclude prevails over include. If an object, parameter or table is both included and excluded - it will not be visible.

Parameters can be restricted individually or by types in a fashion similar to the objects described above. Using this mechanism you may, for example, close all the billing parameters to the NOC people.

Web interface tables can be restricted individually or via blocking access to the whole screens. You may, for instance, choose to completely block access to CDRs to some users, so that they may not accidentally create a very high load to the switch DB.

Sometimes it is not enough to restrict user access to certain tables. We may need a user to see the table, but not edit anything in it, or edit only certain parts. This can be controlled in Table edit. Add/Edit/Del operations in config tables are available by default to all users. Action buttons are located on the second menu row of a table and allow you to perform certain actions (for example the Import rate file button in the Rate management).

You can allow/block operations for a whole group of tables (upper config table) or for an individual interface table (lower config table) by means of checking/unchecking required flags.

Option edit expands Table edit capabilities and allows you to control not only Action buttons but also editing Options on the floating window which was called by this button. There is a very flexible approach in configuration of restrictions. As in the previous case options can be allowed/blocked globally for a whole group of tables or for an individual interface table. Furthermore one row in the lower config table can allow/block a certain option for all interface tables, for all action buttons of one table or for an individual action button depending on your needs.

For example, if there is an option that exists in several different interface tables, and you want to block it for all these tables, then you shouldn't create a rule for each table but choose only the Option name from the drop-down menu and leave the Interface table and the Action button name empty.

Option default value allows you to set a default value for an option that can't be changed if the option editing is blocked.

5gVision allows you to restrict ordinary users from seeing not only certain tables, objects or parameters, but also specific lines in configuration or log tables.

Each user may be assigned a User group. At the moment, user groups define visibility of all the tables in the Config-Alerts screen, except for the Global config table, accessible only by Admins. Normally, seeing and editing alert configuration is a privilege of an administrator. With the help of a user group, you may change this. Four access options are available:

• NO - unable to access the Config-Alerts table (default state).
• View - able to view the Config-Alerts table.
• Edit - able to edit the existing Object groups, ABS and DIFF alerts, etc. in the Config-Alerts table, but not delete them or add new ones.
• Add/Del/Edit - full access to the Config-Alerts table, able to add, edit and delete records in it.

Please note that an ordinary user normally does not have a Config-Alerts screen in the list of pre-made screens and should create one before being able to access the alerts configuration.

Each record in the Config-Alerts table contains an indication of the user group that was in force when the record was created. Two general rules apply:

• An admin user with no user group is able to view any records, while a user group restricts the admin to the records created with this user group.
• An ordinary user is unable to see anything until assigned a user group, then the user will be able to access the records created within this user group.

These access restrictions apply not only to the Config-Alerts table, but consequentially to the Alerts table as well - a user may see the raised alerts only created by himself or other users within his/her user group.

You may add a user group in the User edit group section of the Config-Users table which is hidden by default. Specify the desired access options for the group and assign it to the required users. Please note that when non-admin users with a user group define an Alert Object group in the Config-Alerts->Obj groups table, they should always fill the IDs included field, otherwise the alerts created with this object group will be ignored by the system. This is necessary as lack of specific IDs means that the alert should be triggered for all objects and the system is unable to determine the scope of "all" in the context of user group visibility.

Auth log allows you to check the history of user logins to the system. It contains login time, IP address, user name and other authentication information.