Account Manager

Contents

1. Introduction
    1.1 Features
    1.1.1 For Blind and Visually Impaired Users
    1.2 Assumptions
    1.3 The Exemplum Primary School example

2. Account manager overview
    2.1 Users: introduction
    2.2 Groups: introduction

3. Users
    3.1 Add a new User
    3.2 Edit: User properties, access permissions, Group/Capacity memberships
        3.2.1 Basic: Edit User username (Full Name)
        3.2.2 Groups/Capacities
            3.2.2.1 Add a User to a Group/Capacity
            3.2.2.2 Remove a User from a Group/Capacity
            3.2.2.3 Change a User's Capacity in a Group
        3.2.3 Intranet
        3.2.4 Administrator permissions: username (Full Name)
        3.2.5 Page Manager
            3.2.5.1 Table: Roles and permissions
            3.2.5.1 Edit User username (Full Name)
    3.3 Delete a User account

4. Groups and Capacities
    4.1 Add a new Group
    4.2 Edit: Group properties, Capacities, add Users to Capacities
        4.2.1 Basic properties
        4.2.2 Capacities 1-8
    4.3 Add a User to a Group/Capacity
    4.4 Delete a Group

5. Skins
    5.1 Base Skin
    5.2 Big Skin
    5.3 Braille Skin
    5.4 Low vision Skin
    5.5 Text Only Skin

6. Concluding remarks

1. Introduction

In a typical school, with very many Areas (web sites) to manage, and sometimes with hundreds of Users, from pupils to the governing board, each with different access permissions, some with full and others partial or none, assigned to one or more Groups, with the possibility of different User permissions within each Group, and with many modules to manage, it becomes quite complex to administer and control a web site and its Users. Therefore good accounting management discipline becomes very important for the safety and proper administration of the web site.

In Website@School, we have tried to make account management as simple as possible by implementing a refined Role Based Access Control (RBAC) philosophy for Users and Groups. However this simplicity has one weakness; it is easy to make administrative errors. For example, by accidentally checking one box in a User account, you can incorrectly give that User full access to everything on the web site. So special care must be exercised when managing User accounts!

1.1 Features

These are the main features of the Account Manager in Website@School:

1.1.1 For Blind and Visually Impaired Users

Website@School has a selection of special fonts and color contrasted properties which Users can request their web pages to be displayed in. These selectable 'skins' can accommodate screen readers, braille terminals or other visual improvement tools. can accommodate screen readers, braille terminals or other visual improvement tools. The skins can be easily customized further to suit almost every visual impairment.

1.2 Assumptions

This chapter elaborates on other chapters. We assume you have read and completed the General part of the Table of Contents.

1.3 The Exemplum Primary School example

For Users with little account management skills, the demonstration data restored during the installation of Website@school, contains an example of a small school called the Exemplum Primary school, which can be used to practise the administration of a web site.
Exemplum Primary School demonstration data
Group Members
NoGroup [*] Wilhelmina Bladergroen (wblade) (webmaster)
Faculty Amelia Cackle (acackl) (Principal)
Helen Parkhurst (hparkh) (Member)
Maria Montessori (mmonte) (Member)
Juniors Georgina King (georgina) (Pupil)
Herbert Spencer (herbert) (Pupil)
Helen Parkhurst (hparkh) (Teacher)
Seniors Andrew Reese (andrew) (Pupil)
Catherine Hayes (catherine) (Pupil)
Maria Montessori (mmonte) (Teacher)
Team Amelia Cackle (acackl) (Member)
Freddie Frinton (ffrint) (Member)
Helen Parkhurst (hparkh) (Member)
Maria Montessori (mmonte) (Member)

(top)

2. Account Manager overview

To enter the Account Manager, click on its icon [ accounts ] to open the Account Manager dialogue:
[ Account manager, summary ]
accountmanager_account_manager_overview.png

The opening screen is divided into two parts:

After opening the Account Manager, the Account Manager overview shows a summary of the total active and inactive Users and Groups.

2.1 Users: introduction

There are three types of clients in Website@School:
  1. Regular visitors to a web site (Area) with no account to log in anywhere on the web site.
  2. Users with an account having permission to read only the Private Area(s) (i.e.Intranet(s)).
  3. Users with an account that permits them to perform management tasks in Website@School.

