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.
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/