Re: [Koha] Enabling self checkout during patron import

2016-10-19 Thread Katrin Fischer
Am 19.10.2016 um 09:12 schrieb Krishna K:
> Hi,
> 
> As part of Koha implementation, I would like to import patrons from the
> current library s/w we are using. We plan to enable self checkout feature
> for all patrons. I am aware of how to enable self checkout from the screen
> for each patron. Is there a way by which I can specify self checkout to be
> enabled for all patrons at the time of import or after importing at the
> patron category level or using some script ?
> 

Hi Krishna,

the 'self_checkout' permission is not needed by the normal patrons, it's
meant for your self checkout librarian user that you can use in
combination with the PatronSelfCheckID and PatronSelfCheckPass
systempreferences.

Normal users don't need any permissions in order to be able to use the
self checkout functionality.

Hope that helps,

Katrin

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


[Koha] What's on in Koha devel #6 - Special post hk16

2016-10-19 Thread Jonathan Druart
Hello librarians and developers,

On the same way as my previous email, I think it would be useful for
everybody to get feedback on what was going on during the hackfest in
Marseille last week.
I plan to send the next "What's on in Koha devel" emails to both koha
and koha-devel lists, if nobody disagrees (someone?).
I think it would be helpful for developers not heavily involved in the
development as well as techie librarians.

Here are the different topics on which the developers have focused
during this hackfest (as far I am aware of!):

= Refactoring =
Thanks to testers and QAers, a lot of things have moved in this area.
Only 2 are waiting for QA and 9 are waiting to be pushed, and lot of
others have been pushed!
I will have to refill our bug tracker with new patches soon :)

Unfortunately the move of the biblioitems.marcxml field to another
table (bug 17196) did not interest anybody. It's however our first
step toward new interesting features and don't necessarily depend on
marc to store the records.

= Elastic search =
The mapping configuration page (bug 14899) have been pushed during
this hackfest alongside some other bug fixes.

A couple of UNIMARC users have submitted a patch for the authority
mappings (bug 17373), now we need a couple of others to validate it!

= Mana =
Morgan presented us Mana and how it would help librarians to share
data (subscriptions infos at the moment but could be extended to
reports for instance), see bug 17373 if you are interested by testing
these patches and/or understanding how it works.

= RESTful API & ReactJS =
The developer team works in the aim to submit a proposal for a full
integration of our RESTful API, from the objects to the templates.
We wanted to work all together on this problematic to show the
community how easy and clean it can be.
That means that we had a lot of passionated and intense discussions,
as you can imagine, to reach a consensus on tiny things (variable's
name) or big architecture problematics to simplify all the stack code.

Basically we tried to get the simplest component as possible (the
Koha::Cities modules and admin/cities.tt template) to make it an
example to follow.
For the RESTful API, all what we have is on bug 17428 (and
dependencies). Yes, we know, it does not look like a lot for a whole
week of work, but we needed to agree ;) The idea of having a small
example gave us enough time to have a look at several things like
exceptions, inconsistencies in our existing implementation, etc.

About ReactJS, Kyle showed us how it could work on a small example
(bug 17297) and then on a more complete example using the RESTful API
endpoints 
(https://github.com/bywatersolutions/bywater-koha-devel/commits/cities_editor)

If you are a developer or interested on this topic you should
definitely have a look at these patches to know what could be the
future of Koha ;)
No decision has been taken so far and everything is here for
discussion and example.

During the next meeting, we will certainly talk about some minor but
important details like "should PUT accept the id in the body". Stay
tunes!


Please complete this list if I forget something!

The next dev meeting is on November 9th and the time has been set to
19UTC but is flexible.
I'd like to try something new and get an answer to this survey:
https://framadate.org/3dAEB8zqQLzzTptD from people wanting to attempt
the dev meetings.
The goal is not to get only 1 time slot but 2, in order to alternate
between them. I repeat, you should only answer if you plan to attempt
dev meetings :)

Cheers,
Jonathan
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


[Koha] Holds and emails question

2016-10-19 Thread Graham, Stephen
Hi All - we've only just implemented holds, we went live 3 weeks ago. One thing 
we are grappling with is books which have holds on, going "missing" before they 
get to the holds shelf. At the moment if a user returns an item via the 
Selfcheck machines,which is on hold for another user, then an email (informing 
the user that their book is ready to collect) is automatically added to the 
message_queue table and then sent when the email cronjob runs. However, the 
user may not actually place the returning item in the holds bin, they may put 
it on the normal return trolley, where some else may take it to read in the 
Library and then anything can happen to it. In cases like these the email has 
already been generated and the book is NOT ready to collect even though we've 
told the user that it is.

This is happening often at the moment, and we are dealing with it in two ways - 
either removing the user's email address from their record, so the email cannot 
be sent, or deleting the message from the table at the SQL level. Neither of 
these are ideal. I'm just wondering how other people are handling this? We have 
two campuses, and when an on-hold item is returned which is for a user at the 
other campus, it goes into transit and the email does not get generated until 
the item is checked in at the other campus. Can the same be achieved with the 
Selfcheck machines? Creating a separate virtual library, adding the self check 
machine users to it, and then books will automatically go into transit, 
therefore the email will not get generated? Do other libraries do this?

Cheers, Stephen
Stephen Graham
Library Technology Consultant
Academic Resources
Library and Computing Services
University of Hertfordshire
Hatfield  AL10 9AB
UK
Tel. 01707 286111 Ext: 77751
Email s.grah...@herts.ac.uk

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


[Koha] Enabling self checkout during patron import

2016-10-19 Thread Krishna K
Hi,

As part of Koha implementation, I would like to import patrons from the
current library s/w we are using. We plan to enable self checkout feature
for all patrons. I am aware of how to enable self checkout from the screen
for each patron. Is there a way by which I can specify self checkout to be
enabled for all patrons at the time of import or after importing at the
patron category level or using some script ?
-- 
Regards,
Krishna
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha