Bug 25063 - [OMNIBUS] OPAC Renewal Option
Summary: [OMNIBUS] OPAC Renewal Option
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 26354 26355 26357
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-04 16:11 UTC by Christopher Brannon
Modified: 2023-06-22 18:43 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2020-04-04 16:11:06 UTC
I am seeing a strange thing with patron modification requests.  I see requests come through asking for modification, but nothing has been changed.  Looking closer at the accounts, I see that the accounts are up for renewal.

I am thinking that people are checking their information and confirming that their information is up to date.

I would like to propose two modifications to the modification requests.

First, I think there should be an preference to not be able to submit a request unless information has been changed.

Second, perhaps a preference tied in with the first suggestion, that allows the patron to select a check-box stating that they have reviewed all their information, and it is accurate and up to date.  Perhaps this option only shows when their account is due for renewal.  And perhaps the renewal reminder would include a link to the modification page, asking them to review their information and make any any necessary updates if necessary, but acknowledging that the information is up to date.

I suggest this being an option, because some libraries might require fees or a view of a current ID before renewing.

Third, even if all the patron is doing is renewing, we could have a preference set to notify or not in the modification requests of the acknowledgement and renewal.

Fourth, if there are other steps necessary, like a patron category that requires a fee (that isn't automatically charged on renewal) or ID shown, another preference would give admin the ability to have the account self renew.  If all they have done is checked the acknowledge box and submitted, the account renews.  This option is tricky, since a person could do this, then go back and make changes.  But, those changes, would of course, have to be reviewed.
Comment 1 Owen Leonard 2020-04-17 15:46:46 UTC
A bug report with four distinct enhancement proposals should be four bug reports, each with a specific and explanatory title.
Comment 2 Katrin Fischer 2020-04-18 02:30:18 UTC
(In reply to Owen Leonard from comment #1)
> A bug report with four distinct enhancement proposals should be four bug
> reports, each with a specific and explanatory title.

+1
Comment 3 Christopher Brannon 2020-06-26 17:37:57 UTC
Okay, first off, this is an idea of a new feature.  While I list three or four specific changes, that all center around the concept of this feature.  I COULD file each separately, but then the concept of patron renewal would be obscured.  If you still think this should be 3 or 4 individual enhancements, I can do that.  But I'm not sure why that is being imposed here when other features are added that change several elements.  Would just like to understand the difference so I can be consistent.
Comment 4 Owen Leonard 2020-06-26 18:47:25 UTC
If the enhancement you describe should be implemented all in one go, then one bug report is fine. The way you worded the description made it sound like there were different aspects which could be implemented separately.

Although no enhancement request is guaranteed to be taken up by volunteers, it does increase the likelihood that a volunteer will tackle an enhancement request if it can be broken down into its smallest usable component. The "depends on" and "blocks" fields can be used to link bugs together if one can't be implemented without another.
Comment 5 Christopher Brannon 2020-09-02 15:10:40 UTC
I've broken this down into separate bugs.  Look at see also.
Comment 6 Marcel de Rooy 2022-04-21 11:08:13 UTC
(In reply to Christopher Brannon from comment #5)
> I've broken this down into separate bugs.  Look at see also.

It is not completely clear to me what you did. Does this report only stay as the omnibus report, or is development here needed too? You could use the dependencies to indicate that.

Also note that OPAC Renewal lets me think first of renewing loans, not patron accounts.
Comment 7 Katrin Fischer 2022-06-25 16:14:21 UTC
I feel like there was no bug filed for the fourth option, correct? Have still reformatted to make things a little clearer.