NOTE: Regular visitors (1) are just visitors, having no access at all.
Users with Intranet access (2) can log in to the web site using http://exemplum.eu/index.php.
Users (3) with enough permissions to do management tasks can log in via the management login dialogue using http://exemplum.eu/admin.php.

A User with only Intranet read permission who tries to log in using the suffix admin.php, is allowed to log in, but receives the Access denied dialogue:

[ Acces denied, select link ]
accountmanager_account_manager_access_not_valid.png

The User can now either:

NOTE: Newly created Users, whose access permissions were not set, receive the same Access denied message.

Logging in can be done by adding index.php and admin.php suffixes to the web site URL. When switching from viewing the web site to the management function or vice versa, the User does not have to log in a second time. When logging out of the web site, the User is also automatically logged out of Website@School management function and vice versa.

Clicking the Users link opens the Users dialogue:

[ Users, list ]
accountmanager_account_manager_users.png

Explanation:
Menu: The selected link is underlined.

NOTE: It is also possible to navigate to a User's account if you know to which Group the User belongs.

NOTE: The total number of Users in all Groups (23) exceeds the actual number of Users (9) defined; a User can be a member of one or more Groups. For example, the existing User Helen Parkhurst with login name hparkh is a member of four Groups:
  1. Under All Users,
  2. under Faculty as Member,
  3. under Juniors as Teacher,
  4. under Team as Member.
Therefore every User occurs at least twice in this list. Once under All Users and once under No group, or at least once in another Group. See the table below.

Users:

The relation between Users, Groups and Capacities
All Users faculty juniors seniors team
Amelia Cackle (acackl) Principal     Principal
Andrew Reese (andrew)     Pupil  
Catherine Hayes (catherine)     Pupil  
Freddy Frinton (ffrint)        
Georgina King (georgina)   Pupil    
Herbert Spencer (herbert)   Pupil    
Helen Parkhurst (hparkh) Member Teacher   Member
Maria Montessori (mmonte) Member   Teacher Member
Wilhelmina Bladergroen (wblade)        

Notice that Wilhelmina does not belong to any Group/Capacity. She is a member of the No group.

2.2 Groups: introduction

Groups, and their closely related subject Capacities, are not so easy to understand. To take full advantage of the almost endless possibilities of Website@School's RBAC design, we strongly advise you to read this section. The examples discussed here help you to understand the way Group and Capacities can be combined.

A Group is a collection of Users. Users (or members) of a Group share a single space (called a 'folder' or a 'directory') where files can be stored. The files are used in Sections and pages that the Group has access to.
A Group is always composed of one or more so-called 'Capacities'. A User within a Group is always associated with only one Capacity within that Group. The Capacity is what assigns the privileges to the User, for example to manage (parts of) the Page Manager or the Translate tool.

File Manager example
Group members can easily create links to existing files in the Group storage space from their web pages (via the Insert/Edit button in the (F)CKEditor), provided they have sufficient privileges for the Page Manager. Group members can upload files to this storage space, but only if they have sufficient privileges for the File Manager.

Example:
Andrew Reese and Catherine Hayes are members of the Group 'Seniors' in the 'Pupil' Capacity. Maria Montessori is also a member of the Group 'Seniors' but in the 'Teacher' Capacity. If Maria has access to the File Manager, she can upload files to the storage space of the Group 'Seniors'. If other Group members, like Andrew and Catherine, have access to the Page Manager (but not the File Manager), they can use the files Maria uploaded, but they cannot upload files themselves.

Page Manager example
Assume that Helen Parkhurst (the teacher of the Juniors) initially has no permissions whatsoever. This means that her account hparkh:
- is not associated with any Group/Capacity (Groups),
- has no privileges with any Private Area (Intranet),
- has no administrator privileges (Admin), let alone permissions to manipulate pages (Page Manager).

By associating her account hparkh with the Group Team in the Member-capacity, she inherits all permissions associated with the combination Team/Member. These permissions could include read access to the Private Area containing the Team Intranet.

If subsequently she is also associated with the Group Juniors in the Teacher-Capacity, she enjoys all privileges associated with the Teacher-Capacity of the Juniors-Group too. These privileges could include access to the File Manager and access to the Page Manager (say as Areamaster) limited to the (protected) Juniors Intranet.

