Bug 37815

Summary: Protected flag permissions should be honoured in the REST API
Product: Koha Reporter: Jake Deery <jake.deery>
Component: PatronsAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: carthur, dcook, gmcharlt, kyle, rcoert
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 36085    
Bug Blocks:    

Description Jake Deery 2024-09-03 08:27:33 UTC
(follow-up from bug 36085)

We now restrict access to the protected flag in the GUI. This should also be replicated out to the REST API.
Comment 1 David Cook 2025-08-21 23:52:29 UTC
This is a good reminder that we need to do more in modules and less in Perl scripts.
Comment 2 David Cook 2025-08-22 00:08:44 UTC
(In reply to David Cook from comment #1)
> This is a good reminder that we need to do more in modules and less in Perl
> scripts.

Looking again at members/memberentry.pl, this is how we create a patron:

Koha::Patron->new( \%newdata )->store( { guarantors => \@guarantors } );

I keep coming up with designs and then forgetting them because of other priorities, but something like...

try {
  Koha::Patron->create({
    user => $user,
    data => $newdata,
    guarantors => $guarantors,
  });
} catch {
  #blah blah blah
}

Maybe even a "policy" attribute if we want to compute things like system preferences in advance for better performance on bulk changes.

Or maybe we update the "new" constructor to take a user object. 

In theory, the controller should just be managing input/output. 

--

But... that's easy for me to say. Doing that kind of refactoring is a huge pain so we let inertia keep us going with the status quo...

Maybe there's some kind of transitional middleground we just haven't thought of yet. I know there's other bugs for doing data validation. It's something that needs to happen at some point, but we'll need a good design and some agreement. I think the scariest bit is actually the perceived effort in doing UI work for the exception handling...

I'm actually doing some local work on restrictions. Maybe I'll have a think about a lightweight way to start doing this which can be gently applied... hmmm...

Anyway, I'll get off my soapbox heh.