Bug 7680

Summary: Create a PatronDefaultView preference to control whether patron links go to circ or patron details
Product: Koha Reporter: Owen Leonard <oleonard>
Component: System AdministrationAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: fridolin.somers, gmcharlt, jonathan.druart, katrin.fischer, marjorie.barry-vila, patrick.robitaille, paul.poulain, robin, veron
Version: master   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Medium patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 30568, 22279    
Bug Blocks: 6670, 6905, 9255    
Attachments: Bug 7680 - PatronDefaultView preference to control whether patron links go to circ or patron details
Bug 7680 [REVISED] PatronDefaultView preference to control whether patron links go to circ or patron details
Bug 7680 [REVISED] PatronDefaultView preference to control whether patron links go to circ or patron details

Description Owen Leonard 2012-03-08 14:39:48 UTC
Bugs 6670 and 6905 ask that links to patron records take the user to the patron's circulation page instead of the patron detail page. A system preference should be created, PatronDefaultView, allowing the library to choose which view is preferred. Any link which is not explicitly intended for one or the other destination should be controlled by this preference.
Comment 1 Owen Leonard 2012-03-08 17:34:51 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2012-03-08 17:39:11 UTC Comment hidden (obsolete)
Comment 3 Owen Leonard 2012-03-08 18:03:30 UTC
A lot of pages are touched by this patch. Testers, FYI:

catalogue/detail.tt
catalogue/issuehistory.tt
catalogue/moredetail.tt
circ/branchoverdues.tt
circ/branchtransfers.tt
circ/circulation.tt
circ/overdue.tt
circ/returns.tt
circ/transferstoreceive.tt
circ/view_holdsqueue.tt
circ/waitingreserves.tt
members/member-password.tt
members/member.tt
members/memberentrygen.tt
members/moremember-print.tt
members/moremember-receipt.tt
members/moremember.tt
members/update-child.tt
offline_circ/list.tt
offline_circ/process_koc.tt
patroncards/members-search.tt
reports/bor_issues_top.tt
reserve/request.tt
reviews/reviewswaiting.tt
serials/viewalerts.tt
suggestion/suggestion.tt
tools/viewlog.tt
virtualshelves/shelves.tt
Comment 4 Jared Camins-Esakov 2012-03-10 22:22:08 UTC Comment hidden (obsolete)
Comment 5 Ian Walls 2012-03-19 23:52:37 UTC
The two choices presented for this are 'circ' and 'details', but the default value installed is 'normal'. This does universally default to 'details', but when going to the syspref editor for the first time, 'circ' will be selected because it's first.  Best to explicitly say 'circ' or 'details' instead of 'normal'.

Also, are we sure that everyone one of these links should behave the same way?  On the one hand, consistency is nice, but I envision a situation where certain links are used only by certain staff (who want it one way) and other links are used by other staff (who need the opposite functionality).

Not going to mark as failed QA over these issues... but I will ask for someone to address these concerns in a reply before I mark this one as 'ready'.
Comment 6 Owen Leonard 2012-03-20 08:22:14 UTC
> I envision a situation where
> certain links are used only by certain staff (who want it one way) and other
> links are used by other staff (who need the opposite functionality).

I don't think there's a perfect solution here. There's certainly the demand to change this on certain pages, so creating an option seems the best way to handle it. We can't do per-user preferences, so that's off the table pending work to make it possible. Better I think to be able to predict what you'll get.
Comment 7 Paul Poulain 2012-03-28 15:09:06 UTC
sorry, but the patch does not apply anymore because, probably, of some kohaDates plugins updates

CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/moredetail.tt


They are not trivial, I don't want to do something wrong by fixing them myself.

Other QA comment: calling the link patron-default-view.inc is not very intuitive, and I think that we will have problem when we will start building "views" for "objects".
I'd prefer to have it called patron-default-link.inc
Comment 8 Owen Leonard 2012-03-28 15:13:14 UTC
I would be happy to rebase this and make the requested corrections but is there enough consensus that this feature works as everyone thinks it should?
Comment 9 Paul Poulain 2012-04-02 13:37:25 UTC
(In reply to comment #8)
> I would be happy to rebase this and make the requested corrections but is
> there enough consensus that this feature works as everyone thinks it should?

maybe you can switch the status to "in discussion", and start the discussion on mailing lists ?

(to give my opinion = I have none yet)
Comment 10 Marjorie Barry-Vila 2013-10-11 14:52:55 UTC
Hi,
anyone know where is the discussion of this system preference?

Thanks
Marjorie
Comment 11 Fridolin Somers 2013-10-14 12:41:33 UTC
(In reply to Owen Leonard from comment #2)
> The new include, patron-default-view.inc, outputs the *opening* half of
> the <a> so that individual templates can control whether to show
> full name, barcode, both, etc.
In my opinion, it would be better if include contained the full anchor tag. Because templates are hard to read when they are not correct HTML.
You could pass to include the content of the tag : 

[% IF ( PatronDefaultView == 'circ' ) %]
<a href="/cgi-bin/koha/circ/circulation.pl?borrowernumber=[% borrowernumber %]">[% text %]</a>
[% ELSE %]
<a href="/cgi-bin/koha/members/moremember.pl?borrowernumber=[% borrowernumber %]">[% text %]</a>
[% END %]
Comment 12 Owen Leonard 2013-10-14 12:50:57 UTC
I'd be happy to pick this up again if others think it's a good idea (and I think it is). I'd like to hear more opinions though.
Comment 13 Jonathan Druart 2014-05-13 13:17:48 UTC
(In reply to Owen Leonard from comment #12)
> I'd be happy to pick this up again if others think it's a good idea (and I
> think it is). I'd like to hear more opinions though.

I think it is a good idea too.

Given that 4 bug reports are opened, it seems there is a real need here.

see bug 6670, bug 6905 and bug 9255.

Owen, I will be happy to test this patch if you rebase it.
Comment 14 Jonathan Druart 2014-05-13 13:18:26 UTC
*** Bug 6670 has been marked as a duplicate of this bug. ***
Comment 15 Jonathan Druart 2014-05-13 13:19:39 UTC
*** Bug 6905 has been marked as a duplicate of this bug. ***
Comment 16 Jonathan Druart 2014-05-13 13:24:31 UTC
It would be better if the content of the link (patron name) was sent to the include file, as a parameter. But it seems not to be easy.
Comment 17 Jonathan Druart 2014-12-11 13:34:09 UTC
I am still a candidate to SO or QA this patch if rebased :)
Comment 18 Marjorie Barry-Vila 2015-03-24 19:46:45 UTC
Hi,
I asked two years ago but this bug is still under discussion.
Some news about it?

Marjorie
Comment 19 Owen Leonard 2015-03-25 12:10:26 UTC
I'm still interested in working on this feature but don't have time for it at the moment. As far as I'm concerned it's not dead, FWIW.
Comment 20 Katrin Fischer 2019-04-28 21:15:52 UTC
Maybe this could be wrapped into unifying the patron name display? (bug 22279)
Comment 21 Jonathan Druart 2019-04-28 23:32:59 UTC
(In reply to Katrin Fischer from comment #20)
> Maybe this could be wrapped into unifying the patron name display? (bug
> 22279)

Agreed, we definitely should fix bug 22279 first, then this feature will be very easy to implement.
Comment 22 Katrin Fischer 2023-01-08 00:07:03 UTC
We just recently had a request to change the link targets - so this is still valid.