Configuring user profiles

Working sessions in siguanet-desktop are tied to user profiles. The concept is introduced in the Generating remote settings files and the Application configuration pages. These are the points you should already be familiar with:

• You should create one .srs file per profile, so that standard users don't have to manually connect to PostgreSQL.
• You should deploy the corresponding .srs file through HTTP so that, upon application login, siguanet-desktop can build the PostgreSQL connection string according to the user's profile.
• You should create one .sgd file per profile in order to define the set of functions which meets the needs of each user's profile.
• You should deploy the corresponding .sgd file through HTTP so that, upon application login, siguanet-desktop can enable and load those tools that are suitable for the user's profile.

Here we'll focus on profile management and how to create and deploy profile definition documents, also named siguanet-desktop documents ( .sgd ).

Profile management

As of version 1.2, there are 4 predefined user profiles embedded in siguanet-desktop's object model, as seen in the ProfileType enumerated type:

• Anonymous is intended for users who choose anonymous access on application login, that is, people who don't strictly belong to your organization and are not provided with means of identification.
• Normal is intended for users within your organization.
• Manager is intended for users that have governing or executive responsibilities within your organization (e.g. university chancellors or vice-chancellors).
• Root is a special profile reserved for application and system administrators.

You should create an .sgd file for each of these 4 base profiles, typically in a cumulative way. The default profile discovery method uses the personal table in your SIGUANET database as a backend, although you can provide your own discovery logic, as explained in the Implementing user authentication page.
As for the built-in discovery method, users who access siguanet-desktop anonymously or cannot be authenticated are assigned the Anonymous profile. On the other hand, authenticated users are assigned the Normal profile. From the SIGUANET database point of view, you should assume that Normal users are those present in your personal table. Finally, Manager and Root users are those who belong to your personal table and are explicitly assigned one of these two user profiles. So, you simply run this SQL insert to assign a particular user the Manager profile:
UPDATE personal SET perfil = 'MANAGER' WHERE nif = '00000014Z';
Or this one to assign the Root profile:
UPDATE personal SET perfil = 'ROOT' WHERE nif = '00000014Z';
Where '00000014Z' is the personal identifier of the user in question.

The application allows one user to have multiple profiles. Having said that, there's no need for a Root user to have multiple profiles since, by design, siguanet-desktop allows Root users to impersonate any other user profile upon application login. There's no point either for Manager users to also access as Normal users, since in practice the Manager profile should be thought of as an extension: the Manager profile definition document will normally enable the same tools and functions than the Normal one, plus some others. Multiple profiles are simply stored in personal.perfil field as a comma separated list.
Multiple profiles make sense when you need to provide individual users with custom profiles in addition to their base profile. There is no restriction on the number of custom profiles that a user may be assigned. In the end it's just a matter of providing the corresponding profile definition document. A custom profile will always reference a base profile, and its implementation differs slightly between Anonymous users and authenticated users. Let's see both cases.

Custom profiles for Anonymous users

Imagine you want an external collaborator to evaluate some functionality which is not intended for Anonymous users but, since she doesn't belong to your organization there's no way for her to login as an authenticated user. The way for you to go is:

• take a copy of the Anonymous profile definition document;
• edit the document and enable the target tool or functions;
• tag the document with a custom profile name, that is a short significant string in a single word;
• save and deploy the new document to your .sgd HTTP directory;
• eventually communicate the custom profile name to your collaborator so that she can supply it on application login.

There's currently no way to revoke an Anonymous custom profile. Removing the XML document file from the .sgd HTTP directory makes no solution, since the user may still have a local copy that the application can load. So, do not grant Anonymous custom profiles if you think that the information provided by the functions in question may be sensible.

Custom profiles for authenticated users

Let's say there's someone named Pickwick within your organization who is in charge of collecting all kinds of aggregated data for making up some really serious statistical charts and reports. This guy desperately needs access to a subset of the siguanet-desktop functions that are intended for Manager users, but he works as an administrative assistant and you want the application to deal with him as a Normal user. This is what you should do:

• take a copy of the Normal profile definition document;
• edit the document and enable the target tool or functions;
• tag the document with a custom profile name (a single word), e.g. 'PICKWICK';
• save and deploy the new document to your .sgd HTTP directory;
• let's say the identifier of our good friend Pickwick is '000000042X'; hence, to assign him the new custom profile you'll need to run the following SQL using the naming convention [base_profile_name].[custom_profile_name]:
  UPDATE personal SET perfil = 'NORMAL.PICKWICK' WHERE nif = '00000042X';
• whenever you want to revoke Mr. Pickwick's custom profile, you should simply run: UPDATE personal SET perfil = NULL WHERE nif = '00000042X';

Creating .sgd files

You'll find .sgd file samples in the profile_samples/ folder, so in practice there's no need for you to start from scratch. You can work your own profile definition documents out from these templates. Anyhow, for the sake of completeness, we'll go over the process step by step.
First of all, remember .sgd files are human readable XML: you can modify them by hand. Moreover, an .sgd file is nothing but a product of serializing instances of the siguanet-desktop's document object model. So, there isn't any particular format involved, just plain objects.
Secondly, siguanet-desktop is itself an .sgd editor provided that you log in to the application as a Root user. Let's assume you're using the built-in profile discovery method. In this case, you need write privileges in your SIGUANET database personal table in order to assign yourself the Root profile. The assignment is made simply running the following SQL insert:
UPDATE personal SET perfil = 'ROOT' WHERE nif = 'your_identifier_here';