Bug 7392 - Add system preference to configure export options for OPAC detail page
Summary: Add system preference to configure export options for OPAC detail page
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: 3.8
Hardware: All All
: P3 enhancement
Assignee: Katrin Fischer
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on: 7345
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-01 13:19 UTC by Katrin Fischer
Modified: 2013-12-05 20:04 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 7392: Add system preference to define export options in OPAC (20.66 KB, patch)
2012-01-01 13:21 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 7392: Add system preference to define export options in OPAC (20.66 KB, patch)
2012-01-01 13:29 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 7392: Add system preference to define export options in OPAC (20.75 KB, patch)
2012-01-01 13:55 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 7392: Add system preference to define export options in OPAC (20.78 KB, patch)
2012-01-14 17:24 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 7392: Follow-up (2.38 KB, patch)
2012-01-14 17:24 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 7392: Follow-up (2.48 KB, patch)
2012-01-14 17:40 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
[SIGNED-OFF][REBASED] Add syspref to define export options in OPAC (21.40 KB, patch)
2012-01-16 12:20 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Second followup for pref description (2.16 KB, patch)
2012-01-16 12:22 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 7345: Follow up: Adding the new export option to staff interface (22.14 KB, patch)
2012-02-10 18:54 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Rebased patch (21.06 KB, patch)
2012-02-13 07:50 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Follow-up 1 (2.48 KB, patch)
2012-02-13 07:51 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Follow-up 2 (2.12 KB, patch)
2012-02-13 07:53 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Follow up 3 for marcstd typo (1.58 KB, patch)
2012-02-13 11:32 UTC, Marcel de Rooy
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 7302: Followup: rename "Client number" column with "Account number" (2.12 KB, patch)
2012-06-17 19:34 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2012-01-01 13:19:43 UTC

    
Comment 1 Katrin Fischer 2012-01-01 13:21:10 UTC Comment hidden (obsolete)
Comment 2 Katrin Fischer 2012-01-01 13:29:20 UTC Comment hidden (obsolete)
Comment 3 Jared Camins-Esakov 2012-01-01 13:55:43 UTC Comment hidden (obsolete)
Comment 4 Marcel de Rooy 2012-01-13 18:09:04 UTC
Copy-and-paste qa comment ;) along with Katrin's response already (see 7345 where this mixup started..)

Hi Marcel,

thx for testing this :)

>In the pref file I find a template variable:
>Use the CSS stylesheet [% opacthemelang %]/css/ This does not work here.

I changed that from the old template syntax to TT - so it probably never
worked. Not sure how to make it work? I can take the line change out - but it
will still be broken.

>OpacExportOptions: It does not really read comfortable in the Preferences
>screen. All options exceed the length of the field. Could you extend the field,
>make it better readable (new line)? [Is no blocker but a design thing..]

It seems the appearance of the field is determined by the type you give in the
pref file. I am not sure there is a better type we can use here. The only other
option seems to be a box like we use for OpacUserCSS and others?

>MARC standard is promised but not delivered yet (while pending on other
>report). Does not block this, but you could move it to the report it belongs.

I have marked both bugs as dependent on each other. The only thing keeping 7392
from being pushed is the missing presence in the GUI. So I thought I would look
into it and it turned into a new feature, going beyond a simple follow-up.

>Just a thought: If you add an unexisting format, it now comes in the list and
>you will have an error message on screen. Would it be interesting to exclude
>these formats (question with some doubts on my part too)..

