Evergreen DokuWiki

The goal of this project is to rewrite the current Dojo-based Evergreen patron editor into AngularJS.

The AngularJS interface should support the same functionality available in the Dojo-based patron editor, to include the following:

1. The ability to display all patron registration fields, suggested patron registration fields, or required patron registration fields.
   1. The interface should default to displaying all patron registration fields, except in cases where the “Default showing suggested patron registration fields” organizational unit setting has been enabled for the workstation OU. In those cases, the interface should honor the setting and default to displaying suggested patron registration fields.
   2. Toggles should be available allowing users to change displayed fields to all, suggested, or required.
2. The patron summary display in the left sidebar:
   1. should display when editing a patron record unless the user has clicked to collapse the display;
   2. should NOT display when creating a new patron record.
3. Options to Save and Save & Clone should be visible and easily-accessible no matter where the user has scrolled on the patron registration form.
   1. Users should be able to tab to the Save button from the last field in the form.
   2. A keyboard shortcut should also be available to save the form.
4. Surveys configured for the workstation OU should display as they currently display in the XUL client.
5. Example text should be provided for the following fields: date of birth, email address, all phone fields, and postal code. he default example text should honor the text supplied in the corresponding organizational unit settings or, in the case of date of birth, the format supplied in the Format dates with this pattern organizational unit setting If no date format is supplied, the default example text should follow existing practice for setting the default (appears to be the default format set for the locale). All other example text blocks should not display if no regex is supplied.
6. The user should NOT be able to change the barcode field directly. Instead, there should be a separate option the user must explicitly choose that allows the user to update the barcode.
   1. When the barcode is updated, the old barcode should be set to inactive and not primary, and the new barcode set to active and primary.
   2. A See All option should be available:
      1. Users should be able to view all active and inactive barcodes linked to the patron.
      2. Users should also be able to set primary and active barcodes here. They should have the ability to set multiple active barcodes.
7. An option should be available to generate a new password for the user. Clicking the option should:
   1. generate a random four-digit, numeric password.
   2. automatically populate the Password and Verify Password boxes.
8. The interface should honor the Patron: password from phone organizational unit setting. When this setting is enabled and the user is creating a new registration, the password field should automatically populate with a four-digit number matching the last four digits of the patron’s daytime phone number.
   1. The password field should NOT update when changing the daytime phone number of an existing patron.
9. After selecting a patron permission group, the interface should automatically populate the privilege expiration date field with a date. This date should be calculated based on the permission group’s permission interval.
10. An Update Expire Date option should be available in the interface. Selecting the option should update the patron’s expiration date based on the permission group’s permission interval.
11. Invalidate options should display adjacent to the email address and daytime phone fields.
    1. These options should only display when editing an existing patron and when there is valid data in the corresponding field. The options allow staff to mark an email address or phone number as invalid.
    2. Selecting the option should:
       1. clear the email address or daytime phone number from the record and
       2. add a message to the patron record with an invalid email or invalid phone alert.
    3. Adding a new email address or phone number to these patron records should clear the message from the record.
12. An option should be available to add a secondary permission group to the user account. At a minimum, Tthis option should only be available when editing existing user accounts.
13. The interface should allow users to apply user statistical categories that have been configured for the workstation OU or a parent of the workstation OU.
14. Any field documentation configured for the workstation OU should display as a hovertip for the corresponding field label.
15. The system should continue to identify possible duplicate patrons and display an alert if potential matches are found. The alert should provide a link allowing staff to open up a search results screen that retrieves potential matches. The system could continue to use the same logic as is currently used to identify potential duplicates, using the following fields as match points:
    1. First and Last Name
    2. Address
    3. Phone number
    4. Email address
16. When registering a new patron, the following fields should populate with the following defaults:
    1. The Password and Verify Password field should default to a random, four-digit number.
    2. The Primary Identification Type, Country, and Internet Access Level fields should default to the value set in the corresponding organizational unit setting.
    3. The Home Library field should default to the workstation OU.
    4. The Active field should default to true.
    5. The Hold Notification Format field should default to both phone and email.
    6. The Address should default to both Mailing and Physical. The Address Type text field should default to Mailing.
    7. The Valid Address? field should default to True.
17. When entering a zip code, the system should utilize the zips.txt file to automatically populate the City field.
18. The patron registration form should provide data validation.
    1. In the cases outlined below where data is invalid, the form should a) provide a visual cue that the data is missing or invalid and b) provide a message to the user upon form submission.
       1. It should validate that all required fields contain data.
       2. It should validate that text entered in the barcode, username, day phone, evening phone, email address, and postal code fields adhere to any corresponding regex entered as an organizational unit setting.
       3. It should validate that the data entered in the Password and Verify Password fields match.
       4. It should validate that dates match the date format organizational unit setting.
    2. In cases outlined below where a given field is not unique, the interface should immediately display a message after the user tabs/clicks to the next field in the form.
       1. It should validate that the barcode field is unique at the time that the text is entered. If it is not unique, the interface should display a message informing the user that the barcode is already in use.
       2. It should validate that the username field is unique at the time that the text is entered. If it is not unique, the interface should display a message informing the user that the username is already in use.
19. If the user tries navigating away from the patron registration form or refreshing the page before changed data has been saved, the system should provide a warning, giving the user the option to close or return to the editor.
20. When a user clicks the Save button for a new patron registration, the system should:
    1. Perform any necessary validation, as described in 15 above;
       1. If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data.
    2. Save data entered through the patron registration form.
    3. Load a new patron registration form.
21. When a user clicks the Save button after editing an existing patron record, the system should:
    1. Perform any necessary validation, as described in 15 above;
       1. If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data.
    2. Update new data entered through the patron registration form.
    3. Return to the existing patron’s record in the patron editor.
22. When a user clicks the Save & Clone button, the system should:
    1. Perform any necessary validation, as described in 15 above;
       1. If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data.
    2. Save data entered through the patron registration form.
    3. Open a new patron registration form populated with the address and phone number of the original patron.
    4. If the Save & Clone button is clicked from a new patron registration, the new form should open in the same tab. Otherwise, it should open in a new tab.
    5. The system should honor the Patron Registration: Cloned patrons get address copy organizational unit setting.
       1. If this setting is null or set to false:
          1. the new patron registration form should display, but gray out the address fields so that they cannot be edited.
          2. At the top of the address field, a message should display that says “This address is owned by another user: [Name of user].” The user’s name should be hyperlinked. When clicked, it should open, in a new tab, that patron’s record in the patron editor.
          3. When this patron registration form is saved, it should link to the address of the primary user in the database.
       2. If this setting is set to True:
          1. the new patron registration form should display with data from the address fields in the original patron’s record copied into the address fields for the new patron. These fields should be editable.
          2. When this patron registration form is saved, it should create a new address in the database for this user.
       3. The Cloned patron should become part of the original patron’s group.

An optional add-on component of this project is to add a table of contents to the editor as demonstrated in the recent UI mock-up created by OPW intern Julia Lima. See: http://media.tumblr.com/69beec7802a938b889bdfa80c7e0d54b/tumblr_inline_nkn0okinXl1t572gy.png

1. The table of contents should allow staff to quickly jump to major sections of the registration form - personal data (top of screen), user settings, address, and statistical categories.
2. A widget should be available to remove the table of contents from the display. The state of the widget should be sticky across login sessions.