Re: [Koha-devel] Trouble for the Gitea project: forked to Forgejo

[Marc Véron]

Hi everybody
Why not https://codeberg.org/ ?
Regards
Marc

Am 25.01.23 um 03:45 schrieb Victor Grousset/tuxayo:

Hi :)

Thanks David Nind for sharing this info on the last dev meeting:

Use of Gitea: We use Gitea for git.koha-community.org. Gitea was 
"forked" and is now Forgejo[1] - see the links update and related 
links[2] (sounds eerily familiar 8-(.. ). The community needs to look 
at what to do next, such as whether to continue to use Gitea, update 
to Forgejo, do something else (David Nind)

[1] https://forgejo.org/

> [2] https://forgejo.org/2022-12-26-monthly-update

Comments during the meeting:


forgejo is the 'good' one?



that's what it looks like ^^


"After Gitea Ltd confirmed the takeover of the Gitea project on 30 
October 2022, a group of people proposed that Codeberg e.V. should 
become the custodian of a fork of Gitea. The proposal was accepted 16 
November 2022" - e.V. is a German thing actually


More details:

e. V. is the legal form for associations in Germany and Codeberg e. V. 
is known for their Gitea (well, now Forgejo) instance that became host 
to a decent number of libre projects in the last two years.
(likely they moved away from GitHub and not wanted the not libre 
GitLab instance at GitLab.com (open-core))



Trivia:
> Forgejo (pronounced /forˈd͡ʒe.jo/) is inspired by forĝejo, the 
Esperanto word for forge.


 I knew the name spelling looked familiar!


Cheers,


___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Mailinglist "Koha"

[Marc Véron]

I sent my request about Bug 18483 Customised help: Enhance staff client 
with news based, easily editable help system (Passed QA -> In 
Discussion) to Koha and Kona-devel (as requested by 
https://wiki.koha-community.org/wiki/Bug_and_Enhancement_Discussion), 
but it showed up on Koha-devel only. So something seems to be wrong with 
the Koha list.


Marc


Am 30.10.2017 um 20:48 schrieb Jonathan Druart:

Sorry, I did not see Owen's reply

On Mon, 30 Oct 2017 at 16:47 Jonathan Druart 
> wrote:


Here are the archives:
https://lists.katipo.co.nz/pipermail/koha/2017-October/thread.html
Last msg is from Thu Oct 26 04:02:18 NZDT 2017

On Mon, 30 Oct 2017 at 16:25 Michael Kuhn > wrote:

Hi Owen

Am 30.10.2017 um 19:58 schrieb Owen Leonard:
 >> Does anyone know hat happened to the mailinglist "Koha",
it seems the
 >> list has become inactive? I haven't received any e-amils
from there
 >> since October 25.
 >
 > The last message according to the archive was on the 26th:
 >
 >
https://lists.katipo.co.nz/pipermail/koha/2017-October/date.html
 >
 > Looks to me like there have been multi-day gaps in postings
before,
 > but if you posted something recently which didn't show up,
something
 > may be going wrong.

So I think there is definitely something wrong because I posted an
answer today 30 October at 00:26 MET. It hasn't appeared until
now.

I don't know who to address to change this but maybe now the
case is
getting some attention.

Best wishes: Michael
--
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg.
Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61  · E
m...@adminkuhn.ch  · W
www.adminkuhn.ch 
___
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/


___
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] Vote request for Bug 18483 Customised help: Enhance staff client with news based, easily editable help system (Passed QA -> In Discussion)

[Marc Véron]

Dear Koha community

On 2017-04-22 I filed Bug 18483 "Customised help: Enhance staff client 
with news based, easily editable help system".

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18483#c0

The Enhancement was ready for Sign off on 2017-04-30, was signed off on 
2017-05-02, and, after some discussion, passed QA on 2017-10-27, and the 
same day was set to "In Discussion".


The aim of the bug is described in the initial comment. It fills a 
request we have since 2012. In short, it is about having an additional 
help system that allows libraries to create their own, library specific 
help information, taking advantage of all functionality we already have 
with the news system.



Initial comment:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18483#c0

---Quote---
"Koha's staff client has a file based help system with an edit function 
for customising. However, the edited files have to be saved and restored 
with each release. Otherwise they are overwritten.


As an enhancement or alternative, the existing news system can be used 
to implement a complementing help system. Similar to the news, the text 
can be created for all branches or for individual branches. Help is 
context sensitive (based on the existing help system), and it can be 
created / edited directly from the help page (based on a user permission).


The display can be managed with a system preference (Bug 18472: Add 
system preference CustomOnlineHelpStaff to hide / select custom online 
help system)."

---End quote ---


Author's answer on a question of QA team member M. de Rooy (asked on Bug 
18472, Comment 21), moved to Bug 18483:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18483#c21

---Quote---
Need:
- Having a user editable, page aware help system is a long outstanding 
need. First time I was asked for goes back to 2012.

- We have libraries interested in Koha who ask for in their requirements.
- Writing a brand new help module would take a lot of time. And who 
would fund it?


User:
- The news system works very well and libraries are used to use it. The 
help additons introduced in Bug 18483 enhances the news system to host 
custom help as well.
- From a user standpoint it is easy to use, you can add whatever you 
want / need as help. All the benefits of the news system can be used. 
Custom help items can easyly be added / edited.
- It can be turned on and off (combined with the existing file based 
help system or 'standalone'). This Bug 18472 is the basis for turning on 
and off and/or add additional help systems.
- There is no change in behavior of news and file based help system if 
turned off (however this patch allows to turn off the edit function of 
the existing file based help system).


Impact:
- In Bug 18483, I paid great attention to have a minimal impact on 
existing code. No changes in .pm files were needed.
- There is a small database change to have a field to host the page key 
if a news item is used as help item.


Things to come:
- Since the news system works for both staff client and OPAC it will be 
easy to implement the editable help for OPAC as well (Bug 18515)


So I kindly ask for Bug 18472 and Bug 18483 to make part of Koha.
---End quote---

After the enhancement has been put to "In discussion", I kindly ask the 
Koha community to vote about Bug 18483 as outlined in:

https://wiki.koha-community.org/wiki/Bug_and_Enhancement_Discussion

Thanks and kind regards

Marc Véron
Koha Support Schweiz
www.koha-support.ch
Contributing to Koha since 2012

___
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/

Re: [Koha-devel] Best place for test plans

[Marc Véron]

Hi David

I think it is a good practice to have the test plan as commit comment 
and to obsolete any comments that are related to obsoleted patches. In 
Bugzilla, comments can be obsoleted by entering the keyword 'obsolete' 
as tag and then hit the return key.


Marc


Am 04.10.2017 um 01:56 schrieb David Cook:


Hi all,

I’ve been wondering about the best place to put test plans. I think 
traditionally we include them in our git commits, but I feel like it 
would be better to include them as standalone comments in Bugzilla.


My reasoning is that finding test plans can be really difficult when 
you’re scrolling back through numerous autogenerated per-commit 
comments. And if there is lots of rebasing or modifications, you wind 
up with a million test plans, so you can’t even Ctrl + F really.


I figure when a patch is ready for testing, the developer should write 
1 comment containing all test plan instructions and post it to the 
bottom of Bugzilla. That way, testers can just Ctrl + F for test plan, 
find the lowest one, and just consider that in their testing.


What do you all think?

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595



___
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/

Re: [Koha-devel] [SIGNED_OFF] labels

[Marc Véron]

+1


Am 25.08.2017 um 08:52 schrieb David Cook:


+1

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

*From:*koha-devel-boun...@lists.koha-community.org 
[mailto:koha-devel-boun...@lists.koha-community.org] *On Behalf Of 
*Marcel de Rooy

*Sent:* Friday, 25 August 2017 4:29 PM
*To:* Koha-devel 
*Subject:* [Koha-devel] [SIGNED_OFF] labels

Hi all,

I would favor stopping the use of adding [SIGNED_OFF] labels to 
patches when it is not strictly needed (which normally is the case).


Only when (exceptionally) a few patches are signed and a few are not 
on one report, I could see its use.


At this moment they need to be obsoleted manually with git bz.

Can we stop adding them ?

Marcel



___
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/

Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

[Marc Véron]

Sorry for the empty message... What I wanted to say:


+1 for improving the dashboard
(I always check the dashboard first, then the Bug tracker, then the list 
of bugs to sign off, then my open bugs...)



Maybe the Dashboard could contain the links to the newest bugs / changed 
bugs from the Bug trackers start page:



Bugs reported in the last 24 hours   | last 7 days
Bugs changed in the last 24 hours   | last 7 days


Marc


Am 11.08.2017 um 15:34 schrieb Marc Véron:




Am 11.08.2017 um 11:55 schrieb Marcel de Rooy:


+1 for improving the dashboard

Instead of listing the oldest bugs, which may not be that 
interesting, we should list the critical ones on top. The need to 
click on that line should be removed. See them rightaway. Maybe we 
can put these oldies somewhere down on the page in order to not 
forget them?





