Scroll

Hierarchical logins

Follow
Summary This article describes the hierarchical logins in askiavista.
Applies to askiavista
Written for Data processor
Keywords hierarchical; logins; vista; askiavista

 

This article is a stub - yet to be completed.

Improvement of askiavista hierarchical access to the database

I. Introduction

For large end-user clients, there is a need to extend the concept of packages. If a company is global, there will be standardized way of comparing countries, regions, cities and individual outlets. The range of responses available for the outlet question will depend upon who is logging in: the shop manager will only see its shop, the regional manager will see all shops in its region and the MD will have access to everything.

1. Extend the packages?

We could extend the concept of packages to support not only questions but also individual responses. The problem is that we would have to generate thousands of packages (one for each user). Furthermore, the concept is so often used among our clients that we would have to create a tool to manage these packages.
And one of the side effects of this would be to dramatically increase the size of the XML files.

2. Hierarchical login

The other alternative is to introduce Hierarchical logins.
We define N questions that will represent the hierarchy. For each user, we have assign hierarchical level (0 – N), and a link to a modality in its level.
For instance:
We could have the following 4 questions: Continents, Countries, Cities, Outlets.
The shop manager of a shop in London could only see his shop in the Outlet but could see all cities in his country and all countries in his continent.
The England regional manager would see all the outlets in England, all the cities in England, etc…
The database will indicate for each outlet, its parent city, its parent country and parent continent.
This table could be used for storing the information (which would mean that there is no limitation on the number of levels)

II. Hierarchical data tables

1. Level table

Field name Field type Description
LevelKey String (unique id) Key of level (without spaces and special characters except the “_”)
ParentLevelKey String Key of parent level
Name String Name of level
QuestionShortcut String Shortcut of question


Nota: To have cross-survey compatibility we use the shortcut of questions
Nota2: To manage the deletion and the restoration we use a key instead of an auto-increment id

Example:

LevelKey ParentLevelKey Name QuestionShortcut
Continent   Continent Continent
Country Continent Country Country
City Country City City
Outlet City Outlet Outlet


2. Hierarchy table

Field name Field type Description
LevelKey String Key of level
Key String Entry code of response
ParentKey String Entry code of parent response
Name String Caption of response


Nota: To have cross-survey compatibility we use the entry code of responses

Example:

LevelKey Key ParentKey Name
Continent EUR   European
Continent AME   American
Country UK EUR United Kingdom
Country FR EUR French
Country US AME United States of America
Country BR AME Brazil
City LON UK London
City PAR FR Paris
City NYC US New York City
City RIO BR Rio de Janeiro
Outlet LON1 LON First outlet in London


3. UserRules table

Field name Field type Description
UserId Integer askiavista User ID
Rules String Visibility rules of user


Example:

UserId Rules
1 continent{~All~;~Exc[ASI] }country{~Parent~}city{LON;PAR}outlet{~Parent~}


See the “Visibility rules” part for details.

4. RulesTemplate table

Field name Field type Description
TemplateKey String (Unique id) Key of template (without spaces and special characters except the “_”)
Name String Name of template
Description String Description of template
Rules String Definition of rules


Nota: The system again uses a key to support the reading of rules.

Example:

TemplateKey Name Description Rules
WorldMgr World Manager   continent{~All~}country{~All~}…
ContMgr Continent Manager   continent{#0#}country{~Parent~}…
CountryMgr Country Manager   continent{~Child~}country{#0#}…
CityMgr City Manager   … country{~Child~} city{#0#} …
OutletMgr Outlet Manager   …city{~Child~}outlet{#0#}


See the next section, III. Visibility Rules, for more details.

III. Visibility Rules

1. Definition of rules and keywords

To cover all possibilities, we define some visibility rules:

Rules Description Keyword
All All responses are visible for the current question (level). ~All~
The new responses will be automatically added.
For example: All continents, all countries or all cities...
Only selected The only selected responses are visible Entry codes separated by semi-colons ;
For example:
Asia;Europe or Japan;England or Osaka;London
Inherits from parent selection All responses are visible according to the parent selection ~Parent~
For example:
- If I can see the Europe then I can see all countries in Europe
- If I can see England then I can see all cities in England
- If I can see London then I can see all outlets in London
Inherits from child selection All responses are visible according to the child selection ~Child~
For example:
- If I can see one outlet in London then I can see London
- If I can see London then I can see England
- If I can see England then I can see Europe
All child of specify parent All responses of specify parent(s) ~ChildOf (Name of level , FirstEntryCode,
For example:
- See all countries of Europe SecondEntryCode,...)
- See all cities of France
None of selected The selected responses are not visible ~Exc[ (List of entry codes separates with “;”) ]
This rules cannot be used with the rules ‘Only selected’, but can be used with all other
For example:
- All except London
- Inherits from parent except Europe
- Inherits from child except England
Use a template Use a template of rules: ~Template(Name of template,
For example:
- Manager of ‘Europe’ ReplaceFirstValue, ReplaceSecondValue,...)
- Manager of ‘Paris’  


A rule of level is enclosing with the “{“ “}” characters, the name is define before the “{“
The arrays of specific values are enclosing with “[““]” characters and separates with “;” (Exc)
The methods are enclosing with with “(“ “)” characters (Template, ChildOf)
The arguments of methods are separates with “,” characters.
The first argument of Template is the name of template
The first argument of ChildOf is the name of level

2. Examples of rules

Example 1

continent{~All~ ~Exc[ASI] }country{~Parent~}city{LON;PAR}outlet{~Parent~}

This rule means:

The user can see all continents except the Asia: continent {~All~ Exc[ASI] }
The user can see the countries of visible continents: country{~Parent}
The user can only see the London and Paris cities: city {LON;PAR}
The user can see all outlets in London and Paris: outlet {~Parent~}

Example 2

continent{ASI} country{~ChildOf (continent, EUR) ~Exc[FR]} city{~Child~} outlet{LON1;LON2}

This rule means:

The user can see the Asian continents: continent{ASI}
The user can see the European countries except the France: country{~ChildOf(continent, EUR) Exc[FR]}
The user can see the cities of visible outlets: city{~Child}
The user can see the first and second outlets of London: outlet{LON1;LON2}

Example 3

~Template (ContMgr , EUR)

This rule means:

The user is a manager of European continent.

Example 4

~Template (MultiRules , EUR , FR , PAR)

and definition of template is:

continent{#0#} country{#1#} city{#2#} outlet{~Parent~}

This rule means:

The user can see the Europe
The user can see the France
The user can see Paris
The user can see all outlets in Paris

Have more questions? Submit a request

Comments