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

Mon Aug 1 22:57:32 CEST 2016

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.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/20160801/fec2508d/attachment-0001.html>