This section will focus on the many lists that the NetServer provides to make our lives easy. Here we will discuss: what these lists are, how we can use them, the most important list interfaces, and finally some examples of how we can use these lists.
Overview of lists
When developing applications, it is necessary to provide lists so that the users can be allowed to select items with ease.
In NetServer a list is a set of data presented as an object that can be directly bound to any control which supports lists. The advantage is that we do not have to construct the list, all we have to do is call a NetServer method, and then we can get the list made exactly the way it is created and managed in SuperOffice administration. This saves us a lot of time and we don’t have to do the complex things that involve building up a list like this all by ourselves.
- Web services:
Introduction to Multi-Department Organisation (MDO) lists
Larger organizations may need to hide non-relevant information from employees. This is now possible with the multi-department organization (hereafter referred to as MDO) lists.
To take templates as an example, this means that, if MDO is implemented in SuperOffice, a user will see only those templates, with a record in
TemplateGroupLink pointing to the UserGroup the user is a member of.
The templates will be grouped with headings taken from the
Heading table, and under each heading will be the templates that have a
TemplateHeadingLink record pointing both to the template and the
Heading. This means that a single template may appear several times in the list, under several headings.
Each primary list table will have two link tables related to MDO functionality: one for filtering and one for grouping.
Heading table contains the headings to be used in the MDO list boxes, for all lists.
Link table between a list and the
Heading table is always named
UserGroup table is treated in a special way. It has no direct
Link tables and is instead used by Link tables as a target to implement the MDO filtering.
An associate is a member of only one
UserGroup, as specified in the associate record. MDO filtering will be implemented by showing records from the other lists if, and only if, they have entries in the
<list table name>GroupLink.
The following diagram illustrates the new structure:
To make coding simpler, the List tables are defined in a specific order so that the table ID of the Link tables can be calculated from the main table ID. The order is:
|ID = k||Main table, for instance, Template|
|ID = k+1||GUI Group link, in this case, TemplateHeadingLink|
|ID = k+2||Filter link, in this case, TemplateGroupLink|
SQL Example - for context
Filter without heading
SELECT l.category_id, l.name FROM Category l, CategoryGroupLink gl, UserGroupLink ugl WHERE l.deleted = 0 AND l.category_id = gl.category_id AND gl.group_id = ugl.usergroup_id AND ugl.assoc_id = <my assoc_id>;
The result is a set of list names, filtered via the user's group membership. Items that the user is not allowed to see will not be returned.
Because a user may be a member of more than one usergroup we have to join against the UserGroupLink table.
Items that are visible to more than one group will be returned twice. Use
SELECT DISTINCT to filter the duplicates out.