Restrictions And Permissions

Concept

This web site is generally restricted, with the exception of the root directory home page, http://www.vibrantelectroniccourse.com .  At that address you can read the first page (index.htm) and click to an article by me, Karl Loren, on the "state of study." That article draws on data in two folders which are also NOT restricted:

http://www.vibrantelectroniccourse.com/Education/

http://www.vibrantelectroniccourse.com/Data/

There is an "access page" (access.htm) which is planned to be the beginning of the initial page through which new people become registered for access to  further pages.

Registration Permission

No special permission is required for "registration" for this web site.  However, the only pages any person could view would be those relating to registration until his registration is complete.

Presumably the complete registration will involve his acceptance of a cookie, and the requirement that our program sends an eMail to the address he has given us during registration, and that he then clicks on a link on that eMail, as he receives it, to "activate" his registration.

Initial registration should ask for minimal data from the person.  He would need to supply a  username, real name and eMail address.  When he gets his "activation request" eMail, he would be given a temporary password and link to the registration section.  He would then be encouraged to visit the "registration record" to change the password to anything of his choice and to either add additional (optional) data or make changes.  NONE of these additions or changes should become effective until he has received and clicked on a "registration change activation link" in an eMail that would be automatically sent to his eMail address.

Activation of his registration should be completely automated and would give him the lowest level of permission into this web site.

Within this "low level" of the web site would be explanations of the courses, sample courses, a shopping cart feature for paying for courses, testimonials and whatever else we might want to place in this "low level" of access.

Some of these features may also or alternatively be placed in the root directory, not requiring either registration or permission.

Shopping Cart Permission

Use of the shopping cart will obviously require more than the minimal information initially required to access the "low level" parts of the web.  The registration section should offer optional fields for all the information that would be required for use of the shopping cart.

If a person chooses to use the shopping cart, the program should look for all the information required and, if found, allow the shopping cart usage to continue (presumably with a purchase) with no further input of personal information.

Student Permissions

Anyone who has completed the information necessary to use the shopping cart has already then completed any information still needed to obtain a "student permission."

Those who are already registered, and have one or another form of "permission" could immediately access some other page to which their "permission" grants them immediate access.

A student gains the next level of permission by paying a fee for an eCourse.  He then has a certain number of "points" which he can use to select a course within the range of his available points.

Course Permission

For instance, a student who has registered for  "How To Use A Dictionary" would receive the first segment of an eCourse.  It would be taken from a place like this:

http://www.vibrantelectroniccourse.com/E/A/1/index.htm

However, this file and all files in the "E" folder would be restricted.  The permissions must be scripted so as to provide access to one new file at a time, leaving all the old files still accessible.

In actual fact the way the eCourse was original designed included a page such as the above and each of the items on that page links immediately to some part of the eCourse.  When the permission concept is fully implemented the student who is properly registered COULD go, immediately, to some URL that ONLY allows those parts of the eCourse which he has already studied.  The above "index.htm" page should never be offered to a student until he has successfully completed the entire course.  Then, of course, that page would be a convenient way for the student to pick any part of the eCourse which he has done, and re-do that part. 

I presume we will make good use of both "session cookies" and "persistent cookies."

Cookies - General Information
Cookies are small pieces of text that a Web site can store on your computer and recover later. Session cookies only last as long as you are logged in or have your browser open. Permanent cookies are stored on your disc for use the next time you visit the site.  (Source)  (Source for more information on this web site.)

Presumably this specialized restriction and permission would depend on the data in the student's course record.  That record should show what parts of the eCourse have been completed, and to which full access continues to be available. 

Company Course Administrator

Eventually this entire eCourse concept will be promoted to other commercial firms.  For them I, Karl Loren, might develop the study material, or use their study material.  I might design the quizzes, or they might.  In any event, these other firms may well want to use a Learning Management System that has the features of this one.

The person in each Company who is authorized to examine the scores and progress of all the students in that section is called the Company Administrator.  When he has proven skills in publishing web pages to "his" section, he could be given that type of permission also.

As this potential develops, the Learning Management System should include flexibility of structure of the web site so that different sections of the web could be designated to be for the use of different groups of students.

For instance, the XYZ company may decide they want to place their company policies on this web site, and grant permissions to their own staff only to read the policies, and even to take eCourses based on those policies.

Presumably duplicate sets of MySQL tables as are used for this first venture would be created in separate web sections.  These separate web sections would have their own separate "restrictions and permissions" rules.

It could also be possible that the entire package, the Learning Management System along with some set of eCourses could be developed on this web, as a pilot, and when completed simply exported to a different URL.

Each such separate commercial firm would then be expected to have a level of permission that grants a "Company Administrator" access to any or all of the pages within that company's web section.  Generally he can look, but not change these pages.

In order to keep some aspects of the Learning Management System proprietary, it should be possible to keep some of the PHP coding outside any pages that could be accessed by a Company Administrator.  (This would call for the generous use of "included" files in the PHP code which is located in areas where some Company Administrator can go.)

Company Web Administrator

This is the person who has access to all the pages thus far described for any one Company.

He would be the one who uses the various Database Entry Screens to add new eCourses, review student progress and generally administer the section for one company.

Depending on the arrangements made with Karl Loren, this could be the person who designs eCourses or it could be Karl who does this part.

This person does not have access to the coding that supports all of the parts of the Learning Management System.  But, there should be "entry screens" whereby this person could add eCourses to the MySQL tables in his Company Section, and publish eCourses in that section. He would not have authority to make changes in structure of MySQL nor any changes in the coding for the PHP which administers and controls the tables.

Super Webmaster

This is the person who has authority to add to or revise any MySQL tables, or any PHP or other types of program coding -- anywhere on the web site.  In particular whatever part of those resources can be located outside the "company sections" would be accessible by this Super Webmaster.

Super Administrator

This is the person who controls the entire security system.  While every other level of permissions includes the authority to change data within the scope described, this Super Administrator is the only one who administers the security system and can change any other permission anywhere on this web.

This is the person who would authenticate new persons for any permission above that of student. The student permissions are controlled automatically. Any permission beyond that level would be through a "super registration" screen that would only be approved and implemented by this Super Administrator.