I can make them not show up - that's probably the easiest way to solve this.
Comment 5 Marcel de Rooy 2012-01-13 18:16:12 UTC
(In reply to comment #4)
> I changed that from the old template syntax to TT - so it probably never
> worked. Not sure how to make it work? I can take the line change out - but it
> will still be broken.
I suggest that you still edit this line, but you could describe something like css subfolder in the templates themelanguage subfolder blabla..

> It seems the appearance of the field is determined by the type you give in the
> pref file. I am not sure there is a better type we can use here. The only other
> option seems to be a box like we use for OpacUserCSS and others?
Don't touch it then. We could leave it to the design experts to adjust with a follow-up. 

> I can make them not show up - that's probably the easiest way to solve this.
Well, if you could make a small adjustment for that now, please do..
Looking forward to the new patch. THANKS.
Comment 6 Katrin Fischer 2012-01-14 17:24:31 UTC Comment hidden (obsolete)
Comment 7 Katrin Fischer 2012-01-14 17:24:43 UTC Comment hidden (obsolete)
Comment 8 Jared Camins-Esakov 2012-01-14 17:40:24 UTC Comment hidden (obsolete)
Comment 9 Marcel de Rooy 2012-01-16 12:20:18 UTC Comment hidden (obsolete)
Comment 10 Marcel de Rooy 2012-01-16 12:22:23 UTC Comment hidden (obsolete)
Comment 11 Marcel de Rooy 2012-01-16 12:24:39 UTC
QA Comment:
Requested points have been incorporated. I added a textual change to get the descriptions for two opac css sysprefs in line with each other.
Updating patch status.
Comment 12 Paul Poulain 2012-02-10 18:05:21 UTC
Sorry, still does not work. When trying to apply the [SIGNED-OFF][REBASED] Add syspref to define export options in OPAC, I get a nasty:
Patch format detection failed.


really sorry...
opening the patch, I see unusal end of line (^M)
Comment 13 Jared Camins-Esakov 2012-02-10 18:54:11 UTC Comment hidden (obsolete)
Comment 14 Marcel de Rooy 2012-02-13 07:23:37 UTC
Something strange happened here with the attachments. Looking at it now!
Comment 15 Marcel de Rooy 2012-02-13 07:50:14 UTC
Created attachment 7608 [details] [review]
Rebased patch
Comment 16 Marcel de Rooy 2012-02-13 07:51:40 UTC
Created attachment 7609 [details] [review]
Follow-up 1
Comment 17 Marcel de Rooy 2012-02-13 07:53:23 UTC
Created attachment 7610 [details] [review]
Follow-up 2
Comment 18 Marcel de Rooy 2012-02-13 07:57:26 UTC
Paul,
I could not find the unusual line. But the last attachment after that had some problems (mixup with 7345). 

But I have rebased the base patch for this report now. That should be pushed first and the two other followups in the given order.
Please consider pushing this report first before another one with a dbrev. It is in the Passed QA already for some time now..
Comment 19 Paul Poulain 2012-02-13 11:11:00 UTC
While testing before pushing those patches, I fall in a problem that either means there's a bug or some documentation is needed.

I switched the syspref to:
bibtex|dc|marcxml|marc8|utf8|marcstd|mods|ris
=> I get the "Save record" list with MARC (non unicode/MARC8) / MARC (Unicode/UTF8) / MARC (Unicode UTF8/Standard)
I can export my record and it includes all 9xx fields (including 995, where the item(s) are)

The I switched the syspref to "empty" = the list disappear on the OPAC, expected behaviour

Then I switched the syspref to:
bibtex|dc|marcxml|marc8|utf8|9xx|mods|ris

Then ...
I understood that the (9xx,x9x, xx9) are not related to the format as are other () in the syspref description

=> i'll do a follow-up before pushing to say

Note: Available options are: BIBTEX (bibtex), Dublin Core (dc), MARCXML (marcxml), MARC-8 encoded MARC (marc8), Unicode/UTF-8 encoded MARC (utf8), Unicode/UTF-8 encoded MARC without local use -9xx, x9x, xx9- fields and subfields (marcstd), MODS (mods), RIS (ris) 

it will be more clear

Then I tried to upload a marcstd record, and got exactly the same result as for utf8 or marcxml record: I get the 995 (item) and the 090(biblionumber) fields as well.
Am I not supposed not to get them ? what am I doing wrong ?
Comment 20 Marcel de Rooy 2012-02-13 11:32:34 UTC
Created attachment 7616 [details] [review]
Follow up 3 for marcstd typo
Comment 21 Paul Poulain 2012-02-13 12:34:59 UTC
Follow-up (comment 20) from marcelr is a consequence of the comment 19, and fixes the problem I rised, and that was confirmed by a discussion on IRC.

This patch has been pushed with the 7345, it can't be found in new/bug_7392 branch, it is in new/bug_7345
Comment 22 Katrin Fischer 2012-06-17 19:34:15 UTC Comment hidden (obsolete)
Comment 23 Katrin Fischer 2012-06-17 19:37:14 UTC
Comment on attachment 10339 [details] [review]
[SIGNED-OFF] Bug 7302: Followup: rename "Client number" column with "Account number"

wrong bug number, sorry!
Comment 24 Jared Camins-Esakov 2012-12-31 01:06:37 UTC
There have been no further reports of problems so I am marking this bug resolved.