Bug 3756 - new sys prefs - no way to add a new local use preference
Summary: new sys prefs - no way to add a new local use preference
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: rel_3_2
Hardware: PC All
: PATCH-Sent (DO NOT USE) blocker (vote)
Assignee: Chris Nighswonger
QA Contact: Bugs List
URL:
Keywords:
: 4185 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-11-03 05:25 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 UTC (History)
5 users (show)

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


Attachments
local use 1 (212.63 KB, image/png)
2010-07-25 20:01 UTC, Nicole C. Engard
Details
local use 2 (197.24 KB, image/png)
2010-07-25 20:01 UTC, Nicole C. Engard
Details
local use 3 (72.90 KB, image/png)
2010-07-25 20:01 UTC, Nicole C. Engard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:14:37 UTC


---- Reported by nengard@gmail.com 2009-11-03 17:25:56 ----

When I'm on the local use tab there is no way to add a new system preference - we have a lot of documentation on how to use this - so we kind of need this option back.



---- Additional Comments From pianohacker@gmail.com 2009-11-03 19:12:29 ----

It is _technically_ possible to add a local use preference, but you have to edit the right .pref file to do so. Here's why I left the UI for the feature out for the time being:

 * Getting Koha to understand a new preference requires editing code, which will be harder than adding it to the .prefs file. Admittedly, the "Local Use" tab made a nice workflow for adding a new pref before sending it in, but see below:
 * The old system did the local use tab through a rather horrifying hack where it selected for every preference it didn't know about (SELECT from systempreferences where variable not in ('timeout', 'MIME', ad infinitum for every Koha syspref)). I could bring this system back, but it would be slow and ugly and the local use preferences wouldn't be searchable.
 * Because of the rather complex format of the .pref files, an editor/creator would have to be either complex or incomplete.

Would it work to change this bug to "Add documentation for adding system preferences" (for new sysprefs editor) and delay a UI until 3.4 or .6?



---- Additional Comments From nengard@gmail.com 2009-11-03 19:23:42 ----

While I understand this - it's a big issue - particularly to our customers since they use Koha as a CMS and follow this tutorial:

http://wiki.koha.org/doku.php?id=en:documentation:tutorials:creatingcmspages

In short - they need the power to add new pages (aka preferences) via the UI - so I say we can change the bug title - but not wait until 3.4 since it's not a new feature - it was a feature in 3.0 that is no longer there :(



---- Additional Comments From henridamien@koha-fr.org 2010-01-20 22:32:20 ----

Maybe something good would be some way to Test the systempreferences in database and synch the database with yaml.
Would be only one shot or once in a while (when updating database)

this command line script would take all the sysprefs in YAML and see whether they are present in database, and the other way round. It would report the ones missing.
And then could display them so that it would be easy to INSERT into database OR to add into yaml files.
(It is what has been done on univ_lyon3 branch of git.biblibre.com for sysprefs in the database)




---- Additional Comments From nengard@gmail.com 2010-02-07 15:57:12 ----

This is something we need in 3.2 because there are libraries that have set up custom pages using the local use preferences and upgrading to 3.2 might make it so that they can no longer manage these pages ... 



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:14 UTC  ---

This bug was previously known as _bug_ 3756 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3756

Actual time not defined. Setting to 0.0
The original assignee of this bug does not have
   an account here. Reassigning to the default assignee
   for the component, gmcharlt@gmail.com.
   Previous assignee was pianohacker@gmail.com.
Bug reassigned, setting status to "NEW".
   Previous status was "ASSIGNED".
CC member thehaven104@gmail.com does not have an account here

