Discussion for Bug 14757 - Allow the use of Template Toolkit syntax for slips and notices
I would like to start the discussion Marcel wanted to have at the dev meeting. Right now, we have one bespoke syntax for slips and notices with all kinds of caveats and limitations. My first instinct was that we should over time tear out this old syntax and replace it with TT. However, there are some issues: 1) TT is a bit more complicated ( and more powerful of course ) than our custom syntax 2) We have an editor for our current syntax ( though it is somewhat problematic to use at times, as not all fields in the editor are actually available on the notices where they display ) 3) Creating an editor for TT would be somewhat non-trivial if we were to replace what we have with a better and more advanced way of dealing with data passed to the slip or notice. I'm wondering if we should, at least for the time being, consider the existing notice syntax as the "basic" mode for slips and notices, and have the ability for TT in notices and slips be an 'advanced' mode. Basically, that means that nothing will change for librarians. The current syntax and editor will continue to be what they are. Instead, 'advanced' users can simply start using TT in their notices and slips. What we will do is document how to use TT in slips and notices in the manual. So, what I would do at this point is deprecate my replacement notices ( keeping the new methods where necessary for the advanced mode ), and create some good documentation. That way we get the power of TT while retaining backwards compatibility! What does everyone think? Kyle 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 )
Hello Kyle and others, I really like the idea :) I don't see major issues, and the lack of editor is a wrong issue (what kind of editor do you want??) The main point is that it will be much more powerful that our current homemade syntax parser. I have already used this enhancement on bug 15705: without the TT syntax, I would never managed to answer the need (display a specific error on notifying the user, depending on what was wrong). IMO there are 3 steps to implement: 1/ Update existing notices to match our current TT syntax: [% var %] OR (and maybe better) set START_TAG and END_TAG to '<<' and '>>' and we have nothing to do here :) 2/ Take care of some specific variables we currently support: LibrarianFirstname, LibrarianSurname, LibrarianEmailaddress, count, today, ... 3/ Support of "repeatable": at the moment we cannot loop on elements with [% FOREACH %], it's a shame and frustrating Note that we already support the TT syntax in the CSV profiles (bug 12404). The main question is: could we add TT directive in newly created notices (see bug 15705 again)? I would answer yes: it will add examples and people will notice that something has changed. With a good help and good examples, it should not be too hard to understand what does the code. Cheers, Jonathan 2016-02-02 17:52 GMT+00:00 Kyle Hall <kyle.m.hall@gmail.com>:
I would like to start the discussion Marcel wanted to have at the dev meeting.
Right now, we have one bespoke syntax for slips and notices with all kinds of caveats and limitations.
My first instinct was that we should over time tear out this old syntax and replace it with TT. However, there are some issues:
1) TT is a bit more complicated ( and more powerful of course ) than our custom syntax 2) We have an editor for our current syntax ( though it is somewhat problematic to use at times, as not all fields in the editor are actually available on the notices where they display ) 3) Creating an editor for TT would be somewhat non-trivial if we were to replace what we have with a better and more advanced way of dealing with data passed to the slip or notice.
I'm wondering if we should, at least for the time being, consider the existing notice syntax as the "basic" mode for slips and notices, and have the ability for TT in notices and slips be an 'advanced' mode.
Basically, that means that nothing will change for librarians. The current syntax and editor will continue to be what they are. Instead, 'advanced' users can simply start using TT in their notices and slips. What we will do is document how to use TT in slips and notices in the manual.
So, what I would do at this point is deprecate my replacement notices ( keeping the new methods where necessary for the advanced mode ), and create some good documentation. That way we get the power of TT while retaining backwards compatibility!
What does everyone think? Kyle
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 )
_______________________________________________ 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/
Going from our own syntax to a more general format is good. If we along that way, improve Letters.pm, that is fine too ! For developers it is great that is more powerful but that is probably the pitfall too. I think we should make sure that we can (automatically) convert old notices to the new format. And perhaps harder: How do we guarantee that we do not loose the ability for librarians to add or edit notices? If you need "an expert" to do so, we went too far.. ________________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Jonathan Druart [jonathan.druart@bugs.koha-community.org] Verzonden: woensdag 3 februari 2016 11:23 Aan: Koha Devel Onderwerp: Re: [Koha-devel] Discussion for Bug 14757 - Allow the use of Template Toolkit syntax for slips and notices Hello Kyle and others, I really like the idea :) I don't see major issues, and the lack of editor is a wrong issue (what kind of editor do you want??) The main point is that it will be much more powerful that our current homemade syntax parser. I have already used this enhancement on bug 15705: without the TT syntax, I would never managed to answer the need (display a specific error on notifying the user, depending on what was wrong). IMO there are 3 steps to implement: 1/ Update existing notices to match our current TT syntax: [% var %] OR (and maybe better) set START_TAG and END_TAG to '<<' and '>>' and we have nothing to do here :) 2/ Take care of some specific variables we currently support: LibrarianFirstname, LibrarianSurname, LibrarianEmailaddress, count, today, ... 3/ Support of "repeatable": at the moment we cannot loop on elements with [% FOREACH %], it's a shame and frustrating Note that we already support the TT syntax in the CSV profiles (bug 12404). The main question is: could we add TT directive in newly created notices (see bug 15705 again)? I would answer yes: it will add examples and people will notice that something has changed. With a good help and good examples, it should not be too hard to understand what does the code. Cheers, Jonathan 2016-02-02 17:52 GMT+00:00 Kyle Hall <kyle.m.hall@gmail.com>:
I would like to start the discussion Marcel wanted to have at the dev meeting.
Right now, we have one bespoke syntax for slips and notices with all kinds of caveats and limitations.
My first instinct was that we should over time tear out this old syntax and replace it with TT. However, there are some issues:
1) TT is a bit more complicated ( and more powerful of course ) than our custom syntax 2) We have an editor for our current syntax ( though it is somewhat problematic to use at times, as not all fields in the editor are actually available on the notices where they display ) 3) Creating an editor for TT would be somewhat non-trivial if we were to replace what we have with a better and more advanced way of dealing with data passed to the slip or notice.
I'm wondering if we should, at least for the time being, consider the existing notice syntax as the "basic" mode for slips and notices, and have the ability for TT in notices and slips be an 'advanced' mode.
Basically, that means that nothing will change for librarians. The current syntax and editor will continue to be what they are. Instead, 'advanced' users can simply start using TT in their notices and slips. What we will do is document how to use TT in slips and notices in the manual.
So, what I would do at this point is deprecate my replacement notices ( keeping the new methods where necessary for the advanced mode ), and create some good documentation. That way we get the power of TT while retaining backwards compatibility!
What does everyone think? Kyle
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 )
_______________________________________________ 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, On Wed, Feb 3, 2016 at 7:18 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
And perhaps harder: How do we guarantee that we do not loose the ability for librarians to add or edit notices? If you need "an expert" to do so, we went too far..
As a data point, part of Evergreen's infrastructure for generating certain kinds of notices uses Template::Toolkit templates. I can't say whether or not that's a big barrier, but I do know that at least some librarians have managed to edit their notices without requiring much assistance. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
I think Jonathan has an excellent plan of attack, but it does require a complete switchover all at once. I would propose we continue to use the default TT tags so that we can push this code to master while working on ensuring all notices work with the new TT syntax. After that, we can throw the switch by converting "<<" and ">>" to "[% " and " %]" respectively. One of the main reasons to keep the default tags is so that librarians can refer to TT documentation and examples with less confusion and thought. Kyle 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 ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Feb 3, 2016 at 5:23 AM, Jonathan Druart < jonathan.druart@bugs.koha-community.org> wrote:
Hello Kyle and others,
I really like the idea :) I don't see major issues, and the lack of editor is a wrong issue (what kind of editor do you want??) The main point is that it will be much more powerful that our current homemade syntax parser. I have already used this enhancement on bug 15705: without the TT syntax, I would never managed to answer the need (display a specific error on notifying the user, depending on what was wrong).
IMO there are 3 steps to implement: 1/ Update existing notices to match our current TT syntax: [% var %] OR (and maybe better) set START_TAG and END_TAG to '<<' and '>>' and we have nothing to do here :) 2/ Take care of some specific variables we currently support: LibrarianFirstname, LibrarianSurname, LibrarianEmailaddress, count, today, ... 3/ Support of "repeatable": at the moment we cannot loop on elements with [% FOREACH %], it's a shame and frustrating
Note that we already support the TT syntax in the CSV profiles (bug 12404).
The main question is: could we add TT directive in newly created notices (see bug 15705 again)? I would answer yes: it will add examples and people will notice that something has changed. With a good help and good examples, it should not be too hard to understand what does the code.
Cheers, Jonathan
2016-02-02 17:52 GMT+00:00 Kyle Hall <kyle.m.hall@gmail.com>:
I would like to start the discussion Marcel wanted to have at the dev meeting.
Right now, we have one bespoke syntax for slips and notices with all kinds of caveats and limitations.
My first instinct was that we should over time tear out this old syntax and replace it with TT. However, there are some issues:
1) TT is a bit more complicated ( and more powerful of course ) than our custom syntax 2) We have an editor for our current syntax ( though it is somewhat problematic to use at times, as not all fields in the editor are actually available on the notices where they display ) 3) Creating an editor for TT would be somewhat non-trivial if we were to replace what we have with a better and more advanced way of dealing with data passed to the slip or notice.
I'm wondering if we should, at least for the time being, consider the existing notice syntax as the "basic" mode for slips and notices, and have the ability for TT in notices and slips be an 'advanced' mode.
Basically, that means that nothing will change for librarians. The current syntax and editor will continue to be what they are. Instead, 'advanced' users can simply start using TT in their notices and slips. What we will do is document how to use TT in slips and notices in the manual.
So, what I would do at this point is deprecate my replacement notices ( keeping the new methods where necessary for the advanced mode ), and create some good documentation. That way we get the power of TT while retaining backwards compatibility!
What does everyone think? Kyle
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 )
_______________________________________________ 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, On Wed, Feb 3, 2016 at 8:56 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I think Jonathan has an excellent plan of attack, but it does require a complete switchover all at once.
Rather than forcing a complete switchover right off the bat, I suggest adding a flag that specifies whether old-style or TT templates are in effect for a given notice. That way, we'll have much more flexibility to design the new templating mechanism to take full advantage of Template Toolkit, and folks will have the ability to migrate their notices definitions on their own schedule. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
As a consortia manager with lots and lots of letters in this area of Koha, I cannot emphasize enough that making the switchover process with these proposed changes as simple as possible is critical. I'm glad to see consistency getting developed for this area and moving the system forward, but please do keep in mind the day to day library users and administrators who will have to implement these changes on their end. Just my two cents. Galen's suggestion sounds feasible and doable. This reminds me of the bootstrap switchover. We had, what, 2 or 3 versions of warning that prog was going to be retired, and you needed to switchover before 3.18 release? Could the same be handled here? On Wed, Feb 3, 2016 at 9:23 AM Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Wed, Feb 3, 2016 at 8:56 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I think Jonathan has an excellent plan of attack, but it does require a complete switchover all at once.
Rather than forcing a complete switchover right off the bat, I suggest adding a flag that specifies whether old-style or TT templates are in effect for a given notice. That way, we'll have much more flexibility to design the new templating mechanism to take full advantage of Template Toolkit, and folks will have the ability to migrate their notices definitions on their own schedule.
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.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/
-- Heather Braum NExpress Coordinator Resource Sharing Librarian Northeast Kansas Library System hbraum@nekls.org "The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn." ~Alvin Toffler, *Rethinking the Future*
I think that a flag may not even be necessary -- the TT syntax won't conflict with the current letter formats, and is unlikely to be entered accidentally. I think that we could simply silently start to support TT, and no one would be the wiser, except for those who want to use it. This also addresses Heather's concern -- the initial transition would be essentially un-noticable. On Wed, Feb 3, 2016 at 10:22 AM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Wed, Feb 3, 2016 at 8:56 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I think Jonathan has an excellent plan of attack, but it does require a complete switchover all at once.
Rather than forcing a complete switchover right off the bat, I suggest adding a flag that specifies whether old-style or TT templates are in effect for a given notice. That way, we'll have much more flexibility to design the new templating mechanism to take full advantage of Template Toolkit, and folks will have the ability to migrate their notices definitions on their own schedule.
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.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/
I like the idea of the flag as it would allow to keep the code separate from the current notices code and to have a clean start, while we can be pretty sure that the old code still remains working as before. The current syntax is not very consistent across the different notices - <<items.content>>, ----, <item></item>... or in which tables/columns can be included. It would be nice to gain some consistency with this development :) Katrin Am 03.02.2016 um 20:04 schrieb Barton Chittenden:
I think that a flag may not even be necessary -- the TT syntax won't conflict with the current letter formats, and is unlikely to be entered accidentally. I think that we could simply silently start to support TT, and no one would be the wiser, except for those who want to use it.
This also addresses Heather's concern -- the initial transition would be essentially un-noticable.
On Wed, Feb 3, 2016 at 10:22 AM, Galen Charlton <gmc@esilibrary.com <mailto:gmc@esilibrary.com>> wrote:
Hi,
On Wed, Feb 3, 2016 at 8:56 AM, Kyle Hall <kyle.m.hall@gmail.com <mailto:kyle.m.hall@gmail.com>> wrote: > I think Jonathan has an excellent plan of attack, but it does require a > complete switchover all at once.
Rather than forcing a complete switchover right off the bat, I suggest adding a flag that specifies whether old-style or TT templates are in effect for a given notice. That way, we'll have much more flexibility to design the new templating mechanism to take full advantage of Template Toolkit, and folks will have the ability to migrate their notices definitions on their own schedule.
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com <mailto:gmc@esilibrary.com> direct: +1 770-709-5581 <tel:%2B1%20770-709-5581> cell: +1 404-984-4366 <tel:%2B1%20404-984-4366> skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ 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/
_______________________________________________ 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/
I think we have a conflict here of a) Make TT in notices work with the current syntax ( just by replacing <<
with [% %]
and b) Use a flag to decide if it is processed by TT or by the old way of doing things I think if we are going to go with b, we should have the freedom to not be beholden to all the oddities and cruft of the current syntax. For this reason I am a fan of b. Is anyone opposed to this idea? This would give us plenty of time ( all the time we want really ) in which to tweak and perfect the TT based parser before deprecating the current parser. If anyone has an issue with this path, please speak now! Kyle 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 ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Feb 3, 2016 at 3:16 PM, Katrin Fischer <Katrin.Fischer.83@web.de> wrote:
I like the idea of the flag as it would allow to keep the code separate from the current notices code and to have a clean start, while we can be pretty sure that the old code still remains working as before.
The current syntax is not very consistent across the different notices - <<items.content>>, ----, <item></item>... or in which tables/columns can be included. It would be nice to gain some consistency with this development :)
Katrin
Am 03.02.2016 um 20:04 schrieb Barton Chittenden:
I think that a flag may not even be necessary -- the TT syntax won't conflict with the current letter formats, and is unlikely to be entered accidentally. I think that we could simply silently start to support TT, and no one would be the wiser, except for those who want to use it.
This also addresses Heather's concern -- the initial transition would be essentially un-noticable.
On Wed, Feb 3, 2016 at 10:22 AM, Galen Charlton <gmc@esilibrary.com <mailto:gmc@esilibrary.com>> wrote:
Hi,
On Wed, Feb 3, 2016 at 8:56 AM, Kyle Hall <kyle.m.hall@gmail.com <mailto:kyle.m.hall@gmail.com>> wrote: > I think Jonathan has an excellent plan of attack, but it does require a > complete switchover all at once.
Rather than forcing a complete switchover right off the bat, I suggest adding a flag that specifies whether old-style or TT templates are in effect for a given notice. That way, we'll have much more flexibility to design the new templating mechanism to take full advantage of Template Toolkit, and folks will have the ability to migrate their notices definitions on their own schedule.
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com <mailto:gmc@esilibrary.com> direct: +1 770-709-5581 <tel:%2B1%20770-709-5581> cell: +1 404-984-4366 <tel:%2B1%20404-984-4366> skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ 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/
_______________________________________________ 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, On Fri, Feb 5, 2016 at 2:53 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I think if we are going to go with b, we should have the freedom to not be beholden to all the oddities and cruft of the current syntax. For this reason I am a fan of b.
+1 to b. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
+1 to b (b) Use a flag to decide if it is processed by TT or by the old way of doing things Regards Marc Am 05.02.2016 um 21:18 schrieb Galen Charlton:
Hi,
On Fri, Feb 5, 2016 at 2:53 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I think if we are going to go with b, we should have the freedom to not be beholden to all the oddities and cruft of the current syntax. For this reason I am a fan of b. +1 to b.
Regards,
Galen
Same here... +1 to b! Am 06.02.2016 um 10:18 schrieb Marc Véron:
+1 to b
(b) Use a flag to decide if it is processed by TT or by the old way of doing things
Regards Marc
Am 05.02.2016 um 21:18 schrieb Galen Charlton:
Hi,
On Fri, Feb 5, 2016 at 2:53 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I think if we are going to go with b, we should have the freedom to not be beholden to all the oddities and cruft of the current syntax. For this reason I am a fan of b. +1 to b.
Regards,
Galen
_______________________________________________ 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/
participants (8)
-
Barton Chittenden -
Galen Charlton -
Heather Braum (NEKLS) -
Jonathan Druart -
Katrin Fischer -
Kyle Hall -
Marc Véron -
Marcel de Rooy