___
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/


___
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/

Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

[Marc Véron]

Am 11.08.2017 um 11:55 schrieb Marcel de Rooy:


+1 for improving the dashboard

Instead of listing the oldest bugs, which may not be that interesting, 
we should list the critical ones on top. The need to click on that 
line should be removed. See them rightaway. Maybe we can put these 
oldies somewhere down on the page in order to not forget them?





___
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/

Re: [Koha-devel] Expected behaviour if itemtype does not exist

[Marc Véron]

Hi everybody

I think that a note on the about page would be very useful.

Marc

Am 08.08.2017 um 19:26 schrieb Katrin:


Hi Jonathan,

I think in this case it's probably a migration issue that should be 
fixed. Catching them with a script makes sense to me.


Katrin


On 08.08.2017 18:24, Jonathan Druart wrote:

Hi Katrin,

Sorry for the late reply.

It's not about the translation, but the existence of the item type.
  my $item_type = Koha::ItemTypes->find('BOOK');
  $item_type->description; # Or whatever method call
will fail if "BOOK" is not defined.

My question was: If an item is defined with a items.itype (or 
biblioitems.itemtype) that is not an entry in the itemtypes table, is 
it considered as a configuration issue?
If yes, I will write a script to catch them, add something to the 
about page and the update database process.

If not, we will have to handle that case everywhere in the code.

Cheers,
Jonathan

On Fri, 14 Jul 2017 at 04:37 Katrin > wrote:


Hi Jonathan,

I am not sure if I understand correctly, but I think translating
the itemtype descriptions should be optional not mandatory, so
not causing errors if the itemtype otherwise is set up correctly
(having a 'default' description).

Hope that helps,

Katrin


On 12.07.2017 20:50, Jonathan Druart wrote:

Hi devs,

Since bug 17843 I get errors if the item type (items.itype or
biblioitems.itemtype depending on the pref item_level_itypes)
does not exist as an item type (table itemtypes, filled by
Administration › Item types administration).
The error (Can't call method "translated_description" on an
undefined value) appears because we call a method on an
undefined value.
As this is a configuration issue (right?) I think we should add
an alert from the updatedatabase.pl 
script, then a warning on the about page.
Would that be enough or should we handle the problematic case
anyway (i.e. call the method only if the item type exists in DB)?

Cheers,
Jonathan


___
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/



___
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/


___
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/

Re: [Koha-devel] Suggestions requested for a feature / enhancement based around opac-retrieve-file.pl

[Marc Véron]

+1 from me

Questions:
- Where would the information go about downloadability (and 
availability, see below)? (Biblio record, item record...)
- Will there be a need for granularity, e.g. allow download only for 
users of a certain user type (Staff, Teacher...)?


A related functionality could be to mark items (of any type) to be 
hidden in search results for non logged in users.
Similar to AgeRestrictionMarker and/or OpacSuppression ( Hide items 
marked as suppressed from OPAC search results. )


Then it would be a good idea to manage an "embargo date". Such downloads 
(and/or items) would automatically become available / visible after a 
certain date.


Just my 2 cents :-)

Marc


Am 26.06.2017 um 07:50 schrieb Tomas Cohen Arazi:
It's a simple addition I've been thinking of too. Adding the 'logged 
in user' option to file uploads. It should be very simple to implement.

+1 from me.

El dom., 25 jun. 2017 a las 19:15, Indranil Das Gupta 
(>) escribió:


Hi all,

the current Koha::Upload.pm and opac-retrieve-file.pl
 allows for a
uploaded file (e.g. PDF) to be displayed on the OPAC as long as the
flag is set to public.

I know how many librarians feel about reader history privacy and they
are protective about it for good reason. In this context, I'm faced
with the following two use-cases:

In India, e-books with archival rights are gaining ground over
hardcopy. As it happens the buyer (institutional library) has to give
an undertaking that it will implement reasonable safeguards to ensure
that while all their bonafide users should have access to the books,
these shall not be presented to the users in such as way as to permit
un-monitored access / downloads by un-authenticated users etc along
with maintenance of any access log for any necessary compliance.

Or for example PhD theses where many institutions across India have an
embargo on the full-text online access for non-members for a period
upto 2 years from the date of publication, but no such restriction
exist for bonafide authorised users.

I am working on an early stage prototype to support this sort of
functionality. My question here to  you all is that how far are we
open as devs and librarians to accept such an extension into Koha? Of
course, there would be a syspref that will have to be set for the
functionality to  kick in.

Suggestions? Comments?

regards
indranil

--
Indranil Das Gupta
L2C2 Technologies

Phone : +91-98300-20971 
WWW  : http://www.l2c2.co.in
Blog: http://blog.l2c2.co.in
IRC : indradg on irc://irc.freenode.net 
Twitter : indradg
___
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 )
✆ +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/


___
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/

Re: [Koha-devel] marcxml > biblio_metadata - Automatically convert reports

[Marc Véron]

+1 for this, even if we are in string freeze

We will have a mix between translations and English anyway in the more 
exposed install tool (see Bug 18629), so some more English strings are OK.


Marc


Am 19.05.2017 um 18:15 schrieb Jonathan Druart:

Hi guys,

It seems like my calls did not get the expected attention, so I am 
trying once again.
Bug 17196(Move marcxml out of the biblioitems table) has been pushed 
to master a while ago and 17.05 will be the first release with this 
change.
I wrote bug 17898 (Add a way to automatically convert SQL reports) 4 
months ago asking for a special attention: librarians will need it to 
update easily their reports.
Since 17.05 is going to be released in a week and we are in string 
freeze, I guess there is no way to get it in. But I personally think 
that we should make an exception for this one.


Please do not let this request without answer once again.

Cheers,
Jonathan


___
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/

Re: [Koha-devel] Acquisitions change in Koha 16.11 and forward

[Marc Véron]

+1
Marc


Am 09.05.2017 um 22:44 schrieb Nick Clemens:

Hello All,

With the current versions of Koha there have been some changes in 
acquisitions and how prices are calculated and there seems to be some 
confusion in terms and how things are currently being used.


We wanted to clarify what is happening, propose a change and get 
feedback on what needs to happen.


When placing an order there are several price fields:
Vendor price (listprice in db)
-This is used to populate the Replacement cost and budgeted cost on 
the order page. It is not used against the budget


Replacement cost (rrp in db)
-This is used to calculate the 'budgeted cost/ecost' in the budget - 
it also populates the replacement price in the item created by the aqc 
process once received


Budgeted cost (ecost in db)
-This is the replacement/rpp minus any discount on the order - this is 
the value that will be encumbered when the order is placed


Actual cost (unitprice)
-This is the eventual 'price' of the item and is the encumbered amount 
once the item has been received.


With the changes that were made one can no longer adjust the 
'Replacement/RRP' once an order is placed - this is because this value 
is adjusted for tax in the db (rrp_tax_excluded, rrp_tax_included) and 
used for calculating the ecost tax adjusted (ecost_tax_excluded, 
ecost_tax_included)


Some libraries have been having issues as they use 'Replacement' cost 
mostly for populating items and are not used to it being unable to be 
edited and/or affecting budgets.


We are proposing to rename the current 'Replacement cost' field to 
match the db value - 'Recommended retail price' (RRP) and add a new 
'Replacement cost' field, editable at any point, that is only used for 
populating the item field.


We think this will clear up how the other values are being used and 
restore functionality that changed.


Please let us know if this works or what other suggestions you have here.

Thank you,
Nick, Kyle, Jonathan


___
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/

Re: [Koha-devel] The interface "winks" when I check out a book after upgrading firefox

[Marc Véron]

Thanks, François, for filing Bug 18518
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18518

I could reproduce with Firefox ESR 45.3.0 (Debian) as well by slowing it 
down. See comment on Bug.


Marc


Am 30.04.2017 um 23:08 schrieb Francois Charbonnier:


Thanks Marc! That's exactly what I mean. Do you think it's something 
that can be fixed ?



François Charbonnier,
Bibl. prof. / Chef de produits

Tél.  : (888) 604-2627
francois.charbonn...@inlibro.com 
<mailto:francois.charbonn...@inlibro.com>


inLibro | Spécialistes en technologies documentaires | www.inLibro.com 
<http://www.inLibro.com>

Le 2017-04-28 à 15:35, Marc Véron a écrit :


Hi François

I have a strange 'blinking' or 'winking' on current master as well - 
not sure if we speak about the same thing:


- On the staff client main page, click on 'Patrons'
- While loading the page, I see very shortly a yellow message "Add 
patrons to" (I took a video and stepped through it to be able to read 
the text).

- Then the page refreshes and displays as expected.
- I get the same when I am on the page Home > Patrons and click 'Search'.

I get it with Firefox 53.0  (Windows)
I do not get it with Firefox ESR 45.3.0 (Debian)

Is it that what you mean?

Marc