Comment 1 Nicole C. Engard 2010-06-02 11:43:28 UTC
new wiki page here: http://wiki.koha-community.org/wiki/Koha_as_a_CMS and in the manual here: http://koha-community.org/documentation/3-2-manual/?ch=a9514
Comment 2 MJ Ray (software.coop) 2010-07-07 19:17:06 UTC
Updating version as described in http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_July_2010
Comment 3 Nicole C. Engard 2010-07-22 12:13:56 UTC
This patch includes a bunch of system preferences on the local use tab that need to be removed - no sys prefs that can be found on other tabs should be on this list.
Comment 4 Chris Nighswonger 2010-07-25 19:38:21 UTC
Could you enumerate which prefs you are seeing? This patch hides all non-local prefs in the current head.
Comment 5 Nicole C. Engard 2010-07-25 19:53:17 UTC
okay i'm confused - i don't see them anymore, but i also don't see a way to create a local use preference anymore either.
Comment 6 Nicole C. Engard 2010-07-25 20:00:53 UTC
Found it.  Okay if you go to sys prefs and click on the local use tab i see how to add a new pref, but i have a ton of prefs showing - see the screenshots.  the prefs i have are: 

acquisitions
AnonymousPatron
AutoEmailPrimaryAddress
AutoSelfCheckID
AutoSelfCheckPass
BakerTaylorPassword
BranchTransferLimitsType
defaultSortOrder
FrameworksLoaded
holdCancelLength
ILS-DI:AuthorizedIPs
kohaspsuggest
libraryAddress
marc
MIME
OAI-PMH:Set
OAI-PMH:Subset
OpacCloud
OPACdefaultSortOrder
OPACDisplayExtendedSubInfo
OPACNoResultsFound
OPACRerunSearch
OPACSubscriptionDisplay
OrderPdfTemplate
pdfformat
PINESISBN
printcirculationslips
RandomizeHoldsQueueWeight
sortbynonfiling
SyndeticsCoverImageSize
TemplateEncoding
Version
z3950AuthorAuthFields
Comment 7 Nicole C. Engard 2010-07-25 20:01:14 UTC
Created attachment 2414 [details]
local use 1
Comment 8 Nicole C. Engard 2010-07-25 20:01:36 UTC
Created attachment 2415 [details]
local use 2
Comment 9 Nicole C. Engard 2010-07-25 20:01:51 UTC
Created attachment 2416 [details]
local use 3
Comment 10 Nicole C. Engard 2010-07-25 20:02:29 UTC
note that this is after you click on local use - not the default local use tab you see when you visit sys prefs
Comment 11 Chris Nighswonger 2010-07-26 12:31:39 UTC
(In reply to comment #10)
> note that this is after you click on local use - not the default local use tab
> you see when you visit sys prefs

Ok, this appears to be a result of Frédéric's patch. (http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=4dc85d2f0a7b8fb682fb0f492cc06c8f1a16bc31) According to the commit message for this patch:

"As a side effect, local sysprefs editor displays also deprecated
sysprefs which is a feature from my point of view. For example,
GranularPermissions is displayed as a local syspref because it has been
removed recently from admin.pref but hasn't been yet removed from DB
(could be done later with a DB update)."

However, this does not hold true in all cases. For example, AutoSelfCheckID and AutoSelfCheckPass show in the Local Pref tab now. Neither of these are deprecated sysprefs.
Comment 12 Chris Nighswonger 2010-07-26 12:32:25 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > note that this is after you click on local use - not the default local use tab
> > you see when you visit sys prefs
> 
> Ok, this appears to be a result of Frédéric's patch.
> (http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=4dc85d2f0a7b8fb682fb0f492cc06c8f1a16bc31)
> According to the commit message for this patch:
> 
> "As a side effect, local sysprefs editor displays also deprecated
> sysprefs which is a feature from my point of view. For example,
> GranularPermissions is displayed as a local syspref because it has been
> removed recently from admin.pref but hasn't been yet removed from DB
> (could be done later with a DB update)."
> 
> However, this does not hold true in all cases. For example, AutoSelfCheckID and
> AutoSelfCheckPass show in the Local Pref tab now. Neither of these are
> deprecated sysprefs.

Frédéric,

Could you comment on this?
Comment 13 Nicole C. Engard 2010-07-26 12:36:37 UTC
This may be a 'feature' in the eyes of a developer, but it is very much not a feature for librarians trying to navigate through the hundreds of preferences already there.  Also is a preference is deprecated doesn't that mean that the code is no longer in place for those preferences to work anyway??
Comment 14 Frédéric Demians 2010-07-26 14:13:30 UTC
> This may be a 'feature' in the eyes of a developer, but it is very much not a
> feature for librarians trying to navigate through the hundreds of preferences
> already there.  Also is a preference is deprecated doesn't that mean that the
> code is no longer in place for those preferences to work anyway??

If your average Joe/Jane librarian noses around in the administration interface, you have first to fix your users permissions. Deprecated sysprefs should be removed at all before releasing 3.2 in the wild. In the meantime, it's better not to hide deprecated sysprefs in order not to forget to remove them.
Comment 15 Frédéric Demians 2010-07-26 14:14:10 UTC
> However, this does not hold true in all cases. For example, AutoSelfCheckID and
> AutoSelfCheckPass show in the Local Pref tab now. Neither of these are
> deprecated sysprefs.

I will fix that. Thanks.
Comment 16 Nicole C. Engard 2010-07-26 16:14:07 UTC
(In reply to comment #14)
> If your average Joe/Jane librarian noses around in the administration
> interface, you have first to fix your users permissions. Deprecated sysprefs
> should be removed at all before releasing 3.2 in the wild. In the meantime,
> it's better not to hide deprecated sysprefs in order not to forget to remove
> them.

Isn't the point of this system that librarians can manage it themselves? I don't think that something should be left in as a reminder to developers - instead it should be in the comments in the code - where the developers are - not where the librarians are.  I promote the power of Koha as anyone having the ability to edit the sys prefs themselves instead of needing an expert.  Also this is the old sys prefs interface and doesn't flow with the look and feel of the rest of it.
Comment 17 Frédéric Demians 2010-07-26 16:48:35 UTC
> Isn't the point of this system that librarians can manage it themselves? I
> don't think that something should be left in as a reminder to developers -
> instead it should be in the comments in the code - where the developers are -
> not where the librarians are.  I promote the power of Koha as anyone having the
> ability to edit the sys prefs themselves instead of needing an expert.  Also
> this is the old sys prefs interface and doesn't flow with the look and feel of
> the rest of it.

As said Peter Parker alias Spider Man: With great power comes great responsibility. Your educated power librarians have not to be scared by their power.

There are three categories of sysprefs in local tab: (1) true local syspref, (2) deprecated sysprefs and (3) false local syspref.

I've send a patch to remove from local syspref tab, some sysprefs which belongs to other tabs: there were a bug. It solves (3).

For (2) someone has to send a DB update to delete all deprecated syspref. You can be this person. This should be done before 3.2 as I already said.

  DELETE FROM systempreferences WHERE variable IN ('etc.

Concerning the old syspref interface which has been resurrected for local syspref, I agree that it isn't coherent with the syspref editor but we already discussed this point on koha-devel. Something has to be done in 3.4. This has been discussed here:

http://lists.koha-community.org/pipermail/koha-devel/2010-July/thread.html#34211
Comment 18 Nicole C. Engard 2010-07-26 16:58:52 UTC
(In reply to comment #17) 
> For (2) someone has to send a DB update to delete all deprecated syspref. You
> can be this person. This should be done before 3.2 as I already said.
> 
>   DELETE FROM systempreferences WHERE variable IN ('etc.
> 

I misread what you said before - I'll gladly submit such a patch (that deletes these problem preferences).  That will solve my problem ;)
Comment 19 Jane Wagner 2010-07-26 17:24:22 UTC
I know these three are definitely needed/in use:

AutoEmailPrimaryAddress
AutoSelfCheckID
AutoSelfCheckPass


Will have to check further on the others.
Comment 20 Frédéric Demians 2010-07-26 17:49:11 UTC
> I know these three are definitely needed/in use:
> 
> AutoEmailPrimaryAddress
> AutoSelfCheckID
> AutoSelfCheckID

AutoSelfCheckID and AutoSelfCheckID won't be displayed as local anymore as soon as my last patch will be applied since they exist in circulation template.

Same for AutoEmailPrimaryAddress which belongs to patron.tmpl.
Comment 21 Galen Charlton 2010-10-22 02:10:01 UTC
Core issue is now resolved, and disused system preferences have been removed.  Please file a separate bug for the remaining system preferences that appear in local use.
Comment 22 Magnus Enger 2012-03-23 09:14:19 UTC
*** Bug 4185 has been marked as a duplicate of this bug. ***