User Tools

Site Tools


dev:browser_staff:patron_editor_reqs

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
dev:browser_staff:patron_editor_reqs [2015/04/13 18:27] – created klussierdev:browser_staff:patron_editor_reqs [2022/02/10 13:34] (current) – external edit 127.0.0.1
Line 1: Line 1:
-===== Re-write Patron Editor in AngularJS (DRAFT) =====+===== Re-write Patron Editor in AngularJS  =====
  
  
Line 15: Line 15:
     - Users should be able to tab to the Save button from the last field in the form.     - Users should be able to tab to the Save button from the last field in the form.
     - A keyboard shortcut should also be available to save the form.     - A keyboard shortcut should also be available to save the form.
-  - Example text should be provided for the following fields: date of birth, email address, all phone fields, and postal code. The default example text should honor the regexes 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 settingIf 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.+  - Surveys configured for the workstation OU should display as they currently display in the XUL client. 
 +  - 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.
   - 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.   - 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.
     - 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.     - 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.
Line 34: Line 35:
       - add a message to the patron record with an invalid email or invalid phone alert.       - add a message to the patron record with an invalid email or invalid phone alert.
     - Adding a new email address or phone number to these patron records should clear the message from the record.     - Adding a new email address or phone number to these patron records should clear the message from the record.
-    - An option should be available to add a secondary permission group to the user account. This option should only be available when editing existing user accounts. +   - 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. 
-    - 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. +   - 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. 
-    - 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: +   - Any field documentation configured for the workstation OU should display as a hovertip for the corresponding field label.  
-      - First and Last Name +   - 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: 
-      - Address +     - First and Last Name 
-      - Phone number +     - Address 
-      - Email address +     - Phone number 
-    - When registering a new patron, the following fields should populate with the following defaults: +     - Email address 
-      - The Password and Verify Password field should default to a random, four-digit number. +  - When registering a new patron, the following fields should populate with the following defaults: 
-      - The Primary Identification Type, Country, and Internet Access Level fields should default to the value set in the corresponding organizational unit setting. +    - The Password and Verify Password field should default to a random, four-digit number. 
-      - The Home Library field should default to the workstation OU. +    - The Primary Identification Type, Country, and Internet Access Level fields should default to the value set in the corresponding organizational unit setting. 
-      - The Active field should default to true. +    - The Home Library field should default to the workstation OU. 
-      - The Hold Notification Format field should default to both phone and email. +    - The Active field should default to true. 
-      - The Address should default to both Mailing and Physical.  The Address Type text field should default to Mailing. +    - The Hold Notification Format field should default to both phone and email. 
-      - The Valid Address? field should default to True. +    - The Address should default to both Mailing and Physical.  The Address Type text field should default to Mailing. 
-     - When entering a zip code, the system should utilize the zips.txt file to automatically populate the City field. +    - The Valid Address? field should default to True. 
-     - The patron registration form should provide data validation. +   - When entering a zip code, the system should utilize the zips.txt file to automatically populate the City field. 
-       - 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. +   - The patron registration form should provide data validation. 
-         - It should validate that all required fields contain data. +     - 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. 
-         - 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. +       - It should validate that all required fields contain data. 
-         - It should validate that the data entered in the Password and Verify Password fields match. +       - 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. 
-         - It should validate that dates match the date format organizational unit setting. +       - It should validate that the data entered in the Password and Verify Password fields match. 
-       - 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. +       - It should validate that dates match the date format organizational unit setting. 
-         - 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. +     - 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. 
-         - 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. +       - 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. 
-       - 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. +       - 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. 
-       - When a user clicks the Save button for a new patron registration, the system should: +   - 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. 
-         - Perform any necessary validation, as described in 15 above; +   - When a user clicks the Save button for a new patron registration, the system should: 
-           - If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data. +     - Perform any necessary validation, as described in 15 above; 
-         - Save data entered through the patron registration form. +       - If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data. 
-         - Load a new patron registration form. +     - Save data entered through the patron registration form. 
-       - When a user clicks the Save button after editing an existing patron record, the system should: +     - Load a new patron registration form. 
-         - Perform any necessary validation, as described in 15 above; +   - When a user clicks the Save button after editing an existing patron record, the system should: 
-           - If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data. +     - Perform any necessary validation, as described in 15 above; 
-         - Update new data entered through the patron registration form. +       - If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data. 
-         - Return to the existing patron’s record in the patron editor. +     - Update new data entered through the patron registration form. 
-       - When a user clicks the Save & Clone button, the system should: +     - Return to the existing patron’s record in the patron editor. 
-         - Perform any necessary validation, as described in 15 above; +   - When a user clicks the Save & Clone button, the system should: 
-           - If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data. +     - Perform any necessary validation, as described in 15 above; 
-         - Save data entered through the patron registration form. +       - If data is invalid, the system should return an invalid data message, returning the user to the form to correct the invalid data. 
-         - Open a new patron registration form populated with the address and phone number of the original patron. +     - Save data entered through the patron registration form. 
-         - 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. +     - Open a new patron registration form populated with the address and phone number of the original patron. 
-The system should honor the Patron Registration: Cloned patrons get address copy organizational unit setting. +     - 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. 
-If this setting is null or set to false: +     - The system should honor the Patron Registration: Cloned patrons get address copy organizational unit setting. 
- the new patron registration form should display, but gray out the address fields so that they cannot be edited.  +       - If this setting is null or set to false: 
-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. +         - the new patron registration form should display, but gray out the address fields so that they cannot be edited.  
-When this patron registration form is saved, it should link to the address of the primary user in the database. +         - 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. 
-If this setting is set to True: +         - When this patron registration form is saved, it should link to the address of the primary user in the database. 
-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. +       - If this setting is set to True: 
-When this patron registration form is saved, it should create a new address in the database for this user. +         - 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. 
-The Cloned patron should become part of the original patron’s group. +         - When this patron registration form is saved, it should create a new address in the database for this user. 
 +       - The Cloned patron should become part of the original patron’s group. 
  
 +==== Table of Contents ====
 +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]]
  
-Additional quote for Table of Contents +  - 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. 
-MassLNC also seeks a separate quote for the addition of a table of contents to the patron editor, as demonstrated in the recent UI mock-up created by OPW intern Julia Lima. See: +  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.
-http://media.tumblr.com/69beec7802a938b889bdfa80c7e0d54b/tumblr_inline_nkn0okinXl1t572gy.png +
- +
-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. +
-A widget should be available to remove the table of contents from the display. The status of the widget should be sticky across login sessions.+
  
dev/browser_staff/patron_editor_reqs.1428964059.txt.gz · Last modified: 2022/02/10 13:34 (external edit)

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

© 2008-2022 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a U.S. 501(c)3 non-profit organization.