Summary: | [Omnibus] Refactor overdue_notices.pl | ||
---|---|---|---|
Product: | Koha | Reporter: | Mark Hofstetter <koha> |
Component: | Command-line Utilities | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | dcook, koha |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16063 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Bug Depends on: | 16063 | ||
Bug Blocks: |
Description
Mark Hofstetter
2020-11-01 08:16:19 UTC
The first part is a duplicate with bug 16063 I think - You could move it there and make this bug about the second part only. I am not sure how big of a problem resending notices actually is. At least if you are using -t for triggering the notices using the overdue notice trigger set up and running the script daily. Do you have a use case where it might be an issue? just judging from my experience i'd say the concept of the triggered notice "feels fragile". You depend on the fact that script is run exactly once daily, it will mostly work, but won't if anything goes wrong. I think it all might depend a bit on how your overdues and fines process looks like. Not trying to shoot down your idea, just trying to help out here with the bug and interested in learning about others use cases. In general separate issues should go on separate bugs and descriptive bug titles are key. You can use the 'depends', 'Blocks' and 'See also' to build dependencies. You can also have an "[Omnibus]" improvements bug that serves as a central access point with the patches on separate bugs linked to it. In our use case the timing of the overdue notices is quite important, especially since they are supposed to go out on a specific schedule and the same day a fine is added if fines are used. Some careful configuration is required to achieve this. Sound like some good improvements, but I agree with Katrin. This bug should have a more descriptive title, and individual changes should be in their own bug reports. This one can be an "OMNIBUS" report if you are concerned with grouping together the different changes. I would add too that unless you're planning to make these changes, Mark, it's unlikely that anyone else is going to make them. Refactoring usually only happens if it's part of a different change. (For instance, I'm planning to refactor export.pl and its supporting libraries as part of an architectural change which needs to call the code differently.) But thumbs up for the proposed changes. Most Koha scripts would benefit from being moved into modules, so it's certainly a worthwhile idea. |