Her pupils may also be associated with the Group Juniors but in the Pupil-Capacity rather than the Teacher-Capacity. Privileges associated with this Pupil-Capacity could be limited to viewing pages in the protected Juniors-Area, whereas the Teacher-Capacity would allow for adding to and editing pages in that (protected) Area.

The bottom line is that the total permissions for Helen Parkhurst consist of the combination of:
- those of her User account hparkh itself (no permissions), and
- Team/Member (Team Intranet), and
- Juniors/Teacher (File Manager, Page Manager for Juniors Intranet).

To expand on the above example: When Helen becomes Teacher of the Seniors next year, it is very easy to end her membership of the Juniors Private Area, make her a member of the Private Area of the Seniors and give the Teacher capacity of the Juniors to the her replacement teacher Mary Astell.

About the relationship between Users, Groups and Capacities:

  1. A User can be given zero, one or more privileges. For example the privilege to edit a certain page.
  2. A User can be a member of zero, one or more Groups with certain authority, i.e. Capacity.
  3. Each Group consists of one or more parts (subGroups) called Capacities. When a User is made member of a Group, the User inherits only one of the Capacities existing in that Group.
  4. A Group/Capacity combination can be assigned zero, one or more privileges, for example, the privilege to manage a certain Section.

The table below shows the relationships between the properties of Users, Groups and Capacities. Some properties (among others: data directory, active) belong to Group while others (permissions for Intranet, Admin, etc.) belong to Capacity.

Properties User Group Capacity
Name X X  
Password X    
Full name X    
Description   X  
E-mail X    
Active X X  
Capacity 1-8   X  
Redirection X    
Language X    
Editor X    
Skin X    
Data directory X X  
Group memberships X    
Intranet privileges X   X
Admin privileges X   X
Page Manager privileges X   X

The relation between properties, Users, Group and Capacity

To summarize:
A Group is a collection of Users. A User can only be associated with a Group via a single Capacity. A Capacity consists of a set of permissions. Each User within a Group can have only one Capacity in that Group. A User can be a member of more than one Group with different Capacities in each Group.

NOTE: Capacity names can be changed. For example, if your institution does not use terms like 'Principal', 'Teachers' and 'Pupils' but prefers to use 'Manager', 'Facilitator' and 'End Users', the label names can be easily changed. See chapter Tools, section 3.5 Small language adaptations.

[ Groups, list ]
accountmanager_account_manager_groups.png

Explanation:
Menu:

Groups:

(top)

3. Users

In this section, we will create a new User account, grant the User access permissions and make the User a member of an existing Group. Creating new Groups is discussed separately in 4. Groups and Capacities.

3.1 Add a new user

In the opening screen of the Account Managers Menu, click the Users link to open the Users dialogue:
[ Users, list ]
accountmanager_account_manager_users.png

To add a new User, click the Add a User link in the Users pane to enter the Add a new User dialogue:

[ Add a new User, entry fields ]
accountmanager_account_manager_users_add_user.png

The Add a new User dialogue is shown.

Explanation:

After clicking [Done], the User is added to the list:
[ Users, message= success, list ]
accountmanager_account_manager_users_user_added.png

The User is added to the All Users Group (now 10 Users) and the No Group (now 2 Users). The last Group contains the Users who do not (yet) belong to a Group. Adding a User to a Group is discussed in 3.2.2.1 Add a User to a Group/Capacity.

User's access permissions will be discussed in the next section.

3.2 Edit User properties and grant access permissions

All new Users are initially given no permissions at all. This is a security feature. However the User can, like everyone else, visit the Public Areas of the web site.
The permissions for a User can be set from five points:

3.2.1 Basic: Edit username (Full Name)

To edit the Basic properties of the User account, click its pencil icon or the username. This opens the Edit User username (Full Name) dialogue:
[ Edit User username (Full Name), entry fields. Page top ] [ Edit User username (Full Name), entry fields. Page bottom ]
accountmanager_account_manager_edit_user-top.png

accountmanager_account_manager_edit_user-bottom.png
In the Menu the Basic link is selected (underlined).

Explanation:

3.2.2 Groups/Capacities

