National Association of Writers and Groups (testing site – not for public use – official site: www.nawg.co.uk)

Website Plans: Restricted Areas Specification

NAWG Website

Restricted Areas: Requirements & Specification

Introduction

This article sets out details of what's needed, in order to support the following facilities on the website:

• Members-only areas, e.g:
  • Extra benefits for writing groups and individuals.
  • Early access to Link magazine on-line.
  • Discussion forums.
• Administrative areas, e.g:
  • Organisational things for committee purposes.
  • Administration for competitions and events.
  • Internal resources such as membership lists and planning documents.
• Other areas requiring privacy from the general public, e.g:
  • Content management: adding new material, editing existing material.

Important: Please note that a major purpose of this article is to stimulate discussion and feedback about these matters. It's not a set-in-stone prescription.

The goals are:

1. To make sure everyone understands what's involved.
2. To identify and solve potential issues sooner, rather than later.
3. To design facilities that will benefit our membership and ourselves.

Your time and help are greatly appreciated.

Summary (TL;DR) ↑

The key points to take away are:

• We'll provide and maintain user accounts, in order to provide the facilities we want.
• This may involve an appreciable overhead for us, in terms of management.
• We're also developing a content privacy system to make things work.
• We have a project plan, which is designed to be: evolutionary, agile, iterative, changeable.

General Requirements ↑

In order to provide the facilities we want, we need to:

1. Be able to distinguish between different types of visitor to the site, for example:
   • General public.
   • Group and individual members.
   • Patrons and other special guests.
   • Staff, such as committee members.
2. Be able to restrict some of the site's content to particular people, for example:
   • Only members can access the members-only areas.
   • Only NAWG staff can access the administrative areas.
   • Any visitor can access the unrestricted public areas of the site.

Solutions to General Requirements ↑

There are many ways that our general requirements could be satisfied. What follows is just a particular set of solutions that have been chosen, based on developer experience and early feedback.

1. Provide login accounts for different kinds of users, allowing us to distinguish between them. A site visitor who's logged in can be distinguished from one who is not.

   In addition, we can associate different roles for different user accounts. This will allow us to distinguish between (say) a group member and a committee member, based on what role they have.

2. Implement a content privacy feature to the website. This will be a software system that controls who has access to which content. This will also be based on the roles model.

User Accounts ↑

One of the key requirements behind the facilities we want to provide, is the ability for a visitor to login to the website, in order to gain access to the extra areas they're entitled to.

For this to be practical, we'll need to maintain a collection of user accounts on the site. The details of these will need to be carefully though out but, as a minimum, each account will need:

• A unique identifier, such as a number and/or login name.
• A password for security purposes.
• A display name, by which the user can be recognised, e.g. their real name.
• A unique email address, for communication, automated or otherwise.
• An assigned role – these are documented in a later section.

Allocation of User Accounts ↑

We need to consider exactly who gets to be able to log in and have a role on our site. This may include some or all of the following:

• Group members.
  • Shared logins per group?
  • Separate logins for each group member?
• Individual members.
• Patrons.
• Special guests?
• Staff members.
  • Committee members.
  • Others? Agents?

The decisions we have made so far are:

• Initially, only staff will be able to log in. This is during the period where we are testing the system, using ourselves as Guinea pigs.
• The next stage will have a single log-in for all members, whether individuals or group members. This is to keep things simple and have minimal management overheads.
• Later on, we may have multiple log-ins. This has yet to be decided.

Registration ↑

Each distinct user will need a login account on our website. There are two ways these can be created:

1. Manually: Create the user accounts on request by members. This would need to be handled by people with administrative access to the site's user management area.
2. Semi-automatically: Allow users to register themselves. This would require verification that they really are members of NAWG.

We have chosen option 1: to manually create accounts as and when they are needed. This gives us more control over who can log in.

Logging In and Out ↑

If a user visits the website without logging in, then they'll only be able to access public material.

Once they're logged in, their role will come into play. This will determine which materials they can access.

To log in, they provide their login name and password. To log out, a special action link can be provided on the website.

Facilities need to exist for users who forget their login name and/or password.

User Roles ↑

A visitor to the website is either not logged in, and therefore has no role, or is logged in granted a designated role. The roles give users particular capabilities. This is already a general feature of WordPress, the software platform that our website is built on.

A summary of the standard WordPress roles is given in the table below:

