Hierarchical Logins in AskiaVista
| Summary | This article describes the hierarchical logins in AskiaVista |
| Applies to | AskiaVista |
| Written for | Data processor |
| Keywords | hierarchical; logins; vista; askiavista |
Introduction
For large end-user clients, there is often a need to do more than can be comfortably handled with AskiaVista packages. Using a global retailer scenario as a case in point, there will likely be a need to measure and compare individual outlets by cities, regions and countries. The range of responses available for the outlet question(s) should depend upon who is logging in: e.g. the shop manager should only be allowed to see their shop; the regional manager will see all shops in their 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 hundreds or even thousands of packages (one for each user). Furthermore, the concept is commonly used among our clients, so the implication would be that we would have to create a tool to manage these packages.
And one of the side effects of all this would be to dramatically increase the size of the XML files.
2. Hierarchical login
Therefore the better alternative is to introduce Hierarchical logins.
Here, we define N questions that will represent the hierarchy. For each user, we assign a hierarchical level (0 – N), and a link to a modality in its level.
For instance:
We could have the following four questions: Continents, Countries, Cities, Outlets.
The shop manager of a shop in London could only see his shop at the outlet level, 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)
Hierarchical data tables
1. Level table
| Field name | Field type | Description |
| LevelKey | String (unique id) | Key of the level (without spaces and special characters except the “_”) |
| ParentLevelKey | String | Key of the parent level |
| Name | String | Name of the level |
| QuestionShortcut | String | Shortcut of the 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 |
France |
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.
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 the definition of the template is:
continent{#0#} country{#1#} city{#2#} outlet{~Parent~}
This rule means:
The user can see Europe
The user can see France
The user can see Paris
The user can see all the outlets in Paris