In this section we will add a User to an existing Group. The creation and management of Groups is discussed in section 4. Groups.

3.2.2.1 Add a member to a Group/Capacity

A User can be made a member of one or more Groups. To add a User to a Group, go to the Account Manager overview and in the Menu, click the Users link to enter the list of Users dialogue. Select the User by clicking on the Pencil icon to enter the Edit User username (Full Name) dialogue.
Next, in the Menu, click the Groups link, to enter the Memberships username: (Full Name) dialogue:
[ Memberships username (Full Name) ]
accountmanager_account_manager_user_memberships_none.png

In the Menu, the Groups link is underlined. And in the workplace it can be seen that the User is not a member of any Group.
Click Add a Group membership to enter the Add a Group membership to User username: (Full Name) dialogue:

[ Add a group membership to User username (Full Name), drop down menu: New group/capacity: faculty/Member selected ]
accountmanager_account_manager_user_group_add_membership.png

Mary Astell is a new teacher, so she will be made a member of the Group 'faculty' in her Capacity as Member. Open the dropdown menu and select faculty/Member. Next click [Done] to save the change and return to the list of Memberships username: (Full Name) dialogue:

[ Memberships username (Full Name), message= success ]
accountmanager_account_manager_user_group_membership_added.png

The User is now a member of the Group: Group name (Short description of Group) / Capacity

Now check the Intranet permissions of Mary by clicking the Intranet link in the Menu to enter the Intranet access: username(Full Name) dialogue:

[ Intranet access: username (Full Name), Related: faculty/Member Access ]
accountmanager_account_manager_user_group_member_intranet.png

Observe that in Intranet access: username (Full Name) under Related, Mary is a member of the Group 'faculty' with Capacity Member and has Access permissions to the Exemplum Intranet.

NOTE: If "faculty/Member Access" is not shown, these permissions were not set for that Capacity. The permissions can now be set via: Account Manager > Groups > Group name > Capacity name > Intranet/Admin/Page Manager.

NOTE: Adding a User to a Group/Capacity has the advantages that all permissions required by the User are set in one action. This saves time and prevents errors occurring.

NOTE: Files in a Group directory are publicly accessible when the file and path names are known.

3.2.2.2 To remove a User from a Group/Capacity

To remove a User from a Group/Capacity, go to the Account Manager overview and click the Users link to enter the list of Users dialogue.
Select the User by clicking on the Pencil icon to enter the Edit User username (Full Name) dialogue.
Next, in the Menu click the Groups link, to enter the Memberships username: (Full Name) dialogue:
[ Memberships username (Full Name) ]
accountmanager_account_manager_user_group_membership_take_away.png

In the Menu column, the Groups link is underlined.

NOTE: There is no warning message issued when a User is removed from a Group after clicking the Trashcan icon. However, it is easy to reassign a User to a Group by repeating the procedure in section 3.2.2.1 Add a member to a Group/Capacity.

To remove a User from membership of a Group, click the Trashcan icon associated with the Group/Capacity.
Only the User's membership of the Group is removed; the Group itself continues to exist.

3.2.2.3 Change a User's Capacity in a Group

If you need to change a User's Capacity in a Group, first take away his membership from the Capacity before assigning him another Capacity. A User can have only one Capacity at any one time in a Group.

3.2.3 Intranet

To grant a User access permissions to one or more Intranets, click the Intranet link to open the Intranet access: username: (Full Name) dialogue:
[ Intranet access: username (Full Name), dropdown menu: Role: Guru selected ]
accountmanager_account_manager_user_intranet.png

In the Menu column, the Intranet link is underlined.

NOTE: Do not accidentally grant a User the Guru permissions to 'All current and future private areas' (Intranets)! It is advisable to grant this permission only to Wilhelmina Bladergroen, the webmaster of the Exemplum Primary School, or to Amelia Cackle.

The Intranet permissions are:

3.2.4 Administrator permissions: username (Full Name)

A User can be granted permissions to different Website@School management tools. Click the Admin link to open the Administrator permissions username: (Full Name) dialogue:
[ Administrator permissions: username (Full Name). Page top ] [ Administrator permissions: username (Full Name), checked: Basic administrator, Page Manager, File manager. Page bottom ]
accountmanager_account_manager_user_admin_administrator_permissions-top.png

