Answering briefly because it is late. Will follow-up tomorrow. But prefered to post now so you can think about it while I sleep! Take a look at the patrons or better the orders routes and the x-koha-embed header. It will take the output of an object method and try to call ->to_api recursively. If the method matches the name of a dbic relationship it will allow filtering and prefetching the related things in the query. With this mindset, what you would want to do is (probably) add methods and list them in x-koha-embed. This is the 'you need to know what you want to include' approach. But it will finally be something hardcore in the calling page... Si not big deal in my opinion. About the public part (and add an alternative to the previous paragraph), to_api is designed so we can add more params that are passed to the recursive calls. Look for the public items route bug. There, I introduce a generic way for defining the to_api_public method to be called when required. I wasn't sure about 'public' to be honest. It fits, but I feel more attached to the idea of profiles. GDPR could be yet another profile. I'd say 'what to include' should be configurable in an admin page. My two cents. El mié., 17 mar. 2021 21:28, Lari Taskula <lari.taskula@hypernova.fi> escribió:
Hi devs,
I would appreciate your feedback on a couple of issues regarding Bug 20028 that attempts to export all patron related personal data in one package. I'm having difficulties in choosing the best approach, so the help of fresh minds would be awesome.
These are my questions.
a) Code-wise, manually define what to include into the export, or automatically select all related objects with the help of DBIx relationships? 1. https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=79381&action=diff and https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20028#c11 2. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20028#c21
I have written some proof of concept patches for the second approach of fetching related data by DBIx relationships. The idea behind this was that, assuming foreign keys are appropriately defined at database level, it would always return related data without us having to worry when a new patron-related database modification gets introduced. However, then we have to be sure we are not accidentally returning some unwanted columns.
Explicitly defining what to include offers more straightforward control, but it's going to be a lot of objects (around 50, these are listed in the Bug), maintenance and the risk of data missing from the export after a database update. In terms of GDPR and good privacy practices in general it would not be nice if something was missing from the export.
b) Terminology? What to do with REST API terminology for the response object (i.e. borrower vs patron)? A patron has many, many related objects, so how do we describe those objects in a way that satisfies our terminology requirements. We could use Koha-objects to_api(), or create a new to_public_api() for the purpose of public routes, but for some objects it's currently not possible (such as messaging preferences) because they are in development. Is it even in the scope of this Bug to worry about that? If we chose the manual path of explicitly defining what to export, like what was done in the original patch (see a.1.), terminology issues could perhaps be more easily tackled.
If you have a moment, please check out the Bug, add some feedback and let me know which approach you'd prefer. Or perhaps you have even a better solution ;)
Bug 20028: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20028
-- Lari Taskula CEO, Hypernova Oy PL 16 80101 Joensuu, Finland
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/