"ptuoh" (There was no other identifying information.)
- Discuss stories regarding user searching
- Follow up on the reporting tickets - should we send them back to the LDP SIG?
|5 min||Assign note taker||Maura Byrne|
|30 min||Reporting JIRA tickets||Patty W.|
Patty proposed that JIRA tickets REP-259 and REP-260, discussed last week, be given back to Reporting SIG. In-app reports are supposed to be designed to be frequently run, with no changes to the search parameters. REP-259 (Report of registered users) is required for German libraries, as it is necessary for annual statistics. Bjorn says they need the information, specifically the number of users, but not necessarily an in-app report. Jana asked if the information was in the LDP, what was the benefit of an in-app report? Some scenarios were brought up, such as sending email to all current users regarding building closures or similar.
Each in-app report uses data one source, so if the report doesn't exist it would be really easy to write the SQL to do it. And if the data is in the LDP, the canned report is not necessary.
|25 min||Discuss user searching||Patty W., Jana F.|
Patty gave us an update on UXPROD-2092 (Improve searching in User app). The individual searches were broken out into UIU-1706 (Add search type: Last name with explicit truncation); UIU-1707 (Add search type: username with explicit truncation) and UIU-1708 (Add search type: barcode with explicit truncation). This means that searching for a last name "John" will return all last names of "John," while a search for last name "John*" will return all names that begin with the character string "John."
Jana presented the trouble with diacritics in the User search. For the letter ü, if the screen can't support the character it should be transcribed to ue. This doesn't happen with default user searching - the müller shows up with muller, but not with mueller. This sounds a lot like UIU-1726 (Interfile diacritic marks/letters), and session local should affect the interfiling rules.