Bug 26332

Summary: Koha::Account::pay incorrectly defaults to '0' for manager_id
Product: Koha Reporter: Martin Renvoize <martin.renvoize>
Component: Fines and feesAssignee: Martin Renvoize <martin.renvoize>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: joonas.kylmala
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26271
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 22008    
Bug Blocks: 14825    
Attachments: Bug 26332: Remove hard coded '0' for manager_id

Description Martin Renvoize 2020-09-01 08:17:35 UTC
Since bug 22008 we have a foreign key constraint for manager_id against the borrowers table; However, we neglected to update the 'pay' routing in Koha::Account to reflect this non-required field and left it to default to '0' which may not be a borrower at all.

We should allow 'undef' to be passed into 'pay' unaltered when the interface is anything other than 'staff'.. as it may reflect a SIP or OPAC payment where no staff member is required to be present.
Comment 1 Martin Renvoize 2020-09-01 08:29:06 UTC
Hmm.. 

The data in question is coming from the userenv.. so in theory should always be set and not require a fallback at all.

I think this perhaps highlights an issue in some plugin code not setting userenv properly in my case.. but I still feel we should not be defaulting back to '0' and exploding..
Comment 2 Martin Renvoize 2020-09-01 13:25:26 UTC
Created attachment 109430 [details] [review]
Bug 26332: Remove hard coded '0' for manager_id

This patch removes the fallback to '0' for the manager_id in
Koha::Account::pay. This will only affect plugins that contain a
background callback that doesn't set the user environment.
Comment 3 Martin Renvoize 2020-09-27 06:40:41 UTC

*** This bug has been marked as a duplicate of bug 25606 ***
Comment 4 Martin Renvoize 2020-09-28 19:47:29 UTC

*** This bug has been marked as a duplicate of bug 26506 ***