<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Katrin!<br>
<br>
To cut to the chase: yes, no rule at this moment. So you'd lose
what they bring you right now in term of saving time. They could be
added, easily, but doing so I would go for rules that apply some
localised calendar by default, and allows to handle things like
Easter, Memorial day, Thanksgiving and other floating holidays that
represent 2/3 of of holidays here and aren't covered with the
current rules and need editing. The fixed holidays are covered with
17015 since the days created in the future consider the week and the
year before, looking for holidays. So I do not believe this way of
handling things is a real minus versus the old one. (And we still
have some ideas to make it smarter before considering a rule
system. )<br>
<br>
As for the days in the future, and regular maintenance, I don't have
any case here where documents have a due date two years in the
future. And our UI makes it extremely easy to modify swat of days
in one click (and some input).<br>
<br>
Cheers!<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 08/01/2016 04:57 PM, Katrin Fischer
wrote:<br>
</div>
<blockquote cite="mid:60f001c4-5c84-57b4-0a39-fb81c3a044c3@web.de"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi Philippe,<br>
<br>
I still got some question marks about this idea... mostly it
doesn't feel quite right so far.<br>
</div>
<blockquote cite="mid:579606CB.9030201@inlibro.com" type="cite"> <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>
</blockquote>
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.<br>
<blockquote cite="mid:579606CB.9030201@inlibro.com" type="cite"> <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>
</blockquote>
It sounds like this type of calendar would need more regular
maintenance than the current system?<br>
<blockquote cite="mid:579606CB.9030201@inlibro.com" type="cite"> <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>
</blockquote>
<br>
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?<br>
<br>
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.<br>
<br>
Katrin<br>
<br>
<blockquote cite="mid:579606CB.9030201@inlibro.com" type="cite"> <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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:philippe.blouin@inLibro.com">philippe.blouin@inLibro.com</a> <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:philippe.blouin@inLibro.com"><mailto:philippe.blouin@inLibro.com></a>
inLibro | pour esprit libre | <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.inLibro.com">www.inLibro.com</a> <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="http://www.inLibro.com"><http://www.inLibro.com></a>
_______________________________________________
Koha-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.koha-community.org/">http://www.koha-community.org/</a>
git : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://git.koha-community.org/">http://git.koha-community.org/</a>
bugs : <a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.koha-community.org/">http://www.koha-community.org/</a>
git : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://git.koha-community.org/">http://git.koha-community.org/</a>
bugs : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://bugs.koha-community.org/">http://bugs.koha-community.org/</a>
</pre>
</blockquote>
<br>
</blockquote>
<p><br>
</p>
</blockquote>
<br>
</body>
</html>