accountmanager_account_manager_user_admin_administrator_permissions-bottom.png

In the Menu column, the Admin link is underlined.

Explanation:

[1]
NOTE: Assigning the Users and Groups (Account Manager) to a User is risky. With this permission, a User can promote himself to Guru status or give another User the Guru permissions.

Notice that Mary Astell has the Roles: Basic administrator, Page Manager and File Manager.

3.2.5 Page Manager

3.2.5.1 Table: Roles and permissions

The User's or Group/Capacity permissions to the Page Manager are set according to Roles. Roles are sets of permissions. There are seven Roles available for managing the site, the Areas, the Sections and the pages. The Roles and their permissions are described below in ascending order of authority:
  1. --: Null. This role is equivalent to no permissions at all. It is the default setting except for the person who originally installed Website@School, who has Guru (all) permissions.
  2. Contentmaster: Only page content can be modified.
  3. Pagemaster: Page properties and page content can be modified.
  4. Sectionmaster: Section properties can be modified and subSections and pages can be added.
  5. Areamaster: Area properties can be modified and top-level[*] Sections and pages can be added.
  6. Sitemaster: Site properties can be modified and Areas, Sections and pages can be added.
  7. Guru: Everything: this role provides all possible permissions, perhaps even more.

[*] Top-level, in this case, means that the Sections and pages are visible in the menu bar of a theme. The possibility to add a top-level Section or page influences the number of items in the main menu of an Area (the horizontal top row in themes like Frugal or Rosalina). A page in a Section, or a Section in a Section, is not considered a top-level page or Section.

The table below shows the permissions associated with the various Roles.
 
  Content
master
Page
master
Section
master
Area
master
Site
master
Content C of page P in section S or area A X X X X X
Page P in section S or area A - X X X X
Section S in area A - - X X X
Area A - - - X X
All current and future areas - - - - X

Legend: '-' means not allowed ; 'X' means allowed.

Note: The 'Null'-role is not shown because this Role has no permissions associated with it. The Guru role is also not shown because this Role has all permissions.

Example:
A pupil is given the Contentmaster permission and his teacher gets the Pagemaster permission. This combination enables the pupil to create only the content on an invisible or inactive page given to him by the teacher. The teacher can modify the content, make the page visible or set embargo/expiry dates with the Pagemaster permissions.

When the Page Manager was selected in the previous section '3.2.4 Administrator permissions: username (Full Name)', the Page Manager link is added to the Menu of the Edit User username (Full Name) dialogue:

[ Edit User username (Full Name), message= success, Page Manager link added ]
accountmanager_account_manager_edit_user_pagemanager_added-top.png

In the Menu, select Page Manager to open the Page Manager permissions: username (Full Name) [nn-nn of nn] dialogue:

[ Page M manager permissions: username (Full Name), drop down menus ]
accountmanager_account_manager_edit_user_pagemanager.png

3.2.5.2 Edit User username (Full Name)

Now we can grant the Page Manager permissions to Mary Astell. She is a new User to Website@School so we grant her Guru permissions in the sandbox, i.e. the Exemplum inactive Area. This Area is segregated and no one can see what takes place in this enclosed area.

[ Page Manager permissions: username (Full Name) [nn-nn of nn], drop down menus: Role: Area 3: Guru selected ]
accountmanager_account_manager_edit_pagemanager_expanded.png

NOTE: Be careful ! Do not accidentally give a User permission to 'All current and future areas'.

Notice the You are here: breadcrumb trail, indicating what web page you are on, and allowing easy navigation to the higher pages. The Page Manager permissions: username (Full Name) [nn-nn of nn] can sometimes indicate that the list of allowable Intranets is longer than shown on this page.
The View: at the bottom of the page allowes easy jumping to other page(s).
Also notice the opened Area 3: Mary Astell has no pages created by her as yet.

Explanation:

NOTE: You can modify the permissions by selecting a different value from the drowpdwon menu. You can also revoke the permissions by selecitong the -- None value.

3.3 Delete a User account

To delete a User account, navigate to the Account Manager, click on the Users link to open the list of Users dialogue:
[ Users, list ]
accountmanager_account_manager_users_with_mastell.png

Click on the Trashcan icon to open the Confirm delete of User username (Full Name) dialogue:

