Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Description: Clicking a filter or entering a search via the "Patron lookup" link shows a blank pane.
Details: Same as the find-user plugin for managing proxies, the table-header values instead of the keys are being passed through to the MCL. Before i18n was implemented, this was fine as values could be used for keys, but since the values will change when translated this is no longer the case and the keys must be used instead.
Theodor Tolstoy (One-Group.se) April 5, 2018 at 12:07 PM
Looks fine to me!
Zak Burke April 3, 2018 at 6:27 PM
They're related. The issue here is that the data we're passing to the plugin has columns like name, patronGroup, and username, but the table-headers we were trying to match it against had names like Name, Patron group, and Username.
The ui-requests regression test fails for the same reason but with a different set of components. That'll be handled by STCOM-246.
Niels Erik Nielsen April 3, 2018 at 11:28 AM
The ui-requests regression test fails, seemingly due to no user barcode found when looking up a requestor; could that be related to this issue?
Description: Clicking a filter or entering a search via the "Patron lookup" link shows a blank pane.
Details: Same as the find-user plugin for managing proxies, the table-header values instead of the keys are being passed through to the MCL. Before i18n was implemented, this was fine as values could be used for keys, but since the values will change when translated this is no longer the case and the keys must be used instead.