[Koha-bugs] [Bug 2720] Overdues which debar automatically should undebar automatically when returned

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720

--- Comment #24 from Kyle M Hall <kyle at bywatersolutions.com> ---
(In reply to Owen Leonard from comment #15)
> - There is a typo in updatedatabase, a reversed end parenthesis.
Fixed!

> - There is at least once instance of "debar" being used instead of
> "restrict" 
Fixed!

> - I think the "X" icon isn't appropriate here. It would be simpler and more
>   clear to use text ("Remove").
Fixed!

> - The table of restrictions doesn't look correct if there are no
>   restrictions--probably because there is nothing in <tbody>? Anyway
>   I think it would be more consistent to separate the entry from from
>   the table. Wrapping <form> around <tfoot> is invalid.
> - onclick="return confirm(_('Remove debarment?'))" at line 24 of 
>   borrower_debarments.inc is not translatable. The action should be moved
>   to a function.
Fixed!

> - borrower_debarments.inc has a couple of unescaped ampersands in line 24.
Fixed!

> I don't think the "Restrictions" tab should be present on circulation.pl at
> all times. Being able to add a restriction to an account is certainly not
> something which happens so frequently that it needs to be only one click
> away. 
That is correct, it's there for removing restrictions primarily. However, I see
no strong reason *not* to allow the ability to restrict a patron from here.

> It's useful to be able to see information about all restrictions, but the
> full information could just as easily be displayed in the main block of
> "Cannot check out!" messages at the top. There's no reason to conserve space
> there if the patron is restricted anyway. If we mimicked the current method
> for displaying restrictions we could simply make it possible to display more
> than one line of restrictions, each with the same "lift restriction" button
> or link.
As you write, it's useful, and this area appears to be more a matter of
aesthetic preference. If you really dislike it, please submit a followup!

> If we did this then we could move the form for adding a manual restriction
> either back into the patron edit form (where people still expect to find it)
> or onto its own page (not as good an option IMO).
This latest edition of the patch adds the restrictions back to the patron
editor to address this.

> One idea for an improvement: Perhaps the overdue notices job could set a
> restricted comment with the datetime of the job? "Restriction added by
> overdues process 2013-03-05 00:20:00"
Done!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are watching all bug changes.