## Group Admin Pages - Design

ACS subsite docs : Group Admin Pages - Design

### I. Essentials

- ACS administrator directory (/admin/groups for each subsite)

- Tcl script directory
- PL/SQL packages

- Requirements document
- Acceptance test

### II. Introduction

The group administration packages provides a "control panel" to allow the administrator of a subsite to control the groups in use on that subsite. Administrators manage the types of groups in use on a subsite. For each of these group types, the administrator can create new groups, specify applicable relationship types, create relations between these groups, and modify attributes of the types and groups.

### III. Historical Considerations

Versions 4.0.x of the ACS lacked a useful group administration package for subsites. For example:

- Groups were given no context
- Groups could not be deleted
- Group types could not be created
- Relationships were limited to membership and composition, not including subtypes of these two.

This package addresses most of the short-coming of the previous subsites group administration package making group administration subsite aware and better integrated with the ACS Object Model.

### IV. Design Tradeoffs

Whenever possible, the design of this package tries to minimize disturbance to the core ACS 4.0 data model. Instead, we focus on adding a more powerful user interface and PL/SQL API to the existing group admin pages while extending the data model only when necessary.

### V. API

#### Permissible relationship types

We defined the following two tables to store the relationship type used to store the permissible relationship types for group types and individual groups. Whenever a group is created using the `acs_group.new` function, the relationship types for the new group are automatically copied from those allowed for its group type.

    create table group_type_rels (
           group_rel_type_id      integer constraint gtr_group_rel_type_id_pk primary key,
           rel_type		      not null
                                  constraint gtr_rel_type_fk
                                  references acs_rel_types (rel_type)
                                  on delete cascade,
           group_type	      not null
                                  constraint gtr_group_type_fk
                                  references acs_object_types (object_type)
                                  on delete cascade,
           constraint gtr_group_rel_types_un unique (group_type, rel_type)
    );

    create table group_rels (
           group_rel_id           integer constraint group_rels_group_rel_id_pk primary key,
           rel_type		      not null
                                  constraint group_rels_rel_type_fk
                                  references acs_rel_types (rel_type)
                                  on delete cascade,
           group_id	              not null
                                  constraint group_rels_group_id_fk
                                  references groups (group_id)
                                  on delete cascade,
           constraint group_rels_group_rel_type_un unique (group_id, rel_type)
    );

#### Dynamic subtypes of object types

To allow administrators to create dynamic object types (e.g. subtypes of the object types `group`, `membership_rel`, and `composition_rel`), we provide a TCL library of procedure that generate PL/SQL packages. For each dynamically created object type, we:

- We create the ACS object type
- We create a table to store the attributes for the new type
- We create a PL/SQL package with a new function and delete procedure

Whenever an attribute is added or deleted, a type added or removed, we regenerate some of the PL/SQL packages, based on the type hierarchy affected by the change.

Attributes themselves are stored using `type-specific` storage. For each new attribute, we create a column in the table dynamically created for the new object type.

To support the clean separation between programmer defined PL/SQL packages and automatically generated packages, we add the `dynamic_p` column to the `acs_object_types` table.

    acs_object_types.dynamic_p       char(1) default 'f'
                                     constraint acs_obj_types_dynamic_p_ck
                                     check (dynamic_p in ('t', 'f'))

Note that the `dynamic_p` is still experimental and may be removed in a future version of ACS

### VII. Data Model Discussion

...

### VIII. User Interface

The user interface comprises entirely of administrative pages located in the `/admin/` directory of the subsite package.

### IX. Configuration/Parameters

The revised group administration pages require no new package parameters.

### X. Future Improvements/Areas of Likely Change

There are many areas for improvement to the user interface, including tighter integration with the relational segments and constraints packages. One major improvement would allow individual subsites to define their own group types and relationship types, separate from any other subsite. However, since ACS object types are not themselves objects, it is difficult to properly scope object types.

We also may add a few additional package parameters including:

- "Create Group Types" (Boolean). Determines whether new group types can be created dynamically.

- "Create Relationship Types" (Boolean). Determines whether new relationship types can be created dynamically.

### XI. Authors

This document is primarily the result of discussions between Oumi Mehrotra and Michael Bryzek. Bryan Quinn and Rafi Schloming provided key insights early in the development process.

- System creator: mbryzek@arsdigita.com
- System owner: mbryzek@arsdigita.com
- Documentation author mbryzek@arsdigita.com

### XII. Revision History

Document Revision # | Action Taken, Notes | When? | By Whom?
--- | --- | --- | ---
0.1 | Creation | 11/30/2000 | Michael Bryzek
1.0 | Major Revision | 1/11/2001 | Michael Bryzek

group-admin-pages-design.html,v 1.1.4.1 2001/01/12 22:43:33 mbryzek Exp