[ Confirm delete of User username (Full Name) ]
accountmanager_account_manager_delete_user_account.png

Click [Delete] to delete this User account or [Cancel] to abort the Delete action.

NOTE: By deleting the User account, all ACL's (Access Control Lists), all records from the database belonging to this User and all data associated with this User are deleted.
An access control list (ACL) is a list of permissions attached to Users, to processes and to operations. Each entry in a typical ACL specifies a subject and an operation. For example, when a teacher leaves the school, his User account is deleted, as well as his membership of the Group team and his access permissions to read certain pages in the Intranet.

NOTE: If all directories, subdirectories and files belonging to a User are to be deleted, all the files in the directories belonging to him must be deleted before deleting his User account. If any direcory is not empty, an error message is displayed (This is a design feature).

[ Error: remove files and folders first ]
accountmanager_account_manager_delete_user_account_error.png

Beware: Deleting files can cause broken links in pages.
NOTE: The empty data directory itself is not deleted automatically.

[ Error: Delete file ]
accountmanager_account_manager_delete_file.png

NOTE:
1. In general any file in the data folder of an active User, an active Group or an active public Area can be retrieved by anyone as long as the name of the file is known.
2. If a User, Group or Area is inactive, no files can be retrieved, even if the name of the file is known. In other words, once a User, Group or Area is made inactive, it appears to a visitor as if the account or the Area or the files do not exist anymore.

NOTE: Bear in mind that everything existing in a public Area is always publicly accessible once a visitor knows the file path to the file. If you need a protected place for files, use an Intranet instead. A Rule of Thumb: everything is publicly accessable except that which is not public.

At this point, we will not delete Mary's account.

(top)

4. Groups and Capacities

We will assume you have read section 2. Account Manager overview, in which Groups and Capacities are explained and examples are given. In section 3. Users, the Groups, Admin and Page Manager were discussed, but now they are treated from a different perspective, i.e. a Group as a collection of permissions given to a User.

Here is an example to illustrate the power of the Group/Capacity feature:
Suppose you can grant twenty parents each with permissions to read only the Parents Intranet (Role: Access), together with permissions to do 'everything' (Role: Guru) in just one Section of the Parents Intranet. (This is possible but it entails actions which can be error prone; doing the same mouse clicks repeatedly twenty times.)
It is far easier to create a Group called 'Parents', set the properties of the Capacity once as described above (carefully checking your work!), and make the twenty parents members of the Parents Intranet Group. Using this technique makes it easier to add, change, or remove properties of a Group/Capacity.

To understand the technique we have created two accounts: Mr. W.G. Spencer, father of Herbert Spencer (Junior pupil) and Mrs. A. Hayes-Hall, mother of Catherina Hayes (Senior pupil).

4.1 Add a new Group

After clicking the Account Manager icon, you are on the Account Manager overview page:
[ Account manager, summary ]
accountmanager_account_manager_overview_users_added.png
NOTE: The number of Users has increased from nine to twelve (Mary Astell, Mr. Spencer and Mrs. Hayes-Hall).

In the Menu, click the Groups link to enter the Groups dialogue:

[ Groups, list ]
accountmanager_account_manager_group_open.png

Clicking the Add a Group link, opens the Add a new Group dialogue.

[ Add a group, entry fields, Page top ]
accountmanager_account_manager_group_add_group-top.png

Explanation:

In the bottom part of the Add a new Group dialogue, the capacities can be selected:

[ Page bottom. Drop down menu: capacity 1: Member selected ]
accountmanager_account_manager_group_add_group-bottom.png

Explanation:

After selecting one or more Capacities, click [Done] to add the Capacities to the Group:
[ Groups, list, message= success ]
accountmanager_account_manager_group_added.png

In the list (next to the Trashcan and the edit icons) the name of the new Group and its corresponding Capacities are shown:
Group name (Capacity name 1, Capacity name 2, ..., Capacity name 8).
Both the pencil icon and the Group name take you to the Basic Properties dialogue. The names of the Capacities are direct links to dialogues where permissions can be assigned to that Capacity.

4.2 Edit: Group properties, Capacities, add Users to Capacities

