https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43550
Bug ID: 43550
Summary: Convert misc/cronjobs/update_patrons_category.pl to
Getopt::Long::Descriptive, with --from/--to as
genuinely required options (see bug 43546)
Initiative type: ---
Sponsorship ---
status:
Product: Koha
Version: Main
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5 - low
Component: Command-line Utilities
Assignee: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected], [email protected]
Depends on: 43546
Target Milestone: ---
This is one of a set of bugs filed alongside bug 43546 (Standardize
command-line scripts on Getopt::Long::Descriptive) to convert individual,
commonly-used cron scripts to whatever declarative option-parsing convention
that bug settles on. Depends on 43546.
Current state: update_patrons_category.pl uses plain Getopt::Long (GetOptions
call around line 171). -f/--from and -t/--to (source and destination patron
category codes) are effectively mandatory: the script dies with "Categories not
found" if either fails to resolve to a real category (around line 224),
including when the option was never supplied at all -- but Getopt::Long has no
way to express that, so nothing stops the script from running with neither
supplied and proceeding through several other steps (including the
--regbefore/--regafter date-range validation around lines 205-216) before that
die is reached.
This is a direct analog of cart_to_shelf.pl's -h/--hours case described in bug
43546 -- a genuinely mandatory option currently enforced only by an ad hoc
post-parse die, well after other processing has already happened.
What this bug covers: convert to the new convention, declaring --from/-f and
--to/-t as required, so a missing category code is rejected immediately and
consistently, before any of the date-range validation logic runs.
Test plan:
- --help output covers all documented options and matches current behavior
- Omitting --from or --to now fails immediately with a clear, consistent error,
before any other validation runs
- Supplying both still behaves exactly as before, including the existing
"Categories not found" check for invalid (but present) category codes
Referenced Bugs:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546
[Bug 43546] Standardize command-line scripts on Getopt::Long::Descriptive for
safer, more consistent option handling
--
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
