https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29275 --- Comment #23 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Martin Renvoize from comment #18)
Sorry dude.. I love this improvement.. but I think we have a problem. The new js equivalent to patron-name.inc is awesome and works great.. but it got me looking at what patron-name.inc does and threw me into the rabbit hole looking at how patrons get hidden from other branch staff in certain modes of operation.
Good catch! And this is bigger than this dev!
I can't see any handling, either in the js function or in the API response builder, that would filter out patrons that the logged-in user should not be able to see details for. I'm hopeful that I'm just missing something in the API layer as I think that's where it should sit personally.. we shouldn't expose the data at all if the user doesn't have permission to view it, rather than hide it at the view stage. If that functionality is there, any chance you could point me to the unit tests for it?
I proposed a generic solution for checking 'allowed-to-embed' objects on bug 28523. It looks pretty solid to me and I made this bug dependent on it. For the specific case of a 'null' patron on the response (which is now the case, correctly handled in the controller level, not just hidden) I decided to handle it locally (so not in js-patron-format.inc) like this: if ( row.patron != null ) { return $patron_to_html( row.patron, { display_cardnumber: true, url: true } ); } else { return _("A patron from library %s").format(escape_str(row.library.name)); } it felt like there was no need for a generic message, as each scenario could require different wordings. Please test! -- You are receiving this mail because: You are watching all bug changes.