[Koha-bugs] [Bug 29275] Use the API to render checkout history for a biblio

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29275

--- Comment #23 from Tomás Cohen Arazi <tomascohen at 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.