[Koha-devel] Pre-RFC on new discrete calendar

[Philippe Blouin]

Good afternoon Katrin!

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.

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.

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.

THEN we get to the performance benefits I'm striving for....

Right now, my first step would be to create a patch that creates the new 
table and modify the Koha/C4 Calendar modules to seed the new one with 
any modification of the old ones.  So no impact on current behavior.  
Then second step would be to create the new UI, without touching the old 
one.  THEN next step would be to transfer the functionnality usages.  
Basically in reverse order of what I have available right now.  :-)

Philippe Blouin,
Responsable du développement informatique

Tél.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at 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.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
>>
>> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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 at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160725/ba2cd8f0/attachment.html>