How to Model User and Group Management

by Davide Martinenghi
24,592 views Published on Feb 03, 2014
Applies to: 7.2 or higher
Table of contents

Introduction

In a Web Application, we often need to grant different groups of users access to different resources. For example, in a Web Application used for Enterprise Resource Planning, the head of Human Resources will have access to all the employees’ sensitive data (such as person details, salary, etc.), while Technical staff members will have access to their own time reports, but will not be able to access other people’s sensitive data. For this reason, we need to suitably model different types of groups and users in a Web Application.

With WebRatio you can easily manage users and groups. In this article, we describe the best practices for modeling management of users and groups in a Web Application. Before reading this article, you should be familiar with the topics of Data Management and Data Management Action Definition.

Users and groups in WebRatio

Although WebRatio is not equipped with a built-in module to manage users, you can model an Area in the "Administration" Site View to achieve this goal. Note that, when a new Web Project is created, the Domain Model already contains the part that is required to model users and groups. Usually, it looks like in the following image.

Managing users, groups and protected modules is as simple as modeling just two areas: one for users and one for groups. 

Each area needs to contain a management page (for either users or groups) and an error page. 

The page used to manage users will be used by an administrator to create a new user, to modify or delete an existing user, and to connect users to groups. A connection between a user and a group simply indicates that the user belongs to that group.

The page used to manage groups will allow the administrator to create a new group, to modify or delete an existing group, and to connect groups to protected modules. In this case, a connection between a group and a module indicates that all the users belonging to that specific group have access to that specific module.

Let's see how these two areas can be modeled.

Managing groups

The main idea behind the group management page is to handle a list of groups, shown by means of either a List or a Simple List associated with the "Group" Entity.

The page should also contain a Form, also associated with the "Group" Entity, used to insert data for a new group or to modify data of an existing group.

The overall picture is as shown in the following figure.

Administrators need to associate groups with modules and to define the default module for a group, i.e., the module to which a user of the group is redirected to after login.

In order to manage these associations of groups with modules, the Form should contain a Selection field for selecting the default module for the group as well as a Multi Selection Field listing all the modules that the group can be associated with.

To preload the Multi Selection and the Selection Field, you may use a Selector (called "All modules" in the figure), which extracts all the modules of your Web Application. We can connect the Selector to the Form through a Data Flow and make the proper binding to preload these fields.

In case the administrator needs to modify an existing group from the List, we need to retrieve the information about that group and preload it in the Form. To make that possible, we need to connect the List of groups to the Form in order to pass the group details to the Form. We do this with a Normal Navigation Flow with automatic binding. We also need another Selector (named "Associated modules" in the figure) to extract all the modules to which the selected group is connected. Connect the List to the Selector with a Data Flow with automatic binding, and the Selector to the Form with another Data Flow with the proper binding.

Now we need to model the Actions: a "Manage group" Action that takes care of group creation and group modification, and a "Delete group" Action that takes care of group deletion.

The details of the "Manage group" Action Definition are shown in the figure below.

An Is Not Null Operation ("New group?" in the figure) checks whether the administrator is going to add a new group or to modify an existing one. In the former case, we follow the KO Flow to use a Create Operation ("Create group" in the figure) on the "Group" Entity and a Data Flow from the Input Port to the Create Operation. In the latter case, we follow the OK Flow to use an Update Operation ("Modify group" in the figure) on the "Group" Entity and a data flow from the Input Port to the Update Operation. We finish by connecting OK and KO Flows as shown. Note that the KO Flow will lead to the error page.

The last thing to model is the deletion of a group. This is very simple. We just have to use a Delete Operation on the "Group" Entity and connect it through an OK Flow from the Input Port. In this way the administrator can delete a group by just clicking on the link placed next to each group in the group list. The details of the "Delete group" Action Definition are shown in the next figure.

Managing users

Managing users is almost identical to managing groups. It suffices to replace "Group" with "User" and "Module" with "Group" in the previous descriptions and figures to fully handle this case. The details are shown in the figures below.

 
 

Webratio Attachments

 

Related Learning Objects