Role	Capabilities
Visitor	(Not logged in.) Can only read public content.
Subscriber	Can read public and some private content.
Contributor	As above but can also submit new content.
Author	As above but can also directly add new content.
Editor	As above but can also change/delete existing content.
Administrator	Full capabilities.

By assigning appropriate roles to the website's users, we can also control which content they can access. For example:

• NAWG committee members can be authors, allowing them access to all areas, including "administrative" areas.
• NAWG group members and individuals can be subscribers, allowing them access to "members only" areas, but not administrative areas.

Note that the roles described above are the default ones. Customised roles are also possible, though this would require more research and experimentation, to determine the details of what's possible.

User Management and Support ↑

Depending on how we decide to allocate logins, we could have hundreds or even thousands of user accounts on our site. This could potentially incur a large amount of management and support work.

It's hard to estimate this without any data to go on, though the author's feeling is that it could be high, due to the fact that many of our membership may be relatively unskilled with computers and information technology. This is based on a limited experience on the author's part, so may prove to be an invalid assumption.

The following table shows some anticipated support and management issues, together with possible solutions or mitigations.

Please have a think about the cases where no solutions are listed, or the solutions are weak. Obviously, we can provide help by email, telephone or post, but we need to minimise the amount of our time this will take up.

Please also consider what else we haven't yet thought of.

Content Privacy System ↑

User accounts are only one side of the equation. We'll also need a software system in place, to manage who has access to which materials on the website.

In general, the content restrictions will be:

• Based on the concept of privacy levels, associated with roles.
• Configurable and changeable. In the future, we may decide to tighten up or relax restrictions in particular areas.
• Hierarchical and utilising inheritance. This is mainly for reasons of technical and administrative convenience.
• Defaulting to err on the side of restriction, to avoid security issues.

Privacy Levels ↑

Each piece of web content, such as an article or downloadable document, can be assigned a privacy level. This will determine who is permitted to access that item.

The proposed privacy levels are as follows:

Level	Description
0	The item is public; everyone can access it.
1	Restricted to users with subscriber role and above.
2	Restricted to users with contributor role and above.
3	Restricted to users with author role and above.
4	Restricted to users with editor role and above.
5	Restricted to users with administrator role.

Please note that these have been designed with simplicity and ease of implementation in mind, given that our web software platform (WordPress) already has support for role-based capabilities.

Content Hierarchy ↑

People unfamiliar with the workings of WordPress, the website's content management software, may not realise that the content is organised in a hierarchical manner.

Here's an overview, showing a generic example:

Parent taxonomy    (e.g. category "Events")
        ↓
Child taxonomy     (e.g. category "Events/Wentworth")
        ↓
Particular article (e.g. "Wentworth: Booking")
        ↓
Parent comment     (i.e. a direct comment on the article)
        ↓
Child comment      (i.e. a reply to the above comment)

Another example might be:

Parent page        (e.g. "Home")
    ↓
Child page         (e.g. "Headlines")
    ↓
Attachment         (e.g. an image or downloadable document)

The above examples are somewhat simplified for clarity. Deeper and more complex hierarchies are possible.

Privacy Configuration and Inheritance ↑

The privacy level for a given piece of content is derived according to the following scheme:

1. If there is one, use the level assigned directly to the item, or…
2. Use the hierarchy (if any) and inherit level(s) from that, or…
3. Use the default configured level for that type of item, or…
4. Use the value 5 – the safest.

The inheritance method is more complicated than simply assigning a level to every piece of content. However, it's more powerful and flexible. It also requires less manual work by an administrator.

An example of this would be setting up a "committee" area (article category) on the website, that is to be accessible only by people with author role.

• Without inheritance, every new article, comment, attachment in that category would have to be manually set to level 3, upon creation.
• Using inheritance, the category itself is set to 3 (once). Then all new items in "committee" are left unassigned and automatically inherit the value 3.

More sophisticated cases can be catered for by using the inheritance system, with minimal impact on manual administrative overhead.

Project Plan

Structure ↑

There are many aspects to the project some with strong inter-dependencies, which dictate a serial production schedule. Other aspects are less dependent on others and can therefore be produced in parallel.

As detailed in the requirements, the two major components to the project are:

1. User accounts.
2. Content privacy system.

In terms of production, these are largely independent and can be developed in parallel, although the basics of 1 will be required in order to test the operation of 2.

Underlying these two main components, there are many sub-components, forming a collection of distinct items to be delivered. Some of these items have a hierarchical relationship, whereas others are more independent.

