<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Good afternoon Katrin!<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
THEN we get to the performance benefits I'm striving for....<br>
<br>
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. :-)<br>
<br>
<div class="moz-signature">
<style type="text/css">
.moz-signature {
color: #FFFFFF;
}
.sig_inlibro {
padding-top : 2px;
color: #888888;
font-family : "Trebuchet MS", verdana;
font-size: 90%;
}
.sig_content {
border-top: 2px solid #DDDDDD;
border-bottom: 2px solid #BFD13D;
background-color : #F6F6F6;
padding-left:10px;
}
.sig_inlibro a:visited, .sig_inlibro a:hover, .sig_inlibro a:link {
text-decoration: none;
color: #005B85;
}
.nom {
color: #005B85;
font-weight : bold;
}
.inlibro, .in {
color: #BFD13D;
}
.libro {
color: #005B85;
}
.in, .libro {
font-size : 120%;
}
.desc {
margin-bottom: 0;
padding-bottom: 5px;
}
.small {
font-size: 80%;
}
.tagline {
color : #00BCE4;
}
.sig_footer {
padding-left : 10px;
background-color : #EEEFEA;
}
</style>
<div class="sig_inlibro">
<div class="sig_content"> <span class="nom">Philippe Blouin,</span><br>
<span class="tagline small">Responsable du développement
informatique</span><br>
<p class="desc small"> Tél. : (888) 604-2627<br>
<a href="mailto:philippe.blouin@inLibro.com">philippe.blouin@inLibro.com</a>
</p>
</div>
<div class="sig_footer"> <span class="in">in</span><span
class="libro">Libro</span> <span class="tagline small">|
pour esprit libre |</span> <a class="small"
href="http://www.inLibro.com">www.inLibro.com</a> </div>
</div>
</div>
<div class="moz-cite-prefix">On 07/24/2016 04:42 PM, Katrin Fischer
wrote:<br>
</div>
<blockquote cite="mid:ceca073c-4797-9b73-2aa6-69b1784318c0@web.de"
type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:philippe.blouin@inLibro.com">philippe.blouin@inLibro.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:philippe.blouin@inLibro.com"><mailto:philippe.blouin@inLibro.com></a>
inLibro | pour esprit libre | <a class="moz-txt-link-abbreviated" href="http://www.inLibro.com">www.inLibro.com</a> <a class="moz-txt-link-rfc2396E" href="http://www.inLibro.com"><http://www.inLibro.com></a>
_______________________________________________
Koha-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a>
<a class="moz-txt-link-freetext" href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a>
website : <a class="moz-txt-link-freetext" href="http://www.koha-community.org/">http://www.koha-community.org/</a>
git : <a class="moz-txt-link-freetext" href="http://git.koha-community.org/">http://git.koha-community.org/</a>
bugs : <a class="moz-txt-link-freetext" href="http://bugs.koha-community.org/">http://bugs.koha-community.org/</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Koha-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a>
<a class="moz-txt-link-freetext" href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a>
website : <a class="moz-txt-link-freetext" href="http://www.koha-community.org/">http://www.koha-community.org/</a>
git : <a class="moz-txt-link-freetext" href="http://git.koha-community.org/">http://git.koha-community.org/</a>
bugs : <a class="moz-txt-link-freetext" href="http://bugs.koha-community.org/">http://bugs.koha-community.org/</a>
</pre>
</blockquote>
<br>
</body>
</html>