Niedermayer.ca
Published on Niedermayer.ca (https://niedermayer.ca)

Home > User Management System (UMS) -- Detailed System Design > The User Management System > General Project Requirements

General Project Requirements

The Great Plains Free-Net Inc., based in Regina Saskatchewan, is a non-profit, volunteer-driven corporation dedicated to providing low and no-cost internet connectivity to residents, community groups and organizations that are not sufficiently served by commercial Internet Service Providers (ISPs).

In particular, the Great Plains Free-Net caters to individuals:

  • whose personal computers are too old or antiquated to run current generation web-browsers and other internet client software;
  • who want a text only user interface to a graphical user interface because of personal preference or disability;
  • who are new to the Internet environment and who need more “hand-holding” and support that commercial ISPs are prepared to offer; or
  • who are not heavy users of the Internet and who do not require the unlimited or generous usage offers characteristic of many commercial offerings.

For community groups, the Great Plains Free-Net offers:

  • no and low cost web hosting to community groups seeking to inform the public of their services and programs;
  • e-mail list services to cyber-communities for whom face-to-face meetings are unrealistic;
  • Database hosting services for dynamic web content; and
  • Virtual domain hosting on a cost-recovery basis for community groups, individuals and organizations that wish to pay for this service.

Because of the mix of products and services offered to the public, the Great Plains Free-Net (GPFN) needs a User Management System (UMS) to manage its user base. As GPFN is volunteer driven, this system needs to be managed remotely by volunteers. As GPFN exclusively uses a Linux server base, any new system should be implemented in a Linux environment and be Internet and Web enabled.

In general, the UMS needs to provide the following functions:

  1. Allow users and prospective users to use the Web to apply for a new user account;
  2. Allow existing users to apply to upgrade their account to include new services or increased quotas;
  3. Allow GPFN volunteers to approve or reject applications for new accounts or account upgrades and, if approved, effect the necessary changes to the system;
  4. Allow users some access to their own system configuration such as changing their password, reviewing their account history, changing mail forwarding settings, and possibly adjusting spam filters;
  5. Allow GPFN volunteers access to change the configuration parameters listed in function (4) above for any GPFN user;
  6. The GPFN charges for memberships and other services based on a calendar year. The system must support a “renewal cycle” whereby all existing GPFN users are asked to explicitly renew their account. This renewal is validated by responding to an e-mail notification (in the case of free accounts), or by remitting a cheque for any memberships or service fees. This renewal cycle is generated through a scheduled task (or “cron job”) or via a GPFN volunteer’s explicit action;
  7. The renewal cycle must not generate renewals for accounts which are not in arrears and must be able to generate a paper invoice or statement upon request;
  8. The system must allow GPFN volunteers to process receipts against outstanding renewal requests so that user accounts are not again flagged for renewal notification during the current renewal or billing cycle;
  9. The system must allow GPFN volunteers to expire or suspend accounts for any reason such as a user misusing their account or not responding to a renewal request. If a user remedies the reason for the suspension, the system must allow a GPFN volunteer to reinstate a previously suspended account. Alternatively, the system must also allow GPFN volunteers to delete any account previously expired;
  10. In order to support expirations due to non-renewal, the system must be able to offer a “batch mode” whereby all non-renewed accounts are listed and expired together. Similarly, once a decision is made to delete accounts, the option should exist to allow a volunteer to delete all expired accounts as a batch process;
  11. The system must maintain a history of the financial transactions against an account including the date and method by which a renewal notification was sent (either e-mail or printing), and the date and method by which a payment was received (cheque, cash, donation in kind, or credit card);
  12. For audit purposes, the system must track the GPFN volunteer who performed any action.
     
  • Log in [1] to post comments

Project Justification

To date, GPFN has used a software package called Chebucto Suite to perform all User Management functions. The Chebucto Community Network in Halifax, Nova Scotia wrote Chebucto Suite (or Csuite). It uses a collection of about 300 shell scripts and a series of flat file datastores to manage all aspects of a user’s account on the system. Because of the changing nature of the Internet market space, Csuite development is now halted as is system support and maintenance.

Csuite assumes that all users will interact with the system using the Csuite shell or “Cshell”. This Cshell is a restricted, custom compiled version of a lynx web browser. Lynx is a text-only web browser that renders HTML pages without displaying any graphics. The Csuite version of Lynx allows users to use keystrokes to branch off into a file editor, a mail reader (pine), as well as manage or review aspects of their user.

Csuite was written for RedHat Linux 4.1. GPFN is planning to upgrade to RedHat Linux 7.2 for its new server. A number of security concerns, new features, and system libraries predicate the need for this upgrade. However, in initial examination of the Csuite package, it is likely that any attempt to migrate Csuite to this new Linux platform would necessitate a line-by-line review of the existing Csuite code. Such a review would be very costly in terms of volunteer personnel resources and would be very specialized work. As well, GPFN did not use some Csuite features while Csuite could not support other desired features.

At the same time, new technology in existence since Csuite was initially developed means that the backend datastores can use a complete Relational Database System (RDBS) such as MySQL. The application logic can use newer more capable implementation languages. This combination of a RDBS and new implementation languages will result in a robust system that is more flexible to the business needs of GPFN and will require less development effort than that required for the rewrite of Csuite.

  • Log in [2] to post comments

Business Case

GPFN is embarking on a comprehensive modernization strategy. As part of this strategy, GPFN is offering a number of new services and adopting a more member-centric philosophy. One problem with the existing system is that very few volunteers understand or can manage Csuite. Therefore member inquiries, problems or complaints often took a number of days to resolve. This delay resulted in member and volunteer frustration. At the same time, the Csuite package was hard-coded in terms of services and member categories, resulting in a collection of ad-hoc systems, databases and other methods to manage services and membership classes specific to GPFN.

While GPFN wants to maintain the Cshell for use by members and users who have older equipment, a growing number of members do not use Cshell. These members often use GPFN’s PPP connection for graphical web browsing, some POP client to connect to GPFN’s mail servers, or a third party high-speed internet connection to view GPFN’s web resources. For these users, a web-enabled system to allow them to review their account settings and change account parameters (such as passwords) is important.

  • Log in [3] to post comments

User Requirements

It is expected that GPFN volunteers would interact with the new system using a graphical web browser. However, there will be users and volunteers who prefer the Lynx browser as their user interface. For this reason, any user interface should be implemented so that it does not make use of a graphics intensive front end. Similarly, the use of imagemaps, Javascript, applets, Shockwave and Flash media is not appropriate.

  • Log in [4] to post comments

System Requirements

Because GPFN is a volunteer-driven, non-profit organization, cost containment is always an organizational issue. The UMS must be implemented in as cost-efficient a manner as possible. This necessitates the use of open-source or ther free software and development tools; conversely, GPFN discourages the use of products which require license fees or other costs.

Because GPFN’s environment is exclusively based on Linux, any system must be implemented on the latest release of RedHat Linux. At the same time, because Linux is a constantly evolving operating system, any system should be sufficiently flexible and robust that it can be ported to newer releases of RedHat as those releases become available.

This requirement can be met by attempting to confine operating system specific calls to a single layer within the application environment.

  • Log in [5] to post comments

Source URL:https://niedermayer.ca/node/57

Links
[1] https://niedermayer.ca/user/login?destination=node/57%23comment-form [2] https://niedermayer.ca/user/login?destination=node/58%23comment-form [3] https://niedermayer.ca/user/login?destination=node/59%23comment-form [4] https://niedermayer.ca/user/login?destination=node/60%23comment-form [5] https://niedermayer.ca/user/login?destination=node/61%23comment-form