Am 27.04.2017 um 20:58 schrieb Francois Charbonnier:


Hi,

I use Koha 16.05 and firefox 53. When I check out an item, the 
interface "winks".


I tried this with firefox 52, the interface stays still.

Have you noticed it as well ? Any advice to fix it ?

Thanks!

--
François Charbonnier,
Bibl. prof. / Chef de produits

Tél.  : (888) 604-2627
francois.charbonn...@inlibro.com 
<mailto:francois.charbonn...@inlibro.com>


inLibro | Spécialistes en technologies documentaires | 
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/




___
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/

Re: [Koha-devel] Gender-neutral pronouns

[Marc Véron]

+1 for trying to achieve gender neutrality

Marc


Am 19.04.2017 um 02:25 schrieb Eric Phetteplace:

Hi list,

I opened bug #18432 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18432 
because I saw several places in the Koha codebase where the pronoun 
"he" was being used to refer to a generic third person who could be of 
any gender. Jonathan Druart noted that this should be a coding 
guideline, as otherwise new instances of gendered pronouns might 
continue to be added. Perhaps it belongs on the "Terminology" page of 
the wiki?


So here's my proposal. I'm trying to be concise.



*Use gender neutral pronouns*
*
*
When referring to a person who could be of any gender, you should use 
the words they/them/their. This goes for code comments, text in 
templates, and strings in tests. For example, here's a string from a 
patrons test updated to be gender neutral.


Before*:*
*
*
is( $total, $enrolmentfee_K + $enrolmentfee_J, "Kid growing and become 
a juvenile, he should pay " . ( $enrolmentfee_K + $enrolmentfee_J ) );


After:

is( $total, $enrolmentfee_K + $enrolmentfee_J, "Kid growing and become 
a juvenile, they should pay " . ( $enrolmentfee_K + $enrolmentfee_J ) );


Gender neutral terms are preferable for a few reasons. They're more 
welcoming, showing that Koha expects users and contributors to be of 
any gender. They're also more accurate. Inappropriately using a 
particular gender can cause confusion, leading someone to believe that 
code operates differently based on the value of borrowers.sex, for 
instance.




I hope that's clear. I'm happy to reword it, and to attend the next 
Koha developers meeting to explain further if need be.


Best,
Eric Phetteplace
Systems Librarian
California College of the Arts
libraries.cca.edu  | vault.cca.edu 


510.594.3660
2>/dev/null


___
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/

Re: [Koha-devel] Development/ QA protocol question

[Marc Véron]

+1 for using 'Patch complexity'

'Patch complexity' gives a hint for singing off as well. While signing 
off I fill it in most of the cases. Sometimes I forget it, though...


Marc


Am 30.03.2017 um 08:34 schrieb Marcel de Rooy:

I always fill patch complexity. Also for patches that I qa.
And not filling that field (and/or other fields) gives it a lower priority.
And yes, the number of lines is not the same as complexity.

-Oorspronkelijk bericht-
Van: koha-devel-boun...@lists.koha-community.org 
[mailto:koha-devel-boun...@lists.koha-community.org] Namens Cab Vinton
Verzonden: woensdag 29 maart 2017 23:01
Aan: Jonathan Druart 
CC: koha-devel@lists.koha-community.org
Onderwerp: Re: [Koha-devel] Development/ QA protocol question

On Wed, Mar 29, 2017 at 4:58 PM, Jonathan Druart 
 wrote:

There is a "Patch complexity" field, but I personally do not use it (I
should yes).

I've see. Don't think anyone else uses it either :-)

Would be cool if it auto-populated with the number of new/ different lines in the 
patch ... Pretty rough & ready measure of complexity.
___
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/



___
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/

Re: [Koha-devel] Bug 5670: Housebound Module

[Marc Véron]

+1 for a new table, called 'housebound_role'

Marc


Am 29.09.2016 um 13:28 schrieb Alex Sassmannshausen:

Hello,

Whilst putting finishing touches on Bug 5670 Housebound Readers Module,
a discussion was started on the best way to handle database architecture
for a part of the feature.  Jonathan, who has been heavily involved in
reviewing the patch series so far, quite rightly suggested we get some
additional opinions.

You can read the discussion on the bug (it's quite old, the last few
comments are probably most relevant), but as a summary (primarily of my
perspective):

The housebound module relies on assigning one or two roles to patrons
registered in Koha.  Patrons can be 'deliverers' (delivering items to
housebound patrons), 'choosers' (selecting items which can then be
delivered by deliverers), or both.

The current implementation uses extended patron attributes, but I would
agree that this implementation is probably sub-optimal for the use case
of the Housebound module.

We are now debating whether it is better to add 2 new columns to the
borrowers table (increasing the number of columns from 69 to 71), for
the two new roles, or whether we should create a new table, called
'housebound_role' to go with 'housebound_profile' and
'housebound_visit', which consists of
- borrower_id (foreign key to borrowers.borrowernumber)
- deliverer (boolean)
- chooser (boolean)

My personal feeling is that the latter approach is better for the
following reasons:
- Housebound module is an optional feature switched on in sysprefs.
- For the sites that enable it, I would expect that only a small
percentage of all registered patrons become volunteers

As a result, the housebound_role table will be empty for sites that have
the feature disabled, and small for sites that have it enabled.

Going with the former approach will implicitly create values for every
patron in the installation, even if the feature is switched off.

For future development, making changes to the housebound_role table
would be less intrusive than making changes to the borrowers table.

Finally, from a data integrity perspective, I cannot see either approach
being better or worse at this point: the foreign key constraint will
ensure data integrity, and the table is normalized in either case
(though I'm certainly not an expert in this area).

WDYT?

Best wishes,

Alex
___
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/

Re: [Koha-devel] To React or not to React

[Marc Véron]

Regarding licensing:

https://en.wikipedia.org/wiki/React_(JavaScript_library)

See part "Patents clause controversy"

Marc


Am 19.09.2016 um 17:15 schrieb Paul A:

At 08:18 AM 9/19/2016 -0400, Kyle Hall wrote:

Thanks for the feedback Stefano!
Please, if anybody is *against* the use of React in Koha, please 
voice your concerns!


Question: what has Facebook added to js that we could not use as 
"regular" js? Not a show stopper, but our "gut feeling" (not fully 
documented, but more than anecdotal) is that all js code, given its 
standalone capability, has a more than proportional speed downside. 
And I'm not going near the licensing questions.


If I understand this bug 17297 ("low enhancement") correctly, it 
refines itemnotes by adding granularity. If this is a "good thing", 
can the original coding be improved? Add an auth value? If we need js, 
how optional might this be? (do we know how many Koha users are truly 
interested?)


I've always been impressed by Koha core speed, and without using such 
expressions as "mission creep" (or heaven forfend, code bloat) I truly 
recognize that enhancements are a real life necessity. Just wondering 
how and where they are best added while maintaining the KISS principle...


Best -- Paul



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 )

On Fri, Sep 16, 2016 at 9:50 AM, Stefano Bargioni > wrote:


My +1 for React. Angular requires a specific skill, other than
Javascript.
Stefano


On 15 set 2016, at 19:22, Kyle Hall > wrote:

I have my proof of concept for using React within Koha
completed! You can see it here:Â
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297

Please give it a try!

So, I've written this development ( at least in part ) in
both Angular and React. I know Angular 2 is out but here
are my thoughts so far.

1) It's much easier to think in React than in Angular.Â
React is for the most part just Javascript. It's far less
opinionated than Angular. They saying goes React is
Javascript and Angular is Angular. I think the flexibility
of React works well within the Koha ecosystem.

2) Writing React feels much more like programming. I think
it's much faster to develop reactive and ajax features inÂ
React than it is using jQuery.

3) React makes it pretty easy to create widgets that we
can drop in to a given page and have just work. Pretty much
anything that shows up on multiple pages would make for a
good React widget. Think the holds table which is on the
checkouts page and the patron details page. It is ajaxified
now, but a far far cleaner version could be written in React.

4) React is just a view layer. Angular is a full MVC
framework with many pieces we don't really need.

I think React is probably the way to go for Koha. I like
Angular but for Koha in particular, I think React is a
better fit. I think we really need to get this decision made
as soon as possible. If anyone has opinions, please let
everyone know!

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/


___
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/ 


---
Maritime heritage and history, preservation and 

Re: [Koha-devel] Proposal to join the QA team for packaging related bugs

[Marc Véron]

+1

:-)

Marc


Am 14.08.2016 um 09:44 schrieb Katrin Fischer:

+1, of course :)

Am 13.08.2016 um 21:05 schrieb Mirko Tietgen:

Hello everyone,

part of the idea of nightly packages is to constantly update the
Debian related files that deal with depenencies. I would like to
find and solve possible dependency problems early and minimize the
delay between Koha release and related package release.

The process to build nightlies is getting more stable now. I have
tested automatic patches to the debian/control file -- that is the
file that contains the package dependencies -- and I think it will
be a helpful tool.