To edit the properties of a Group, open the Groups list. Click on the pencil icon or the name of the Group to edit the Basic properties in the Edit a Group dialogue:
[ Edit a Group, entry fields. Page top ] [ Edit a Group, entry fields. Page bottom ]
accountmanager_account_manager_edit_group-top.png

accountmanager_account_manager_edit_group-bottom.png

In the Menu column of the web page:

4.2.1 Basic properties

Explanation:

4.2.2 Capacities 1-8

Clicking on one of the Capacity names in the Menu opens the Overview: Group name - Capacity name dialogue:
[ Overview: group name - Capacity ]
accountmanager_account_manager_group_capacity_overview.png

4.3 Add a User to a Group/Capacity

This subject is discussed in section 3.2.2.1 Add a User to a Group/Capacity

Summary: go: You are here: accounts &gr; Users > ahayes > groups > Add a Group membership > dropdown menu: parent/Member

[ Groups, list ]
accountmanager_account_manager_groups_members_parents.png
accountmanager_account_manager_groups_members_parents

4.4 Delete a Group

To delete a Group, go to the Account Manager, click on the Groups link to open the list of Groups dialogue:
[ Groups, list ]
accountmanager_account_manager_groups_with_parents.png

Click on the Trashcan icon to open the Confirm delete of Group Group name (Short description of the Group) dialogue:

[ Confirm delete of group name (Description) ]
accountmanager_account_manager_delete_group.png

Click [Delete] to delete this Group account or [Cancel] to avoid creating orphaned web pages.

NOTE: By deleting the Group account, all ACL's (Access Control Lists), all records in the database for this Group and all data associated with this Group are deleted. An ACL is a list of permissions attached to Users, to processes and to operations. Each entry in a typical ACL specifies a subject and an operation. For example, when a teacher leaves the school, his User account is deleted, as well as his membership of the Group team and his access permissions to read certain pages in the Intranet.

NOTE: If you want to physically delete all directories, subdirectories and files, do that as a separate action before deleting the User account. Deleting files can cause broken links in web pages. An empty data directory itself is not deleted automatically.

NOTE: Remember that everything that is located in a public Area is publicly accessible once a visitor knows the file path to a file. If you need a protected place for files, use an Intranet. The Rule of Thumb is everything is public except that which is not public.

(top)

5. Skins

Skins are a feature specially designed for blind and visually impared Users. Skins define the 'look and feel' of Website@Schools management interface.
The skin can be selected in the Edit User username (Full Name) dialogue, described in section Basic: Edit User username (Full Name) at Skin.

NOTE: Here is an interesting feature. After logging in with http://exemplum.eu/admin.php, you can change Skins 'on the fly'. In the browser enter one of the following URL's:

 
    http://exemplum.eu/admin.php?skin=base
    http://exemplum.eu/admin.php?skin=textonly
    http://exemplum.eu/admin.php?skin=braille
    http://exemplum.eu/admin.php?skin=big 
    http://exemplum.eu/admin.php?skin=lowvision
    

Below are some examples of web pages belonging to the management functions that can be modified to help Users with impaired vision or other visual disabilities.
Skins can be created for almost every form of low vision or color blindness.
NOTE: Skins can only be applied to the management web pages of the product and not to the web pages created by Users and seen by visitors.

5.1 Base Skin

[ Skin: base ]
accountmanager_account_manager_skins_base.png

This is the standard (default) appearance of the management web pages of Website@school.

5.2 Big Skin

[ Skin: big ]
accountmanager_account_manager_skins_big.png

This is an example of a management web page with enlarged fonts and icons.

5.3 Braille Skin

[ Skin: braille ]
accountmanager_account_manager_skins_braille.png

The Skin for use with braille terminals is designed in such a way that accessing the main functions is achieved with minimal tabbing.

5.4 Low vision Skin

[ Skin: lowvision example ]
accountmanager_account_manager_skins_lowvision.png

This is a rather artificial example, only to demonstrate the almost endless possibilities of Skins for visually impaired Users.

5.5 Text only Skin

[ Skin: text only ]
accountmanager_account_manager_skins_textonly.png

This is an example of a management web page without icons.

(top)

6. Concluding remarks

The main points in this chapter are:

(top)


Author: Dirk Schouten <dirk (at) websiteatschool (dot) eu>
Last updated: 2014-1-02, version 1.11