Return to ForceIDChange.tex CVS log

Up to [LON-CAPA] / loncom / html / adm / help / tex

Annotation of loncom/html/adm/help/tex/ForceIDChange.tex, revision 1.2

1.1       raeburn     1: \label{ForceIDChange}
                      2: Although the username is the principal unique identifier for a user in LON-CAPA, the student/employee ID
                      3: is a secondary identifier, which needs to be defined (and unique) for certain applications.
                      4: 
1.2     ! bisitz      5: The default is not to allow the student/employee ID for an existing user to be changed when
1.1       raeburn     6: modifying a user's information in course, author or domain context.
                      7: 
                      8: This default can be overridden by checking the ``Force change of existing ID'' checkbox. If that is
1.2     ! bisitz      9: done the old ID will be replaced with the new ID. (Note: the new ID can not be blank; i.e., once an ID
1.1       raeburn    10: has been set for a user, it can be changed to a different ID, but not set to be null).
                     11: 
1.2     ! bisitz     12: A side effect of updating a student/employee ID is that the database file used for the quick
        !            13: look-up of username for a specified student/employee ID will be updated. This can potentially impact 
1.1       raeburn    14: bubblesheet grading, if there is a possibility that student/employee IDs are not unique.
                     15: 
                     16: However, there is no requirement to set a student/employee ID for a user, and you will not encounter
                     17: issues doing that unless you attempt bubblesheet grading or uploading scores from a csv file 
1.2     ! bisitz     18: containing IDs and points as column data. If either of those actions are likely to occur in courses
1.1       raeburn    19: in your domain you should attempt to ensure that student/employee IDs are unique.
                     20: 
                     21: Your domain may have been configured to automatically update student/employee IDs from an institutional
1.2     ! bisitz     22: data source. Similarly, IDs may be retrieved (and set) automatically when creating a new user, if the
1.1       raeburn    23: username is for an institutional user, and your domain has been configured to support that.
                     24: 
1.2     ! bisitz     25: Individual courses contain their own database files of class rosters, which include a copy of each
        !            26: student's ID. If a student/employee ID is changed by a Domain Coordinator, there is an option to
        !            27: propagate that change to the individual classlist database files for courses in which the student has
        !            28: a role that is currently active, or one that will become active in the future.