https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17015 --- Comment #50 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- (In reply to Blou from comment #49)
I admit not understanding exactly your need, but I liked the use of "interact in interesting ways". I mean there are different types of opening hours in a library. Different services are available on different hours.
One thing I'd bet on is that this new calendar would make it much easier for you to stack on extra constraints. What I am concerned is the choice of GUI technologies, if they allow easily to set different types of opening hours in the calendar and can visualize those to the user. I was dabbling with https://fullcalendar.io/ on our overduenotices rewrite. It is pretty cool.
But adding an extra column to the "discrete_calendar" table to represent a combo (branch, checkouttype) would be easy. Not in this patch, though :) Adding a new column was what I was thinking of. Should be rather simple. We can provide a followup when we start working on that.
Also popped into my head. You should add a REST API endpoint for CRUD:ing the calendar entries. Then write the GUI on top of the REST API. This way you have architecturally solid separation of backend-logic from front-end logic. And can make some super snappy UIs using AJAX. Also we can write our own GUI to interface with the discrete_calendar if we want. Our pretty much anybody can do it on top a of a well defined API. ...but maybe not in this rewrite. Up to you how you want to upgrade your workflow. Atomicupdate: installer/data/mysql/atomicupdate/generate_discrete_calendar.perl Not sure what is the community recommendation for naming conventions here. I find it polite to include the ticket number there, eg: installer/data/mysql/atomicupdate/Bug-17015-generate_discrete_calendar.perl tests++ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.