I have created bugs labelled "Automatic debian/control updates" for
master, stable and unstable, and added Kyle, Frederic and Julian
respectively.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17084
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17108
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17111

The bugs get automatic updates after each nightly build process, as
long as they lead to changes in debian/control. To avoid spamming
the bugs I have changed that now to "send patch only if bug status
is 'Assigned'" (untested :P)

There is not really anything to test here, besides a manual sanity
check. But it will consume resources to go through the QA process
every single time there is a change. For that reason I propose I
join the QA team for packaging matters, do a signoff on the
automatic patches (as long as they are ok), label them "Passed QA"
and send them over to Kyle, Frederic and Julian so they can be
pushed early.

Any objections? Comments?

Cheers,

Mirko


--

Mirko Tietgen
mi...@abunchofthings.net
http://koha.abunchofthings.net
http://meinkoha.de




___
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/



___
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/

Re: [Koha-devel] 16909 breaks member add

[Marc Véron]

Hi Blou,

See Bug 16941 - Can not add new patron in staff client

(Status Critical, PQA)

Marc


Am 21.07.2016 um 15:59 schrieb Philippe Blouin:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16909

It's been pushed to master, but seemingly is the cause of not being 
able to add new member.  Pressing Save just brings us back to the page.


Not sure exactly what I should be doing with the status and importance 
of the bug, but this blocks further development (short term) and 
obviously any release (long term).

What is the correct procedure to raise the issue?

Thanks
Blou

Philippe Blouin,
Responsable du développement informatique

Tél.  : (888) 604-2627
philippe.blo...@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/


___
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/

Re: [Koha-devel] How do we find consensus on interface changes?

[Marc Véron]

+1 for 'Style guidelines' and 'GUI manager'

Regarding the Wiki:
https://wiki.koha-community.org/wiki/Interface_patterns
https://wiki.koha-community.org/wiki/Developers_Handbook (1.2 User 
Interface)


Should this be consolidated in one document?

Marc


Am 01.06.2016 um 02:43 schrieb Kyle Hall:
I think you've summarized everything nicely. If Owen were interested 
in taking some official mantel I would not be opposed ; )


I think we need to focus on expediency and uniformity primarily. I 
think we basically have those two things, but they could both be 
improved. I would be more than happy to work on adding a UI guidelines 
section to the wiki. For those interested, here is what I've done so 
far: https://wiki.koha-community.org/wiki/Developers_Handbook


It's a bit rough now because it's really guideline-centric, but I 
think over time it will come into its own quite nicely. Constructive 
criticism is welcome!


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 )

On Tue, May 31, 2016 at 5:26 PM, Katrin > wrote:


I like the idea of having a role like 'GUI manager' and also the
idea of having style guidelines for the interfaces. Actually, I
think. we already have both of those, as Owen has been working on
writing documentation about existing patterns on the wiki.

I am not in favor of approving every change that would change the
screenshots, as that would make the clean-up work much harder,
that Owen, Aleisha and others have done recently. For bigger
changes I'd try sending links to screenshots/bug reports to the
mailing list to get some opinions - if there is no clear
direction, we can still schedule an official discussion/vote at a
meeting.

Katrin


On 31.05.2016 23:54, Kyle Hall wrote:


Love it! I'd say this is a much better idea!

Kyle

Sent from my phone. Please excuse my brevity.

On May 31, 2016 4:25 PM, "Eric Bégin" > wrote:

I would rather have a Interface guideline the same way we
have coding guidelines.

I'm pretty sure that there are some UX design patterns
available somewhere.

If we would like to have a rules, I would suggest that
something that changes the screenshot used in the user
documentation should be approved, especially when it doesn't
add features.

Eric

On 2016-05-31 15:49, Kyle Hall wrote:


I'm concerned that we are going down a road where every
patch submitted to the Koha project will end up requiring a
community vote. I think it would be more reasonable and
efficient to add a community UI manager role to the project.
Someone who is empowered to make executive decisions on this
matter. Either that or accept that the way team rules on
this matter. The community votes them in after all!

Kyle

Sent from my phone. Please excuse my brevity.

On May 31, 2016 3:32 PM, "Christopher Davis"
>
wrote:

Owen,

I think that Koha users should voice their opinion/votes
as that the
Koha software, more or less, belongs to them. Now, what
vehicle should
we use to collect everyone's opinion/vote (like Survey
Monkey, Google
forms, IRC voting, etc.) and should there be a committee
formed for
this purpose? Maybe decisions such as this one should be
voted on
during Koha Devl IRC meetings?

My $0.02 worth,

Christopher Davis, MLS
Systems & E-Services Librarian
Uintah County Library
cgda...@uintah.utah.gov 
(435) 789-0091 ext.261 
uintahlibrary.org 
basinlibraries.org 
facebook.com/uintahcountylibrary

instagram.com/uintahcountylibrary



On Tue, May 31, 2016 at 1:01 PM, Owen Leonard
> wrote:
>> Could the new features which you are proposing be
optional?
>
> They're not really new features, they're just changes
to the way
> existing features look. We can't build options for
 

Re: [Koha-devel] Discussion for Bug 14757 - Allow the use of Template Toolkit syntax for slips and notices

