This patches will improve it and are worth testing do they get pushed :-) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16829 El mié., 20 jul. 2016 13:48, Michael Hafen <michael.hafen@washk12.org> escribió:

The action_logs table in the database could hold that information if you have turned on logging in the system preferences ( http://translate.koha-community.org/manual/3.22/en/html-desktop/#logs). There is a Log Viewer in Tools that may be useful for getting information from this table, or you can try building an SQL Report by hand.

On Tue, Jul 19, 2016 at 11:45 PM, rania azad mohammed < rania.azad@auis.edu.krd> wrote:

...

Dear

We are 3 admins in the library working on shifts in the library, each of us log-in during her time. I want a report or log file to see all the activities of each admin during a specific day. is there such report or file? I tried to find it using the wiki but hopeless

--

*Regards,*

*Rania Azad |* Library Manager Library Department http://library.auis.edu.iq/ The American University of Iraq, Sulaimani Office: *B-G-32* Ext *1219*

_______________________________________________ Koha-devel mailing list Koha-devel@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/

-- Michael Hafen Washington County School District Technology Department Systems Analyst

_______________________________________________ Koha-devel mailing list Koha-devel@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/

-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

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@inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

I'm all for speed improvements. But: - A clear backwards-compatible upgrade path needs to be set and written. Our curent script takes the content of the "old" tables to create the new one. Past and future. Is that what you mean? More so, I've split the work in 8 theoretical steps. But I think it could be considered to offer both ways in parallel: just add the new DB

On 07/21/2016 02:23 PM, Tomas Cohen Arazi wrote: table, slowly transfer the calls to the new library. Just make sure the new table is populated on any call to modify the "old ones".

- I think (because of the speed improvement) that you are realying more on the DB features, this needs to be discussed if it can cause trouble. Actually, that's the serious point: we're going simple SELECTs the old way. With no cache or anything right now. It's not the fact that the code is cut by 80% or anything (although it would be). It's just that much faster to do date calculations using the DB than Perl's DateTime. Something like...

- The less you change the API, the easier is to spot regressions for the current blacklist-like implementation of the calendar. Tests could be adjusted, but it'd be interesting to have the current tests pass. I agree. I admit I do not have a clear plan, and I know without perfect test coverage, this stands no chance. More so, wasting perfectly valid

SELECT COUNT(*) FROM discrete_calendar WHERE (date BETWEEN ? AND ?) AND (isopen=1) Add in opening and closing hours and it's golden. Easily hashable and cachable as well. old tests is... a waste. But again, I'm throwing a line. I want to see if others beside us see a need. I want to see if someone is already working on something that would conflict, etc...

Regards

Thanks a lot for the feedback!

El jue., 21 jul. 2016 a las 13:43, Philippe Blouin (<philippe.blouin@inlibro.com <mailto:philippe.blouin@inlibro.com>>) escribió:

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 <http://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@inLibro.com <mailto:philippe.blouin@inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@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/

-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

I think this sounds great! The one suggestion I would make is to try to break this down into as many discretely testable bug reports a possible. The smaller each testable unit is, the more easily tested and qa'd it is. Kyle <https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB> http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Thu, Jul 21, 2016 at 3:30 PM, Philippe Blouin < philippe.blouin@inlibro.com> wrote:

On 07/21/2016 02:23 PM, Tomas Cohen Arazi wrote:

I'm all for speed improvements. But: - A clear backwards-compatible upgrade path needs to be set and written.

Our curent script takes the content of the "old" tables to create the new one. Past and future. Is that what you mean? More so, I've split the work in 8 theoretical steps. But I think it could be considered to offer both ways in parallel: just add the new DB table, slowly transfer the calls to the new library. Just make sure the new table is populated on any call to modify the "old ones".

- I think (because of the speed improvement) that you are realying more on the DB features, this needs to be discussed if it can cause trouble.

Actually, that's the serious point: we're going simple SELECTs the old way. With no cache or anything right now. It's not the fact that the code is cut by 80% or anything (although it would be). It's just that much faster to do date calculations using the DB than Perl's DateTime. Something like...

SELECT COUNT(*) FROM discrete_calendar WHERE (date BETWEEN ? AND ?) AND (isopen=1)

Add in opening and closing hours and it's golden. Easily hashable and cachable as well.

- The less you change the API, the easier is to spot regressions for the current blacklist-like implementation of the calendar. Tests could be adjusted, but it'd be interesting to have the current tests pass.

I agree. I admit I do not have a clear plan, and I know without perfect test coverage, this stands no chance. More so, wasting perfectly valid old tests is... a waste.

But again, I'm throwing a line. I want to see if others beside us see a need. I want to see if someone is already working on something that would conflict, etc...

Regards

Thanks a lot for the feedback!

El jue., 21 jul. 2016 a las 13:43, Philippe Blouin (< philippe.blouin@inlibro.com>) escribió:

...

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@inLibro.com inLibro | pour esprit libre | www.inLibro.com

_______________________________________________ Koha-devel mailing list Koha-devel@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/

-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

_______________________________________________ Koha-devel mailing list Koha-devel@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/

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@inLibro.com <mailto:philippe.blouin@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@inLibro.com <mailto:philippe.blouin@inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

_______________________________________________ Koha-devel mailing list Koha-devel@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@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/

Hi Katrin! 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. ) 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). Cheers! Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> On 08/01/2016 04:57 PM, Katrin Fischer wrote:

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@inLibro.com <mailto:philippe.blouin@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@inLibro.com <mailto:philippe.blouin@inLibro.com>

inLibro | pour esprit libre |www.inLibro.com <http://www.inLibro.com>

_______________________________________________ Koha-devel mailing list Koha-devel@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@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/