Re: [Koha] opac search returned results doesn't show title information

[Katrin Fischer]

Hi Peter,

assuming that your system is set up throughout as UNIMARC (this has to
be set when creating the instance and for the db), I think you might be
seeing this bug:

*Bug 22085*
 -
UNIMARC default XSLT broken by Bug 14716


It will be fixed in 18.11.03

Hope this helps,

Katrin

On 26.01.19 02:27, Peter Zhao wrote:

Hi,

When I upgraded koha17.11 to 18.11 （unimarc）, the opac search returned results 
list doesn't show title information,but  the intranet search returned results 
show very well.
How to solve this problem?
Peter


















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

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

Re: [Koha] Ordering MARC subfields

[Katrin Fischer]

Hi Radek,

it's not possible to set a default sequence of subfields in the
frameworks right now.  There is already a rather old bug report for that:

*Bug 8976*
 -
Default sequence of subfields in cataloguing editor

Hope that helps,

Katrin

On 22.01.19 21:45, Radek Šiman wrote:

Dear colleagues,

we are facing problem with ordering of subfields in some specific MARC fields. 
For example we need to have 787 with subfields having exactly this order: i, t, 
g. And there are several other fields suffering from the same issue like 336 2, 
a, b. Is there a way how to instruct a cataloguing framework to follow the 
given order of subfields? Or, should we file a request for improvement in 
bugzilla?

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

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

Re: [Koha] Holds in Koha 18.11

[Katrin Fischer]

Hi Sonia,

I am not sure if you have received an answer yet, so I'll try:

Holds allowed (total): Number of holds allowed for this library -
itemtype - patron category combination at the same time. The holds can
be item or record level on different records.

Holds allowed (daily): Same as above, but as a daily limit. Like: only
allow placing 5 holds/day (see bug 15486).

Holds per record (count): Number of ITEM LEVEL holds that a patron can
be place on the SAME record at a time. Useful for serials for example
where every item is another volume or issue (see bug 14695). It looks
like in staff that also limits record level holds. There is bug 15565
pending sign-off to allow this for the OPAC as well.

maxreserves is the total total, similar to MaxFine. The maximum number
of holds allowed for a patron independent of the other rules.

I haven't tested it out fully, so maybe someone can weigh in how the
count is done exactly. But I think it for the counts it doesn't matter
if record or item level holds.

Hope it helps,

Katrin


On 17.01.19 09:36, BOUIS Sonia wrote:

Hello,
I want to be sure to understand properly the circulation rules because I 
haven't found the complete information in the manual (perhaps, I haven't looked 
at the good place?)
In the first table of the "Circulation and fines rules" page, we can find this 
three column:
Holds allowed (total)

Holds allowed (daily)

Holds per record (count)

Holds allowed (total): does it mean the maximum of items that could be reserved 
for an itemtype / patron category at once?
Holds allowed (daily): does it mean the number of items that could be reserved 
per day for an itemtype / patron category?
Holds per record (count) : does it mean the maximum of records that could be 
reserved for an itemtype / patron category at once?

What the syspref maxreserves is about ? items or records?
If patrons try to reserve several itemtype and the total of reservation of each 
itemtype is bigger than the maxreserves syspref, would they be blocked when 
they will reach the number of holds put in the syspref?

In the table of the circulation rules : "Default checkout, hold and return policy", does 
the column "Maximum total holds allowed (count)" concern items or records?

In the table "Checkout, hold policy by patron category", it's possible to put a 
limit of holds by category type : is it the number of records or items?

Does Koha always use the lower of the limits for each settings usable?

Thanks in advance,

Cheers,
Sonia







Sonia BOUIS
--
Responsable du Service des applications documentaires
Bibliothèques universitaires
Université Jean Moulin Lyon 3
ADRESSE GÉOGRAPHIQUE > Manufacture des Tabacs | 6 cours Albert Thomas | LYON 8e
ADRESSE POSTALE > Bibliothèque de la Manufacture | 1C avenue des Frères Lumière 
| CS 78242 - 69372 LYON CEDEX 08

Ligne directe : 33 (0)4 78 78 79 03

http://bu.univ-lyon3.fr| Suivez-nous > 
Facebook | Twitter| 
Instagram
---
L'Université Jean Moulin est membre de l'Université de Lyon

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

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

Re: [Koha] opac search returned results doesn't show title

[Peter Zhao]

Hi Katrin,
  Thanks a lot. I fixed the problem with  "Bug 22085".

Peter

>
>Hi Peter,
>
>assuming that your system is set up throughout as UNIMARC (this has to
>be set when creating the instance and for the db), I think you might be
>seeing this bug:
>
>*Bug 22085*
> -
>UNIMARC default XSLT broken by Bug 14716
>
>
>It will be fixed in 18.11.03
>
>Hope this helps,
>
>Katrin
>
>On 26.01.19 02:27, Peter Zhao wrote:
>> Hi,
>>
>> When I upgraded koha17.11 to 18.11 （unimarc）, the opac search returned 
>> results list doesn't show title information,but  the intranet search 
>> returned results show very well.
>> How to solve this problem?
>> Peter


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