[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  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/

Re: [Koha-devel] Need to improve anti-spam for opac-suggestions

[Marc Véron]

There is already a text based captcha in opac/opac-memberentry pl.

It asks something like the following (with a random string):

Please type the following characters into the preceding box: ODXZX
Note: The preceding box is case-sensitive. Ensure that the entered 
characters are in all-caps.


- What ist the experience with this captcha?
- Possible improvement:
  - Do not call the fieldset / field 'captcha' or the like to make it 
harder for robots to recognize it as captcha field.

  - Combine it with e negative captcha?

Marc



Am 03.02.2016 um 06:54 schrieb David Cook:


I actually had a thought about that as well. What about text-based 
captchas? That shouldn’t discriminate against anyone.


Something along the lines of “please enter the third word from the 
first sentence in the paragraph above into the following box”, and 
possibly have the numbers in that instruction change randomly.


That wouldn’t discriminate against someone who couldn’t use an 
image-based captcha. I think the main downside of that one is that 
it’s a bit verbose for users… but it should be accessible.


Another thought would be to increase the information stored in the 
database… and maybe allow librarians to flag certain IP addresses as 
bots. It wouldn’t be perfect but it could provide some relief.


Other ideas… if they send data that doesn’t fit the field type, we 
might ask the user if they’re a robot. I noticed that the year fields 
in `suggestions` weren’t being filled correctly with the spam, so 
someone is probably sending “G:SDHGAEGH” at a field which should be 
something like “2011”. In other words, we might try adding some basic 
heuristics and prompt the user if we suspect that they might not be 
human (I dislike saying that as the email archive will make me seem 
overly human-centric in the future when we’re sharing the Earth with 
sentient AIs or aliens..).


Maybe even a confirmation screen after clicking submit which might ask 
them to re-enter some information or answer a question. Also not 
perfect but perhaps better than nothing.


David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St, Ultimo, NSW 2007

*From:*Chris Cormack [mailto:chr...@catalyst.net.nz]
*Sent:* Wednesday, 3 February 2016 4:42 PM
*To:* David Cook ; 'koha-devel' 


*Subject:* Re: [Koha-devel] Need to improve anti-spam for opac-suggestions

Positive captchas are still discrimatory. The reasons for not using 
them are as valid now as they were then.


I guess the question is would you rather discriminate against 
potential or current users or deal with the spam. Long winded way of 
me saying we should find a better tool than positive captchas or deal 
with the spam.


My 2 cents

Chris

On 3 February 2016 4:09:53 pm AEDT, David Cook 
> wrote:


Hi all,

It looks like we may need to improve anti-spam for
opac-suggestions.pl.

A negative captcha was added with
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3144,
but I’m noticing a distributed spam attack which appears to either
be wise to the “negcap” field or is occasionally lucky to
accidentally not put any data with that parameter.

Back in the day, we decided not to go with a positive captcha for
accessibility reasons. I suppose we do have a positive captcha in
the patron self-registration (I think) so maybe we should add one
here. Or… think of something else clever.

Ideas?

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St, Ultimo, NSW 2007



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/

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
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/

Re: [Koha-devel] Need to improve anti-spam for opac-suggestions

[Marc Véron]

Hi Brooke,

This is covered by a system preference:
AnonSuggestions:   [Allow / Don't allow] patrons that aren't logged in 
to make purchase suggestions.


Am 03.02.2016 um 14:28 schrieb BWS Johnson:

Salvete!

 Shouldn't that just draw on the list of registered borrowers? I'm trying 
to think of a situation where I'd take a suggestion from someone that's not a 
Patron, and in those cases they either ring the Library directly or email me.

Cheers,
Brooke
___
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/

Re: [Koha-devel] feature for bugzilla ?

[Marc Véron]

Hi Paul,

Reading bug threads is sometimes really hard.

+1  for the idea to have the possibility to collaps comments!

Marc


Am 18.12.2015 um 10:34 schrieb Paul Poulain:

Hi all,

when an entry on bugzilla has a lot of comments, it can take "hours" 
to read all the thread, find relevant and obsolete comments,... 
understand who said what and where we are now.


Justs have a look at -randomly chosen- 
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6934 to see 
this (only 33 comments, not so hard to follow, but will take a lot of 
time. Other bugs are really a nightmare !!! )


I was wondering if there could be an Addon, a feature, un plugin, or 
whatever, that could "obsolete" a comment. An obsoleted comment would 
be collapsed by default. Anyone can obsolete a comment, it's just to 
(hopefully) have a thread easier to read.


Another option could be to put a color on comment that are relevant.

There could be other way to achieve the goal.

But currently, one must be highly motivated to work on a sign-off, 
except if the bug is "new" ! (I suspect that's a reason why some 
patches are stuck)




___
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/

Re: [Koha-devel] Testing party on Thursday 17 December at Lyon 3 University

[Marc Véron]

Hi Sonia,

Great!

I have some translatability bugs to propose - can you please add me to 
the Trello list?


Cheers

Marc Véron


Am 15.12.2015 um 13:33 schrieb BOUIS Sonia:


Hi,

Just before breaking for Christmas holidays, we are organising a 
testing party at Lyon 3 University.


We have selected several bugzilla tickets as you can see on this 
Trello : https://trello.com/b/PcSNIggo/journee-test-lyon-3-17-12-2015


If you want to propose us others tickets with patch easy to test on a 
sandbox or to add a comment, don’t hesitate. (Trello is public, but I 
think I have to add you if you want to comment or change something)


Cheers,

*Sonia BOUIS*

*Responsable du Système intégré de gestion des bibliothèques***

**

*bIBLIOTHÈQUES UNIVERSITAIRES*

*Université Jean Moulin Lyon 3*

6 Cours Albert Thomas - B.P. 8242 – 69355 Lyon Cedex 08

*ligne directe **:**+*33 (0)4 78 78 79 03*| **http://bu.univ-lyon3.fr 
<http://bu.univ-lyon3.fr/>*


**

*/L'Université Jean Moulin est membre fondateur de l'Université de Lyon/*



___
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/

Re: [Koha-devel] Get rid of item-level_itype?

[Marc Véron]

+1 for removing complexity

Marc Véron


Am 11.12.2015 um 13:04 schrieb Jonathan Druart:
> Hi devs,
>
> Friday is a good day for this kind of questions, fasten your seat belt
> for a time travel.
>
> As many of you know, the item type is not correctly managed all around
> the different Koha modules. Sometimes it's, sometimes it's not.
> The main issue is that we deal with it at too many places and the code
> is not clean/centralised at all.
>
> So I have searched for previous discussions on this subject and I have
> found this "Abandoned RFC" on the wiki :
> http://wiki.koha-community.org/wiki/Mandate_item-level_circulation_rules_RFC
> filled from this koha-devel thread
> http://lists.koha-community.org/pipermail/koha-devel/2008-October/031144.html
>
> The questions are:
> 1/ Is this still valid?
> 2/ Is there something missing in the different steps described?
> 3/ Does someone have some other suggestions to do?
>
> I would be happy to provide this change but first I would like to get
> confirmation about it and get people involved in signoffing/QAing the
> possible patch set.
>
> Cheers,
> Jonathan
> ___
> 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/

Re: [Koha-devel] Release notes

[Marc Véron]

+1 (for the BZ custom field for release notes)

Regards

Marc Véron

Mitglied Koha Support Schweiz
www.koha-support.ch

---
marc veron ag informatik information internet
Baslerstrasse 50
CH - 4123 Allschwil

+41 61 483 84 61

www.veron.ch


Am 02.12.2015 um 18:00 schrieb Frédéric Demians:
> Release notes for Koha new versions and maintenance versions are build
> automatically based on Git repository commits and Bugzilla info. A script 
> named
> get_bugs.pl from release tools do the job.
>
> In the release notes, 4 info from BZ are used:
>
> - bug id
> - summary -- short description of the bug
> - component: equivalent of Koha module (Acquisition, Web Service, etc.)
> - severity: critic, normal, new feature, etc.
>
> A fifth info can be retrieved in order to describe in detail the bug/feature.
> This is just the first BZ comment. The first comment can't be changed later in
> BZ. So very often the 1st comment doesn't describe properly the bug.
>
> In order to improve the readability and usefulness of release notes, couldn't
> we:
>
> - Try to normalize and improve the bug summary field when the patch is pushed
>   to master
>
> - Add an optional BZ custom field named releasenotes for example, which would
>   contains useful info describing the bug in detail when necessary.
> ___
> 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/

[Koha-devel] Can the file misc/maintenance/fix_accountlines_date.pl be removed? (Bug 15076)

[Marc Véron]

Hi all

Following bug is "In Discussion":
Bug 15076 - Remove file misc/maintenance/fix_accountlines_date.pl

Is the file still in use by anybody or can it be removed?

Thanks for comments on
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15076

Marc




___
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/

Re: [Koha-devel] IMPORTANT: Global Bug Squashing Week

[Marc Véron]

  
  
Hi Tomas,

I have an account on trello.com.

How to join the board?

Marc


Am 03.11.2015 um 15:35 schrieb Tomas
  Cohen Arazi:


  Hi everyone, this is just a reminder for those
interested on spending time fixing bugs for the release that
join us on the Trello board and/or contact me or any other QA
team member so we join forces to fix the small remaining issues
for the release.
  
2015-11-01 22:52 GMT-03:00 Tomas Cohen
  Arazi :
  
Hi everyone, I'm sorry I missed to send this
  email earlier. I have set a Trello board for managing the
  team-work to have the bugfixes we need for the upcoming
  3.22 release.
  
  
  There are several minor ones, but also a couple nasty
ones (Plack-related).
  
  
  The point is to work together on those, have a fluent
communication on what are we doing, and most important,
have fun while we do important things for the release.
Video conference sessions if we need them, discussions
about a specific bug solution on IRC. Whatever you find
useful.
  
  
  For using the Trello board, you need to have access
to Trello (you need to sign into an account). But it is
not different than what you can see in bugzilla. Only
categorized by priority (set by participants) and with
information about who is doing what at a given time. If
you think something needs to have higher priority, just
say so. If you want to work on a bug, but don't want to
join the propietary Trello, just tell me you are working
on that bug, so I mark it on the board and others know,
and spend time on another bugs.
  


Please help Koha, and join us!
The Koha development team



-- 

  
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
  ✆ +54 9351 3513384
  GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1
  B2F3 C15F
  

  

  





-- 

  
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
  ✆ +54 9351 3513384
  GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
  

  
  
  
  
  ___
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/

Re: [Koha-devel] Cataloguer's info in MARC field

[Marc Véron]

Hi Katrin,

I filed a Bug:
Bug 14941 - Subfield defaults: Add information about substitutable values

Marc



Am 02.10.2015 um 08:38 schrieb Katrin Fischer:
> Hi Marc,
>
> documenting this is definitely a good idea. :) An explanation on the
> help page and maybe a short hint about the existance of placeholders on
> the form?
>
> Katrin
>
> Am 29.09.2015 um 08:03 schrieb Marc Véron:
>> Hi Katrin,
>>
>> I tested as well on some subfields, it worked fine with 'user'.
>>
>> Bug 7045 mentions more replaceable strings: , MM and DD
>>
>> I successfully tested with 'user DD-MM-', resulting in something like:
>> testuser 29-09-2015
>>
>> However I do not find any documentation about the replaceable strings, I
>> would expect it at the following place:
>> http://manual.koha-community.org/3.20/en/catadmin.html#marcbibframeworks
>>
>> Additionally, it might be helpful to have a hint on the edit form for
>> subfields, near "Default value", what do you think?
>>
>> Marc
>>
>>
>>
>> Am 28.09.2015 um 23:26 schrieb Katrin Fischer:
>>> Hi,
>>>
>>> there is a somewhat hidden feature you could use, described on bug 7045:
>>> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7045
>>>
>>> If you add 'user' as the default value for a subfield in your
>>> bibliographic frameworks, the field will be automatically filled with
>>> the staff user's surname. I just tested it - it still works on current
>>> master, but probably needs a bit more testing.
>>>
>>> Hope this helps,
>>>
>>> Katrin
>>>
>>> Am 22.09.2015 um 09:34 schrieb akafortes:
>>>> Hello, 
>>>> is it possible to get the username of the logged in user and use it in a
>>>> MARC field? 
>>>> I would like to add a field where I keep info about who catalogued a 
>>>> record.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: 
>>>> http://koha.1045719.n5.nabble.com/Cataloguer-s-info-in-MARC-field-tp5854171.html
>>>> Sent from the Koha-devel mailing list archive at Nabble.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/
>>>
>> ___
>> 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/
>

___
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/

Re: [Koha-devel] Issue tracker for koha-qa.pl tool

[Marc Véron]

I vote for 4) - for the same reason.


Am 28.09.2015 um 23:31 schrieb Katrin Fischer:
> I'd vote 4) - mostly for the reason of 'not yet another account
> somewhere' and to have all things Koha in one place.
>
> Am 28.09.2015 um 22:43 schrieb Mason James:
>> Hi Folks
>>
>> Jonathan and I are planning to use an bug/issue tracker for the
>> koha-qa.pl tool
>> We thought it would be a good idea to get some opinions from other Koha
>> developers, on which tracker to use
>>
>> here is the list we currently have...
>>
>> 1/ use github.com
>> 2/ use gitlab.com
>> 3/ use a KC.org gitlab server (can someone provide a 2gig server?)
>> 4/ use current KC.org bugzilla
>> 6/ something else...?
>>
>>
>> any opinions?
>>
>> Mason
>> ___
>> 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/
>

___
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/

Re: [Koha-devel] Cataloguer's info in MARC field

[Marc Véron]

Hi Katrin,

I tested as well on some subfields, it worked fine with 'user'.

Bug 7045 mentions more replaceable strings: , MM and DD

I successfully tested with 'user DD-MM-', resulting in something like:
testuser 29-09-2015

However I do not find any documentation about the replaceable strings, I
would expect it at the following place:
http://manual.koha-community.org/3.20/en/catadmin.html#marcbibframeworks

Additionally, it might be helpful to have a hint on the edit form for
subfields, near "Default value", what do you think?

Marc



Am 28.09.2015 um 23:26 schrieb Katrin Fischer:
> Hi,
>
> there is a somewhat hidden feature you could use, described on bug 7045:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7045
>
> If you add 'user' as the default value for a subfield in your
> bibliographic frameworks, the field will be automatically filled with
> the staff user's surname. I just tested it - it still works on current
> master, but probably needs a bit more testing.
>
> Hope this helps,
>
> Katrin
>
> Am 22.09.2015 um 09:34 schrieb akafortes:
>> Hello, 
>> is it possible to get the username of the logged in user and use it in a
>> MARC field? 
>> I would like to add a field where I keep info about who catalogued a record.
>>
>>
>>
>> --
>> View this message in context: 
>> http://koha.1045719.n5.nabble.com/Cataloguer-s-info-in-MARC-field-tp5854171.html
>> Sent from the Koha-devel mailing list archive at Nabble.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/
>

___
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/

Re: [Koha-devel] Facilitate integration of some patches

[Marc Véron]

+1 for Jonathan's proposition

Marc

Am 31.08.2015 um 07:41 schrieb Katrin Fischer:
> I'd be ok testing Jonathan's suggestion of moving to Passed QA directly
> for for bugs with'string change' or 'trivial' complexity.
> QA and RM could still reset to 'Needs signoff' for a second opinion when
> they feel it's needed.
>
> I think the patch complexity can only be set after developing a patch -
> so making it mandatory might not work as a technical solution here.
> Maybe we can encourage the use of the field a bit more?
>
> Currently for most of the patches in the 'Needs Sign-off' queue the
> patch complexity is not set - so it's hard to tell how many patches this
> change would affect.
>
> Katrin
>
> Am 25.08.2015 um 14:57 schrieb Fridolin SOMERS:
>> +1
>>
>> On those 200, how many have a severity of trivial or lower ?
>>
>> Le 20/08/2015 15:51, Jonathan Druart a écrit :
>>> Hello devs,
>>>
>>> I would like to suggest a simplification of the integration workflow
>>> for some patches.
>>> Indeed the signoff queue is back to a critical threshold (200) and the
>>> signoffer's activity is very low.
>>>
>>> Being part of the QA team, I try not to test patches in the Needs
>>> Signoff queue as I loose my QA token.
>>> The active members of the QA team are very limited and when we do SO,
>>> this increase the QA queue.
>>> As a result there is less chances my patches are QAed as there are
>>> more and more patches in the QA queue. It's a bit egoistic, but we all
>>> have the same problem.
>>>
>>> So I suggest that for some patches, the ones with a minor severity,
>>> small or template changes could, IMO, bypass the signoff step.
>>>
>>> I would like to discuss this during the next dev meetings, but I am
>>> keen to get some feedbacks on this idea.
>>>
>>> Cheers,
>>> Jonathan
>>>
>>> PS: If I am correct, we already have discussed about that previously.
>>> ___
>>> 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/
>

___
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/

Re: [Koha-devel] Staff: duplicate an item

[Marc Véron]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7369

Status Passed QA 2015-04-10 14:34:30 UTC

Regards
Marc


Am 31.07.2015 um 23:21 schrieb Paul A:
 I seem to remember (but cannot find) a suggestion? enhancement? to allow
 cataloguers to duplicate an existing *item*, in the same way that it can
 be done for biblios Edit as new (duplicate).

 Could some kind soul please point me to any work that has been done on
 this?

 Many thanks and regards,
 Paul


 ___
 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/

Re: [Koha-devel] Koha Hackfest in Berlin?

[Marc Véron]

Hi Mirko,

It is a great idea to have a Koha Hackfest in Berlin in July 2016 and I
would like to join.

Marc Véron
www.koha-support.ch

Am 09.07.2015 um 00:25 schrieb Mirko Tietgen:
 Hello there, European (and other) Koha devs,

 I am considering hosting a Koha hackfest in Berlin/ Germany next year.

 It is not supposed to be a counter event to the Hackfest in
 Marseille nor the Kohacon, but an additional option to meet and work
 together. It could maybe take place July 2016 (very preliminary date
 for very preliminary planning), maybe 3 days or the whole week.

 Before I spend more time fantasizing about it, I'd like your opinion…

 - do you think it is a good idea (and you would consider joining)?
 - do you think it is a good idea (but you know you won't join)?
 - do you think it is not a good idea (given there is a Hackfest in
 Marseille and Kohacon already, or for other reasons)?
 - do you think you would have to decide between Berlin and Marseille?
 - do you think something completely different?

 No hard feelings if you say Kohacon + Marseille is enough, that
 would be very valuable feedback.

 For obvious reasons I would love to hear opinions from Europe
 (positive or negative), but if coming to Berlin is an option for
 people from more distant places, I'd love to hear that too.

 Cheers,

 Mirko


 --

 Mirko Tietgen
 mi...@abunchofthings.net
 http://koha.abunchofthings.net
 http://meinkoha.de
(...)
___
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/

Re: [Koha-devel] getFrameworkLanguages

[Marc Véron]

That is really a great idea!

--Marc

Am 28.05.2015 um 17:08 schrieb Barton Chittenden:
 I mentioned this in #koha a few weeks ago, but this seems like a perfect
 place to bring it up again:

 http://devblog.nestoria.com/post/115930183873/tombstones-for-dead-code

 Essentially, this is a method for adding executable markers near code
 that you want to remove. If you look for the results of the markers, and
 never find them, you know that the code has never been called, and is
 safe to remove (watch the video for discussion of a few subtle points)

 --Barton

 On Thu, May 28, 2015 at 10:35 AM, Tomas Cohen Arazi
 tomasco...@gmail.com mailto:tomasco...@gmail.com wrote:

 We have dead code in lots of places. A cleanup is not a bad idea,
 but we should be careful with API changes because someone could be
 using it. I didn't spend time on looking at the code. We can add it
 to the agentda for the meeting.

(...)
___
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/

Re: [Koha-devel] staff member responsible of loan/renewal recorded in issues?

[Marc Véron]

Hi Giuseppe,

Go to:
Home  Tools  Log Viewer

Select Modules  Circulation

Regards,

Marc

___
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/

Re: [Koha-devel] Another bug status

[Marc Véron]

I agree with Mirko that we should have clear rules.

That's what I found on the Wiki:

I think that the Status In discussion should be used as it was outlined
when it was introduced, see:
http://wiki.koha-community.org/wiki/Bug_and_Enhancement_Discussion

---Snip
Sometimes, patches or bugs requires some strategic discussion to define
the best way to do something. This discussion can be purely technical, or
functional.
---End Snip

Issues that are not on a strategic level should not go to In discussion.

The possibilities we have right now to switch away from Need Signoff are
outlined in the Wiki page Development workflow, see:
http://wiki.koha-community.org/wiki/Development_workflow

---Snip
Failure cases
1.if the 'patch signer' can't test the patch because it does not apply
anymore, the status is set to Patch doesn't apply
2.if the 'patch signer' can apply the patch but after some tests sees
that there is a functional problem with the patch, the status is set to In
Discussion or Failed QA, depending on the kind of the problem the tester
has detected. The description from the tester must be as detailed as
possible to be able to reproduce the failure.
3.if the 'QA manager' has some objections during the QA process, the
status is set to Failed QA
(...)
---End Snip

And I agree with Katrin that it would be logical to have an additional
status as Kyle suggested.

I would prefer to call it Signoff in process instead of Failed
signoff, because it could cover all the minor things on technical (not
strategic) level, e.g. little code glitches, questions, hints,
suggestions, things that could be fixed in a follow up etc. 
In short, it would be something between 'about to fail' and 'about to be
saved'  :-)

The possibilities to switch away from Signoff in process would be:
- Needs Signoff (minor things resolved, questions answered  etc., ready to
sign off)
- Failed QA (No reaction of author within a certain time, code glitches
turn out to be bigger issues...)
- In Discussion (for strategical issues / discussions only)

The longer I ponder about it the more I think that such a status would be
a good tool to streamline the whole bug work flow.






___
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/

Re: [Koha-devel] Any bugs you want worked on?

[Marc Véron]

I tagged
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12702
and
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10177

Marc
___
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/

Re: [Koha-devel] Fwd: Streamlining frontend development in Koha

[Marc Véron]

It would be great to have the possibility to reorder substitutions like
proposed:

_$(You have checked out $1 books, $2 of which are on hold, X, Y)

Marc


Am 24.11.2014 19:51, schrieb Jesse:
 Okay, thanks. That does seem to solve part of the problem. I notice
 that the code doesn't allow translators to reorder substitutions; is
 that not a major issue?

___
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] Sign-off request for Bug 12162 - Add class=branchcode to body tag to make OPAC CSS-styleable per branch

[Marc Véron]

Hi Koha community,

A couple of weeks ago I submitted a patch that makes the OPAC
CSS-styleable per branch:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12162

It would be great if somebody would have time to for a sign-off.

Thanks and regards

Marc
___
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/

Re: [Koha-devel] RFC for overdue notice enhancements

[Marc Véron]

Great tool, would be nice to have it linked on
http://dashboard.koha-community.org/

Marc

Am 20.08.2014 07:46, schrieb Renvoize, Martin:

 You might want to check out http://splitter.koha-community.org for bugs
 touching the same files that are already in the works.



___
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/

Re: [Koha-devel] Git tip of the day: taille de tabulation dans git diff

[Marc Véron]

Tips and hints are always welcome :-)

Marc

 Am 08.08.2014 10:45, schrieb Julian Maurice:
 Le 08/08/2014 10:43, Julian Maurice a écrit :
 Dans bokeh on a souvent du code aligné avec des tabulations, par exemple:

 $exemplaires = Class_Exemplaire::findAllBy(['id_notice' = $id_notice,
  'id_int_bib' =
 $this-id_int_bib,
  'code_barres' =
 $ex['code_barres']]);


 Comme la taille de tabulation dans nos éditeurs est de 2 et que par
 défaut dans git diff, elle est de 8, on doit souvent scroller à droite
 pour voir tout le code.

 Pour éviter ça, et dire à git d'afficher des tabs de 2:

  git config core.pager 'less -x2'

 (peut aussi se faire avec la variable d'environnement LESS à priori)


 Oops, sorry! Wrong email address :)


___
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/

Re: [Koha-devel] Removal of the prog and CCSR themes in 3.18

[Marc Véron]

+1 for removal

Marc

---

marc veron ag informatik information internet
Baslerstrasse 50
CH - 4123 Allschwil

+41 61 483 84 61

www.veron.ch

Acrobat / PDF - Lösungen seit 1995
Partner für Internet und Content Management
Mitglied Koha Support Schweiz www.koha-support.ch



Am 12.05.2014 22:46, schrieb Chris Cormack:
 +1 from me
 
 
 
 ___
 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/

Re: [Koha-devel] DataTables - using class names in aTargets

[Marc Véron]

+1

Marc Véron

Am 26.02.2014 23:35, schrieb David Cook:
 +1
 
 -Original Message-
 Date: Tue, 25 Feb 2014 09:34:55 -0800
 From: Galen Charlton g...@esilibrary.com
 To: koha-devel@lists.koha-community.org
   koha-devel@lists.koha-community.org
 Subject: [Koha-devel] DataTables - using class names in aTargets
 Message-ID:
   CAPLnt64r5EfNogfH2Q=_RWux=f3e9bualos5ggnft_fkrqq...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hi,
 
 There have been a fair number of bugs filed for fixing table sorting as
 columns get added to or removed from tables.  At root, they stem from our
 current habit of referring to columns by numeric position in aoColumns and
 aoColumnDefs/aTargets, e.g.,
 
 { aTargets: [ 1, 2 ], sType: natural  }
 
 and
 
 aoColumns: [
 { sType: title-string },{ sType: html },null,{
 sType: title-string },null,null,null,null,null,null[% IF (
 exports_enabled ) %],null[% END %]
 ],
 
 However, the documentation for DataTables says that aTargets doesn't have to
 be just an array of integers; it can also be a string - class name will be
 matched on the TH for the column.
 
 To reduce the risk of silly columns-sorting bugs, I suggest that we adopt a
 practice of using descriptive CSS class names for table headers and using
 the class names in aoColumnsDefs/aTarget specifications, and dropping the
 use of aoColumns.
 
 Thoughts?
 
 Regards,
 
 Galen
 --
 Galen Charlton
 Manager of Implementation
 Equinox Software, Inc. / The Open Source Experts
 email:  g...@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/
 
___
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/

Re: [Koha-devel] need help in error in koha 3.6.4

[Marc Véron]

Hi,

NoZebra is deprecated since 3.4.0

See e.g.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7440

http://lists.katipo.co.nz/public/koha/2011-April/028711.html

Current Koha Version is 3.10

HTH
Marc



Am 08.01.2013 19:34, schrieb Mohamed zalabany:

hi all
i have system running on koha 3.6.4 with no zebra
suddenly message appear when we are saving bib records

the message


  Software error:

Can't call method as_usmarc on an undefined value at 
/usr/share/koha/lib/C4/Search.pm line 2524.

did any one faced this error before

i need to solve this problem

thanks for your help




Mohamed El Zalabany
Integrated library systems consultant

*
*mh_zalab...@hotmail.com
Mobile: 0111291444



___
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/

Re: [Koha-devel] About bug 5634 - Ordering branches should be case independent

[Marc Véron]

I did a search for scrolling_list on current master and found 79 hits in 
34 files:


acqui\fetch_sort_dropbox.pl
admin\aqplan.pl
admin\authorised_values.pl
admin\auth_subfields_structure.pl
admin\auth_tag_structure.pl
admin\koha2marclinks.pl
admin\marctagstructure.pl
admin\marc_subfields_structure.pl
authorities\authorities.pl
C4\Input.pm
C4\Items.pm
C4\Reports.pm
catalogue\labeledMARCdetail.pl
cataloguing\addbiblio.pl
cataloguing\additem.pl
cataloguing\value_builder\marc21_linking_section.pl
cataloguing\value_builder\unimarc_field_225a.pl
cataloguing\value_builder\unimarc_field_4XX.pl
circ\circulation.pl
members\memberentry.pl
reports\acquisitions_stats.pl
reports\borrowers_out.pl
reports\borrowers_stats.pl
reports\catalogue_stats.pl
reports\cat_issues_top.pl
reports\guided_reports.pl
reports\issues_avg_stats.pl
reports\issues_by_borrower_category.plugin
reports\issues_stats.pl
reports\itemtypes.plugin
reports\reserves_stats.pl
reports\serials_stats.pl
reserve\request.pl
tools\batchMod.pl


Marc


Am 09.01.2013 00:30, schrieb Chris Cormack:



Bernardo Gonzalez Kriegel bgkrie...@gmail.com wrote:


Hi,
I've been studying the code to hopefully find (and eventually fix)
all occurrences of code to display an ordered list of branches,
to close Bug 5634 [1]

There is a zoo of different versions, so I have some questions:

1) It's desirable to change the code to use GetBranchesLoop()
whenever possible, or only fix the sort order in place?

2) Some solutions use CGI::scrolling_list() to draw the drop down list.
This simplifies the template, but is more code in the script.
Which version do you think is better?


CGI::scrolling_list should be removed wherever it is found, it renders the 
contents untranslatable.

Chris


Regards,
Bernardo

[1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5634


___
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/

Re: [Koha-devel] using new templates for exporting basketgroups in pdf

[Marc Véron]

Mathieu,

I think this is worth to open a bug / enhancement.

Regards

Marc




Am 04.01.2013 10:17, schrieb Mathieu Saby:

Happy new year everybody!
Last month I asked a question regarding pdf templates for basketgroups,
but nobody answered.
So I reformulate :-)

Pdf templates are untranslatable, and the 2 defaut layouts is not
convenient at all for our library. So we want to define our own template.
I have done the job, but I can not activate it in system preferences
without removing some lines in /acqui/basketgroup.pl.
So, do you think it would be a good idea to give libraries the ability to
define their own templates? And what would be the best solution for that :
removing these lines in /acqui/basketgroup.pl, or creating a more flexible
security (I don't now how...)?


Regards,
M. Saby
Rennes 2 university


Mathieu Saby a écrit :

Hello

Our library has created a new templates for  exporting basketgroups in
pdf  (translated in french, and showing fields more usefull for us in
the tables than layout2pages and layout3pages).
Of course, we could name this template layout3pages, and replace the
standard template. But I think it would be cleaner to add this give
this new template a name of his own, so it won't be altered when our
Koha is updated.

The problem is some code in /acqui/basketgroup.pl prevents us to do
that. The only 2 valid templates for exporting basketgroups in pdf are
be layout2pages and layout3pages. And we want to edit perl files as
less as possible.
http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=acqui/basketgroup.pl;h=6b7e5bf192a7b5cfa6761dc750bfc9fe5904bf60;hb=HEAD

188 if ($pdfformat eq 'pdfformat::layout3pages' || $pdfformat eq
'pdfformat::layout2pages'){
189 eval {
190 eval require $pdfformat;
191 import $pdfformat;
192 };
193 if ($@){
194 }
195 }
196 else {
197 print $input-header; 198 print $input-start_html;
# FIXME Should do a nicer page
199 print h1Invalid PDF Format set/h1;
200 print Please go to the systempreferences and set a valid
pdfformat;
201 exit;
202 }

This code was added by this Chris Cormack's commit :  Bug 6679 Fix
scripts in admin  acqui to pass Perl::Critic
http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=7cdea5de355e853f25300821cc641672443177de
added

So, here is my question :
Is this security in code really necessary ? And if it is, is there a
way to make it more flexible ?


Regards,

M. Saby
Rennes 2 University





___
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/

Re: [Koha-devel] Reminder: Patrons (good), borrowers (maybe), members (no!)

[Marc Véron]

MJ,

My opinion is that it is worth to file a bug. We should try to get 
consistent wording. It makes live easiar for users - and for translators :-)



Marc Véron

marc veron ag informatik information internet
www.veron.ch





Am 14.12.2012 00:38, schrieb MJ Ray:

I was working on a patch and I noticed that I was using borrower in
the text, but the file I was editing used member more often.  So I
then asked myself which I should use.

Should I use member or borrower?

And it turns out the answer is no, probably not.  It should say
patron!

See the coding guideline
http://wiki.koha-community.org/wiki/Coding_Guidelines#PERL7:_Definitions
which includes
  * We have decided to use [ODLIS].

http://www.abc-clio.com/ODLIS/odlis_p.aspx#patron defines Patron as
Any person who uses the resources and services of a library, not
necessarily a registered borrower. Synonymous with user. Compare with
client.

http://www.abc-clio.com/ODLIS/odlis_b.aspx#borrower defines Borrower as
A person who checks out books and other materials from a library.

ODLIS isn't big on member.

At the moment, the templates have about 1250 hits for patron, 800 for
borrower and 400 for member.  Those later two numbers will never get
to zero, as both terms are used in links and variable names, as well
as the text (for example, the borrowernumber query string to various
scripts in the members folder).

But it would be really lovely if we could keep using Patron in the
text, please.  Should I open a bug for this?

Thanks,


___
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/

Re: [Koha-devel] Bugzilla change proposal

[Marc Véron]

Am 15.11.2012 17:49, schrieb Paul Poulain:

 What about adding separating enhancements in enhancement (of an
 existing feature) and New feature by adding the new feature to
 severity list ?
 The script generating release notes would be trivial to update to
 reflect that. Of course that would not be for 3.10, but 3.12+

Good idea!

+1

Marc Véron
www.veron.ch




___
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/

Re: [Koha-devel] Some thoughts from QA team

[Marc Véron]

Hi all,

I agree with Katrin in both points.

Marc V.



Am 24.10.2012 16:53, schrieb Fischer, Katrin:

Hi all,

I think so far we have a lot of votes for keeping the discussion on the
Koha developer mailing list so it looks to me like this is what we should
do. Also a +1 from me. I think Mirko made a good point that it is
interesting for all developers to know how the QA team works.

On another note - maybe it's time to clean up our scattered mailing lists
a bit? I didn't even know koha-zebra existed and I might not be alone in
that. If it's mostly people asking for installation help there, it's maybe
worth to fold back into the main Koha mailing list as more people helping
out are subscribed there.

Katrin


___
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/

Re: [Koha-devel] Default search options in the OPAC

[Marc Véron]

Hi all,

I agree with Katrin that we should have the possibility to localize the 
HTML system preferences.


Marc



Am 08.10.2012 13:42, schrieb Fischer, Katrin:

Hi all,

I am sorry, but there is a big problem with that solution as suggested.
The search options won't be translatable and only available in one 
language at a time.
I think what we really need is a way to have all the HTML system 
preferences in an editor

like we have for news that supports content for multiple languages.


Katrin



-Original Message-
From: koha-devel-boun...@lists.koha-community.org [mailto:koha-devel-
boun...@lists.koha-community.org] On Behalf Of Kyle Hall
Sent: Monday, October 08, 2012 1:38 PM
To: Magnus Enger
Cc: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Default search options in the OPAC

I agree, this seems like a good option. The only thing I could imagine
that would make it better would be to add a new section under
administration to define these choices so we don't require librarians to
be messing around with html. Perhaps I'm trying to make it overly
complicated though ; )

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 Mon, Oct 8, 2012 at 3:52 AM, Magnus Enger mag...@enger.priv.no
wrote:

On 18 September 2012 15:58, Owen Leonard oleon...@myacpl.org wrote:

We've now got two patches pending which seek to add more options to
the default OPAC search, the masthead search bar which currently
includes options for Library catalog, title, author, subject, ISBN,
series, and call number:

Add Phrase Searching to OPAC Search
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8778

Add accesssion [barcode] number to the drop down list in OPAC Search
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8302

I'll say right out that I'm opposed to these changes, but I want to
bring it up here on the list so we can discuss.


I agree that the simple search should be simple. But we could probably
spend a lot of time arguing about how simple is simple enough.

Seems to me that it would be better to find a way to make this easily
configurable. I'd like to suggest a simple solution:

In the template, we could have

select id=masthead_search class=left name=idx [%
OPACSearchOptions %] /select

Then we could have a syspref called OPACSearchOptions (or something),
with this initial content:

option value=Library catalog/option option
value=tiTitle/option option value=auAuthor/option option
value=suSubject/option option value=nbISBN/option option
value=seSeries/option option value=callnumCall
number/option

This would keep current behaviour, but make it easy to add or remove
or re-arrange the option elements. And we could explain in the docs
or on the wiki how the values here relate to indexes defined in more
or less obscure config files.

Yes, it would require fiddling with HTML and Zebra (or Solr) indexes
to change it. No, it would not be GUI and pretty. But it would be so
simple, even I could submit a patch for it.

Thoughts?

Best regards,
Magnus
libriotech.no
___
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/



___
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/

Re: [Koha-devel] OPAC themes

[Marc Véron]

Two browser compatibility test sites I am aware of:

http://browsershots.org/

http://netrenderer.com/


Regards

Marc Véron


Am 05.10.2012 13:26, schrieb MJ Ray:

and, bootstrap has great backwards compatibility
  - http://github.com/twitter/bootstrap/wiki/Browser-Compatibility


Only works on OS X and Windows??? And Firefox  5?  I'm pretty
sure we've lots of Linux users, probably some tablets and mobiles
and probably still Firefox 3.x versions out there.

I think this needs some pre-inclusion testing.  I'm happy to point
whatever browsers I can at test sites if anyone's got some?
Collect results on wiki.koha-community.org?

My experience has been that many of the supposedly-responsive grid
systems fail on mobile or non-JS devices.  It'd be good to crack this
right first time.

Thanks,


___
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] Bug 4177 (opaccloud) - Dead feature / dead code? - Releted to French catalogs.

[Marc Véron]

Bug 4177 is still marked as New. Last activity 2011-08-23

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4177

It is related to French catalogs.

Is this feature still functional?

If not, we could remove dead code and set it to RESOLVED.

Comments welcome...

Marc





___
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/

Re: [Koha-devel] Problems with suggestions

[Marc Véron]

+1 for having a preference

Marc

___
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] Fwd: Re: Bug Numbers in Update Database

[Marc Véron]

Can we start putting our bug references in our updates?


+1

This rule should be written down somewhere in the Wiki.
But where?

Marc



___
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/

Re: [Koha-devel] Default search options in the OPAC

[Marc Véron]

Am 18.09.2012 18:27, schrieb Owen Leonard:


- Is it a (mostly-) common goal that the OPAC default search options
be simple and few?


This patch just expands the choice in the drop down list from 7 to 8 
options (), and the meaning of the additional choice is clear. I do not 
think that users will get lost in complexity with this additional choice.


I signed off because somebody seems to need this additional option - 
otherwise no patch would have been submitted.



- If not, should the solution be something more structured than
javascript-based customizations?


Agree - but this is something that could easily be done for a future 
release, e.g. some syspref setting where you can choose what to display in 
the search options.


Marc
___
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/