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.
A bug report with four distinct enhancement proposals should be four bug reports, each with a specific and explanatory title.
(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
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.
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.
I've broken this down into separate bugs. Look at see also.
(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.
I feel like there was no bug filed for the fourth option, correct? Have still reformatted to make things a little clearer.