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.
Created attachment 8096 [details] [review] Bug 7680 - PatronDefaultView preference to control whether patron links go to circ or patron details 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. Individual templates must often pass the "local" borrowernumber variable via the INCLUDE if the variable is not called "borrowernumber": [% INCLUDE 'patron-default-view.inc' borrowernumber = ITEM_DAT.borrowernumber %]
Created attachment 8097 [details] [review] Bug 7680 [REVISED] PatronDefaultView preference to control whether patron links go to circ or patron details 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. Individual templates must often pass the "local" borrowernumber variable via the INCLUDE if the variable is not called "borrowernumber": [% INCLUDE 'patron-default-view.inc' borrowernumber = ITEM_DAT.borrowernumber %] Revision: First patch didn't have the new include file.
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
Created attachment 8151 [details] [review] Bug 7680 [REVISED] PatronDefaultView preference to control whether patron links go to circ or patron details 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. Individual templates must often pass the "local" borrowernumber variable via the INCLUDE if the variable is not called "borrowernumber": [% INCLUDE 'patron-default-view.inc' borrowernumber = ITEM_DAT.borrowernumber %] Revision: First patch didn't have the new include file. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
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'.
> 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.
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
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?
(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)
Hi, anyone know where is the discussion of this system preference? Thanks Marjorie
(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 %]
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.
(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.
*** Bug 6670 has been marked as a duplicate of this bug. ***
*** Bug 6905 has been marked as a duplicate of this bug. ***
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.
I am still a candidate to SO or QA this patch if rebased :)
Hi, I asked two years ago but this bug is still under discussion. Some news about it? Marjorie
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.
Maybe this could be wrapped into unifying the patron name display? (bug 22279)
(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.
We just recently had a request to change the link targets - so this is still valid.