[Koha-bugs] [Bug 17424] New: REST API: Preference to control access to own objects without permission

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

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

            Bug ID: 17424
           Summary: REST API: Preference to control access to own objects
                    without permission
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: Web services
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: lari.taskula at jns.fi
        QA Contact: testopia at bugs.koha-community.org

Introduce a preference to enable/disable access to own objects for patron's
without required permissions.

Bug 14868 added "allow-owner" parameter that allows owner of the object to
perform operations on themselves even if they do not have required permissions
to otherwise do so (e.g. get own patron data or renew your own checkouts even
if you don't have borrowers/circulating permissions). This means patrons can
perform basic OPAC operations via REST API.

However, there should be an option to disable this functionality; as Katrin
pointed out in
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13895#c43 ,

> I can imagine both happening:
> - libraries wanting to shut down any OPAC account functionality, but still
> be able to renew in staff, so the circulation conditions are set up this
> way. In this case, there should be a way to lock the API (opacuserlogin
> might be a way)
> - libraries shutting down the OPAC, because they use something else like an
> external discovery layer. In this case they'd still want to use the API, but
> might turn off the OPAC as far as possible.

I propose a system preference for enabling/disabling access to own objects in
REST API. This way libraries can disable opacuserlogin and any OPAC API
functionality with the new preference. In the second case, libraries can
disable opacuserlogin but still allow OPAC functionality via REST API.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.