[LON-CAPA-cvs] cvs: doc /loncapafiles loncapafiles.lpml loncom/html/adm/help/tex Domain_Configuration_Self_Creation.tex Domain_Configuration_Selfenrollment.tex

[raeburn]

raeburn		Thu Jun 26 15:04:02 2014 EDT

  Added files:                 
    /loncom/html/adm/help/tex	Domain_Configuration_Self_Creation.tex 
                             	Domain_Configuration_Selfenrollment.tex 

  Modified files:              
    /doc/loncapafiles	loncapafiles.lpml 
  Log:
  - Reorganization of domain configuration categories requires additiional 
    documentation files for Domain Coordinators.
  
  
Index: doc/loncapafiles/loncapafiles.lpml
diff -u doc/loncapafiles/loncapafiles.lpml:1.895 doc/loncapafiles/loncapafiles.lpml:1.896
--- doc/loncapafiles/loncapafiles.lpml:1.895	Sat Jun 14 15:22:34 2014
+++ doc/loncapafiles/loncapafiles.lpml	Thu Jun 26 15:04:02 2014
@@ -2,7 +2,7 @@
  "http://lpml.sourceforge.net/DTD/lpml.dtd">
 <!-- loncapafiles.lpml -->
 
-<!-- $Id: loncapafiles.lpml,v 1.895 2014/06/14 15:22:34 raeburn Exp $ -->
+<!-- $Id: loncapafiles.lpml,v 1.896 2014/06/26 15:04:02 raeburn Exp $ -->
 
 <!--
 
@@ -3428,6 +3428,8 @@
 Domain_Configuration_Request_Author.tex;
 Domain_Configuration_Request_Courses.tex;
 Domain_Configuration_Scantron_Format.tex;
+Domain_Configuration_Self_Creation.tex;
+Domain_Configuration_Selfenrollment.tex;
 Domain_Configuration_Server_Status.tex;
 Domain_Configuration_SSL.tex;
 Domain_Configuration_User_Creation.tex;

Index: loncom/html/adm/help/tex/Domain_Configuration_Self_Creation.tex
+++ loncom/html/adm/help/tex/Domain_Configuration_Self_Creation.tex
\label{Domain_Configuration_Self_Creation}

Domain-wide settings are available to set whether users may create their own accounts, and
if so, which types of users may do so, and what types of user information a user self-creating
an account will provide.

In the case of an institutional login, or single sign on (SSO), a user must first authenticate
with an insititutional username and password.  If user information is available from an
institutional data source via a query using the username (mediated via a customized routine in 
localenroll.pm), then that is used to populate appropriate data fields in the user's new LON-CAPA 
account.  A domain configuration is available to specify which fields the user may self-report,
if the corresponding institutional data are unavailable.

Which types of institutional log-in may self-create accounts can be restricted,
institutional status (e.g., Faculty, Staff etc.). The institutional status types are set in the
``Default authentication/language/timezone/portal/types'' item in the domain configuration
(this is a change from 2.10 and earlier, which used custom routines in localenroll.pm for that).

For Shibboleth SSO users, mapping of Shibboleth environment variable names to user data fields 
can be set, so that the appropriate user information is stored at account creation time.

Self-creation of user accounts may also be enabled for non-institutional login.  In this case
the user will provide an e-mail address as a username, and will also set a password.  The user must
have access to e-mail sent to that address, as completion of the account creation process requires 
submission of a link (containing a token), sent to the e-mail address.

In order to discourage creation of multiple accounts by a single user when self-creation is
available in a domain for both insitutional log-in and e-mail address as username, a domain
may want to consider implementing format rules which prohibit self-created accounts 
from using certain types of e-mail address as the username.

If a user attempts to self-create an account employing a username with an e-mail address
in a format which matches a defined rule, the action does not proceed, and
the user is directed to create an account with the corresponding institutional
log-in. In this case, account creation can only occur once the user has authenticated using that 
log-in.

Self-created accounts with an e-mail address as username can be set to be queued for approval 
or created automatically. Institutional status types can be set to be self-reported for e-mail
type usernames -- set in the ''Default authentication/language/timezone/portal/types'' area -- 
and processing (queued or automated) can be set, based on status.

User information (in addition to e-mail address and password) can be set to be required, optional
or not requested.

A Captcha mechanism can be used to validate that the user requesting a self-created account is
a person, not a script.  There are two types of CAPTCHA to choose from -- the ``original'' CAPTCHA, 
which uses a self-contained perl module included with the LONCAPA prerequisites, or ReCAPTCHA,
or ReCAPTCHA, which uses an external web service -- https://google.com/recaptcha --
and requires you to create an account and generate public and private keys which will be entered
in the LON-CAPA domain configuration form.  If you have more than one server in your domain, 
you should request ``global'' keys on the google.com/recaptcha site, as the same keys will be
used by the Account creation form's ReCAPTCHA on all servers in your domain.


Index: loncom/html/adm/help/tex/Domain_Configuration_Selfenrollment.tex
+++ loncom/html/adm/help/tex/Domain_Configuration_Selfenrollment.tex
\label{Domain_Configuration_Selfenrollment}
Ordinarily, course personnel (e.g., Coordinators) have the right to configure
self-enrollment settings in a course to determine which types of LON-CAPA user 
(if any) may request enrollment in their courses (and when), and how such requests
will be handled.

However, the domain can be configured such that control of self-enrollment
in courses is a domain coordinator action. Control over self-enrollment is very
granular - each of the seven settings can be set, by default, to be under the
control of domain coordinators, or under the control of course coordinators.
In addition domain-wide default settings can be overridden for each of the 
seven, on a course by course basis, by using the ``View or modify a course or community''
utility from the Domain Coordinators' main menu, to select a course, in which
to set different choices.

The seven self-enrollment settings are:
\begin{itemize}
\item Users allowed to self-enroll
\item Registration status (official courses)
\item Dates self-enrollment available
\item Access dates for self-enrolling users
\item Self-enrolling users' section
\item Processing of requests
\item Enrollment limit
\end{itemize}

The options for processing of self-enrollment requests are to: (a) process automatically, 
(b) queue pending approval, and (c) queue pending validation.

In the case of self-enrollment queued pending validation, the validation itself can be  
carried out via an external validation server/script.  Validation is configured at the 
domain level, by providing: (a) the web address of the validation server (and/or script),
the form fields to send to the validator -- one or more of: username, domain, six-character
code, course Id, coursetype (i.e., official, unofficial, community, or textbook course),
and course descripton (i.e., title).  The text used for the button displayed when a student
has submitted a self-enrollment request (for validation), as well as accompanying text (HTML 
format) can also be set in the domain configuration.