On Mon, Aug 4, 2008 at 4:58 AM, Henri-Damien LAURENT < [EMAIL PROTECTED]> wrote:
> Ryan Higgins a écrit : > >> Previously subscription-add.pl allowed modification of 'firstacquidate', >> which changed >> the subscription definition, but did not affect prediction. This patch >> adds two fuctions >> to Serials.pm to get/set the current expected issue date (note that all >> date calculations >> in prediction patterns are based on the current expected date, and there's >> only one serial >> issue per subscription in the 'expected' status at any time). >> Subscription editing >> now allows you to edit the next expected date, but not the first acqui >> date (unless you >> haven't received any issues yet), thus allowing for adjustments in the >> prediction pattern. >> This patch also updates fixes some discrepancies in irregularities / >> prediction display. >> >> > Ryan, > you did good job with those patches : > I like the way you can select irregularities (with dates proposed, this was > what I wanted to propose ( with eventually a feature that would create all > the expected issues at once (this would be of great help for dead > subscriptions cataloguing) )). Yes, this feature is *very* high on my list, too, and should be pretty easy to implement. > > However, some behaviours are still questioning. > - one cannot see the irregularities when editing a subscription : you have > to reset Predicition pattern for test Prediction Pattern to be re-enabled. > Is this what you/we intend ? No, this is not intended. I just applied these patches to a clean branch, and I see this error now. It must have crept in while rebasing the commits. I'll submit another patch to correct this in a couple hours. - When updating the arrival date of the first expected issue, firstacquidate > is not updated. Is this what we want ? No, if we have not yet received any issues, then it should be modified. Again, a fix that was lost on rebase. I will correct this as well. - when duplicating a subscription, irregularities information is not > duplicated. Is this intended ? Imho, an irregularities hidden input could > store all the irregularities selected the way irregularities stores them and > this would be duplicated when subscription duplicated. I did not address this in these patches. I agree that that should be the expected behavior, but do not expect that I will have time to add this. - There is little control on the number of irregularities entered. I am OK > with that (It is not critical). > I agree. It would be nice to keep a count of how many irregularities Koha expects the user to enter. That would be a nice enhancement. Thanks for testing these patches so quickly, and catching the above errors. I will submit a couple patches to address those errors later today. Cheers, -- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704
_______________________________________________ Koha-patches mailing list [email protected] http://lists.koha.org/mailman/listinfo/koha-patches