Here is a rough structural breakdown:

User accounts	Credentials	Login, password;
	Roles	Define capabilities;
	Profile	Contact and personal/group information;
	Pages	Login, forgotten password.
Content privacy	Software package	Interfaces, classes, objects, WordPress content filters;
	Configuration	Settings for site and content hierarchy.

Phases ↑

The following list of phases may be applied to the project's various components.

• Specification
• Design
• Implementation
• Testing
• Deployment
• Maintenance
• (Withdrawal)

Please note that not all phases need apply to all components. Also note that the phases are usually sequential but not necessarily in all cases. They are an approximate breakdown of work to be done, not an exact one.

As the methodology is an iterative one (see below), there are likely to be many cycles through the phases, not just one.

Methodology ↑

Where possible, agile methods will be used to deliver the project. This will allow us to respond more quickly to any changes along the way.

We will also be using iterative methods. This is more of a try it and see approach with frequent feedback and adjustment, rather than attempting to over-prescribe everything at the start.

Schedule and Deliverables ↑

Here is a rough outline of the project schedule and its deliverables. It will be filled in with more detail as things evolve.

All future dates are estimates and subject to revision.

Date	Milestone	Notes
Mon-21-Nov-2016	Project starts.
Fri-13-Jan-2017	Prototype delivery.	For committee use only, to try out as "Guinea pigs".
	Testing & feedback.	By all committee.
	Revision.
	Retesting.	By all committee.
Mon-20-Mar-2017	First release.	Single account for all groups and individuals.
	Members' feedback.
	Revision.
Mon-01-May-2017	Second release.	Multiple accounts.
	…

Exit Strategy ↑

At present, we do not have a specific agreed exit strategy for the project.

If the workload in maintaining the restricted areas feature proves to be too much, then the following actions are likely to take place:

Next Steps ↑

The next things to do for this project are:

1. [On-going] Read, discuss, and revise the ideas in this article, so that we're all happy with them.
2. Plan the remainder of the project. In particular:
   1. [Done] The methodology and approach to the project.
   2. [Done] The phases of the project, e.g. design, development, testing, deployment, maintenance, withdrawal (if necessary).
   3. [Done] How to iterate and cycle through the phases.
   4. [Partially done] Schedules and timetables for the above.
   5. Devise an exit strategy, in case we ever need one.
3. [On-going, at development stage] Produce the facilities, according to our plans.
4. Deploy the facilities, according to our plans.
5. Maintain and support the facilities.
6. (Only if necessary) withdraw the facilities according to our exit strategy.

Issues ↑

The following issues are known and, as yet, unresolved.

1. Some items are not under the control of the content privacy software. Such items may be required to be restricted, but there is no current specification nor technical design for this. Such items include:
   1. Downloadable files such as documents and media.
   2. Attachments to articles.
2. Although the main content for restricted articles is withheld, some of the other attributes are still displayed. This may or may not be what we want and needs further discussion. Attributes include:
   1. Article excerpts.
   2. Article titles.
   3. Article authors' names.
   4. Article posting dates.
3. Following on from the above issue, we need to decide how restricted articles' comments are displayed. Possibilities include:
   1. Completely suppress the display of all comments for a restricted article.
   2. Display the count, i.e. total number of comments, only.
   3. Display comment attributes, such as authors and dates, but no content.
4. How are we going to inform our members about their restricted areas? In particular:
   1. Make them aware of their existence?
   2. Promote their use?
   3. Distribute credentials such as login names and passwords?
   4. Handling of forgotten passwords?
   5. Handling of compromised passwords?
5. The staff and committee will need user accounts, as will our members. Are there others who might need to log in and view restricted content? For example:
   1. Associates and helpers who are not official staff?
   2. Patrons and/or other dignitaries?
6. What support will we offer our website users with accounts? How will this be delivered in practise? We have agreed to share he support duties among the committee, but we have no actual plan in place.

7. It is possible for the privacy system to be bypassed. This could happen if a user, with sufficient capability, changes the display theme to one which does not hook into the content filters.

   This is a fairly unlikely scenario and all of the currently installed themes work correctly, but it is a technical design limitation which may need addressing in the future, as the WordPress core evolves and new themes become available.

Author: Kevin Machin ♦ Created: 20-Jan-2017 ♦ Access: public ♦ Article: site-plans-restricted-areas-spec ♦ Topics: old WordPress site, plans, website