Hi Philippe, I still got some question marks about this idea... mostly it doesn't feel quite right so far. > > Let's start with the backend: this is just a simple script that fills > the calendar ahead of time (waaay ahead of time) to allow the user to > modify schedules easily. 1 year is just a hardcoded value, it could > as well be an argument allowing any number of days in the future. > Same for the past: during updatedatabase, this creates one but could > create two years in the past based on the info in the current calendar > tables. In the end, the point is to have a table entry for each day, > specifying which day it WAS opened (for hourly fine calculation) and > which day it will be opened (for hourly checkout or just for > displaying the library open hours on the OPAC). Going a year in the > future, things are a bit dumb when creating, but always replicate the > week before, except for items with notes (holiday) that are fetched on > the calendar year a year before. Then the librarian has plenty of > time to adjust anything. I think depending on the notes is not a good idea. You can add notes to every kind of holiday at the moment - so you'd have to take a look at the type of holiday - repeated yearly/weekly and unique. You'd also need to take into account the exceptions to repeated holidays that you can currently define. > > Which brings us to the UI. Mine is ugly, but it would be easy to > create a nice one AND SIMPLE one (coding) and powerful one (for > users). With that simple backend, it's very easy to simply allow > multiple selections in the calendar widget, the modify opening hours, > or holiday close with a note. Or better: select a week anywhere in > the calendar, then copy that to a given range. 3 days, a month, 3 > months... Very simple in the UI, very few clicks. Very simple to > code in the backend. It sounds like this type of calendar would need more regular maintenance than the current system? > > So in the end, recovering the original work or Kyle's work or defining > new standard, we have a calendar page with a simple calendar and below > it a few edit box (opening hours, closing, notes, closed checkbox) and > a apply button. On the right, like right now, we can display all > "special dates", which are the ones with a "note" entry. In yellow > those that are on days still opened, in pink those days that are > marked as closed. Of course, all UI schemes are very open to > suggestion. But it would be simple and naturally intuitive.
If I was to make a change to the calendar - would I have to wait for the cronjob/script to run and update the table or would it take effect immediately? What will happen if a due date or other date is outside of the calendar? I feel like by relying on a fixed date range, we are going to create problems along the road if there is no rule based system as a backup at least. Katrin > > Philippe Blouin, > Responsable du développement informatique > > Tél. : (888) 604-2627 > philippe.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com> > > inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> > On 07/24/2016 04:42 PM, Katrin Fischer wrote: >> Hi Philippe, >> >> thx for trying to get things moving again - I know there are quite a lot >> calendar related bugs to be found in bugzilla. >> >> Can you explain a bit about how this would change the GUI for the users? >> Do you have to keep it up to date or does the table get filled >> automatically for recurring events? >> >> I am a bit concerned about the limitation of one year into the past and >> one year into the future. What happens if a due date goes beyond that or >> an item is overdue before that? >> >> Katrin >> >> Am 21.07.2016 um 18:43 schrieb Philippe Blouin: >>> Hi! >>> >>> I'm throwing a line here, and I'd just like to get a feel for the value >>> of offering some work to the community. Mind you, the work is "big" so >>> honest responses could save us lot of wasted hours. >>> >>> We've developed a parallel calendar table to specify each individual day >>> if it's opened or not (instead of rules and exception). We added to it >>> the opening hours, and keep a year of them in the past, and a year in >>> the future. >>> The reasonning being: >>> - We need the opening hours. They need to vary season to seasons. We >>> need them for hourly and minute loans. >>> - Exception and holidays and etc... are complicated. To manage, to >>> calculate, to fix. We need the past info as well, to calculate precisely. >>> - Performance. Calculating with C4/Koha Calendars is sloooooooooow. >>> Our little table cut fines.pl calculation times by 97%. Not a typo. >>> Checkout improvement by 30-60% but metric is unreliable so take with >>> grain of salt this one. >>> >>> So before I go and write a wiki RFC, then open bugzillas, make the code >>> community acceptable (we're not using Schemas), complete it, write >>> tests, etc... Is there an interest? Would it answer a need (outside of >>> our clients) ? Maybe a subset? >>> >>> All comments, suggestions, questions are welcomed. >>> >>> High regards, >>> >>> Philippe Blouin, >>> Responsable du développement informatique >>> >>> Tél. : (888) 604-2627 >>> philippe.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com> >>> >>> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> >>> >>> >>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel@lists.koha-community.org >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >>> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel@lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
