I would be nice if after searching for a preference and finding it in the list you could easily link to it. Also, if after finding a pref you could see the prefs in the same category
Created attachment 91840 [details] [review] Bug 23388: Make system preferences links and give them anchors FIXME: Note the floating toolbar actually breaks this because it hides the anchored pref. Add this CSS to IntrnateUSerCSS to fix it padding-top: 50px; margin-top: -50px; } To test: 1 - Search for 'fields' 2 - Scroll to 'PatronQuickAddFields' 3 - You don't have a way to share a link to this pref 4 - You can't view th other patron prefs without scrolling back to tabs 5 - Apply patch 6 - Repeat 7 - Note the pref is a link you can copy 8 - Click it 9 - You are now on the tab for the pref 10 - Click on other prefs and you focus on them
Created attachment 91841 [details] [review] Bug 23388: Sort the tab results when searching Before this patch we can get the matching tabs back in any order To test: 1 - Search system preferences for 'field' 2 - Refresh the page a few times 3 - Note results are reordered 4 - Apply patch 5 - Refresh the page several times again 6 - Results are consistent
Created attachment 91846 [details] [review] Bug 23388: Make system preferences links and give them anchors FIXME: Note the floating toolbar actually breaks this because it hides the anchored pref. Add this CSS to IntrnateUSerCSS to fix it padding-top: 50px; margin-top: -50px; } To test: 1 - Search for 'fields' 2 - Scroll to 'PatronQuickAddFields' 3 - You don't have a way to share a link to this pref 4 - You can't view th other patron prefs without scrolling back to tabs 5 - Apply patch 6 - Repeat 7 - Note the pref is a link you can copy 8 - Click it 9 - You are now on the tab for the pref 10 - Click on other prefs and you focus on them Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Created attachment 91847 [details] [review] Bug 23388: Sort the tab results when searching Before this patch we can get the matching tabs back in any order To test: 1 - Search system preferences for 'field' 2 - Refresh the page a few times 3 - Note results are reordered 4 - Apply patch 5 - Refresh the page several times again 6 - Results are consistent Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Hi Nick, can you explain this bit please? FIXME: Note the floating toolbar actually breaks this because it hides the anchored pref. Add this CSS to IntrnateUSerCSS to fix it padding-top: 50px; margin-top: -50px; } Also: FAIL koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences.tt FAIL filters missing_filter at line 55 ( <td id="[% FOREACH NAME IN LINE.NAMES %][% NAME.name %][% END %]" class="name-cell">) wrong_html_filter at line 60 ( <span class="term" id="jumped"><a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a></span>) wrong_html_filter at line 60 ( <span class="term" id="jumped"><a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a></span>) missing_filter at line 60 ( <span class="term" id="jumped"><a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a></span>) missing_filter at line 60 ( <span class="term" id="jumped"><a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a></span>) wrong_html_filter at line 62 ( <span class="term"><a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a></span>) wrong_html_filter at line 62 ( <span class="term"><a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a></span>) missing_filter at line 62 ( <span class="term"><a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a></span>) missing_filter at line 62 ( <span class="term"><a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a></span>) wrong_html_filter at line 64 ( <a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a>) wrong_html_filter at line 64 ( <a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a>) missing_filter at line 64 ( <a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a>) missing_filter at line 64 ( <a href="?tab=[% TAB.tab_id %]#[% NAME.name %]">[% NAME.name | html %]</a>) FAIL forbidden patterns forbidden pattern: tab char (line 58)
I've been working on an alternate patch which addresses one aspect of this bug: Linking easily to specific preferences. The proposed patch does two things I don't like: It breaks the previous behavior of the system preference names as <label>. And the links don't make much sense unless you're looking at search results. In other circumstances clicking the link doesn't do anything. My proposal would be to show a link on hover: https://zivotdesign.com/p/view.php?p=15646746956636 Unfortunately my solution suffers from the same problem described by Nick: When the page jumps to the anchored link the pref is right at the top of the browser window, thus it's hidden by the floating toolbar. I worked to come up with a JavaScript solution but failed.
How should we continue here? Nick, could you help Owen with his patch or vice versa?
Created attachment 94368 [details] [review] Bug 23388: [WIP] Make system preferences links This alternate solution adds a link which when clicked will copy a URL linking directly to the corresponding system preference. To test, apply the patch and view system preferences. Hovering the mouse over any row in the system preferences table should trigger the display of an anchor link at the end of the row. Hovering over the link should display a tooltip, "Copy link to this preference." Clicking the link should copy it to your clipboard. Test that the link is copied correctly and that it works to link you to the preference in question. Known issues: Because of the way the page is drawn, the browser's calculation of where to scroll isn't accurate, meaning the target preference will sometimes be hidden by the floating toolbar. Question: "Hover" isn't a mobile/touch-friendly interaction. Show the link all the time? Show it at narrower browser widths?
Testing the WIP patch in Chrome 77 but I don't see any change. Maybe I'm just holding it wrong... I see changes in the page source (e.g. <td id="link_). Nothing happens on hover over a preference, though.
The link should appear all the way at the end of the row, not in the first cell in the row (which, now that I think about it and having seen your patch, is probably the correct place for it).
Thanks, that was it. I only noticed one flaw - the URL copied to clipboard is relative to the site root, not including scheme, host port. That and after accessing the syspref it is overlaid by the floating toolbar, but there is a fix to that in the previous patch.
(In reply to Ivan Masár from comment #11) > Thanks, that was it. I only noticed one flaw - the URL copied to clipboard > is relative to the site root Is your staffClientBaseURL system preference set?
> Is your staffClientBaseURL system preference set? It's not set. This seems to be the default, both in my installed instance and in kohadevbox, so I think we should not rely on it.
(In reply to Ivan Masár from comment #13) > > Is your staffClientBaseURL system preference set? > > It's not set. This seems to be the default, both in my installed instance > and in kohadevbox, so I think we should not rely on it. Koha does rely on it in a lot of places to make things work smoothly. Generally much recommended. For links in staff relativ links might work - but in other places where we link from OPAC to staff and staff to OPAC it's needed.
(In reply to Katrin Fischer from comment #14) > Koha does rely on it in a lot of places to make things work smoothly. (which means we should probably add it to the installer onboarding?)
Before I found this bug, I made a patch that solves the same problem (linking to sysprefs) in a different way - via search by syspref name rather than anchor links. As a result, my solution shows one syspref, this one scrolls down to the target syspref. See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23823
What's next?
Does Bug 23823 make this a duplicate? I don't have a better patch forthcoming.
*** This bug has been marked as a duplicate of bug 23823 ***