https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27358 --- Comment #25 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- (In reply to Tomás Cohen Arazi from comment #24)
(In reply to Katrin Fischer from comment #17)
I am a little worried about the short list here:
+sub api_privileged_attrs { + return [ + 'checked_out_date', + 'checkouts_count', + 'holds_count', + 'internal_notes', + 'extended_subfields', + ]; +} +
Can you help me? Just wondering if it also uses the framework visibility, then I'd be happy already :)
If we leave more_subfields_xml/frameworks out of the item representation (we have plans for that), would y'all help me refine this deny-list for the items?
I still think we should switch from 'deny-list' to 'allow-list'.. security by default ;)
I have just rebased this work and it still works nicely. If I don't get feedback in a few days, I will move the 'public' layer work to another (simpler) table, so other devs see the benefit from this and can work on top of it.
Hmm, I don't think it would be a bad idea to move the core idea to another, simpler, endpoint/table so other work can be based upon it.
My feeling is we can have a list of 'hidden in opac' attributes from the 'items' table, and then we can sort visibility in the views. I might be wrong, though. Looking for feedback.
Hmm, not sure I understand this one.. do you mean expose fields in the API and only use the 'hidden in opac' options for the final display.. I can see a use case for that.. but I can also see people complaining that some hidden fields are still publically available if you know how to use the API.
Please PM me if you feel like there's a good use case that could be simpler than this (I'm thinking accountlines).
Accountlines could work.. though I still have a way to go regarding the api's there. Questions like '/credits vs /debits vs /lines' and how embeds should work for offsets and things. -- You are receiving this mail because: You are watching all bug changes.