Background
 
For the circulation manager to act against the RBdigital API on behalf of a patron (e.g. borrow a book, or get the list of existing loans), it must know the patron's RBdigital patronId. This is an internal ID associated with the patron's RBdigital account, which may not exist at the time the patron expresses their desire to borrow a book.
 
We defined the remote_patron_identifier_lookup method to look up a patron's RBdigital account based on some identifier. Currently the 'identifier' we use is a randomly generated string – an alias for the patron – which is not related to the patron's library barcode and is not used when talking to any other vendor.
 
The first time a patron wants to borrow a book, we generate this alias and use it in the lookup. When the lookup fails, we call the create_patron method to make an RBdigital account for this patron based on their alias. Once this succeeds, we know the patron's RBdigital patronId and we can use it to borrow a book.
 
The problem
 
The create_patron method no longer works in libraries where it used to work. We identified two reasons behind this:
 
1. An argument called "postalCode" is now required, but we're not providing it.
2. Library-specific validation is now being performed on the "libraryCardNumber", where previously there was no validation. Since the generated alias bears no resemblance to any library's actual barcodes, it always fails validation.
 
We want to address these issues without introducing the problem the alias system was designed to avoid:
 
3. A patron who's been using SimplyE goes to the RBdigital website but can't log in and can't recover their password, because SimplyE has claimed their RBdigital account for itself.
 
The solution
 
When the circulation manager needs to generate a patron alias, it will append six random alphanumeric characters to the end of the patron's barcode, rather than generating an alias completely at random. So if your barcode is 2333312345, your alias might be 2333312345GJCD6A.
 
RBdigital will change their validation code so that "barcode X with six extra characters at the end" validates the same as "barcode X". This should deal with problem 2.
 
 
The circulation manager will perform three lookups before deciding that a patron doesn't have an account, and that an account should be created:
 

• Lookup based on the patron's email address (if we know it from the ILS)
• Lookup based on the patron's barcode
• Lookup based on the patron alias
   
  This will increase the chance that SimplyE finds a previously created RBdigital account for this patron and doesn't have to create a new one.
   
  When the circulation manager does need to create an account, if it knows the patron's email address it will use that address as the "libraryCardNumber" (not sure about this – please confirm). A patron who later decides to use the RBdigital web interface can go through the password recovery process to gain access to the account created for them by the circulation manager. This avoids problem 3.
   
  If the circulation manager doesn't have the patron's email address, it will use the patron alias as the "libraryCardNumber". Since we don't know the address, it's impossible to trigger the password recovery process for this account. A patron who later decides to use the RBdigital web interface will need to create a second account based on their actual, non-aliased library card. This avoids problem 3.
   
  When creating a patron account, the circulation manager will always send "1111" as the value for "postalCode". This should deal with problem 1.
   
  If I encounter any other validation problems, I'll escalate them to RBdigital.