[Koha-bugs] [Bug 23849] Update the list of sysprefs to share with Hea

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23849

--- Comment #24 from Victor Grousset/tuxayo <victor at tuxayo.net> ---
(In reply to Paul Poulain from comment #20)
> It was FAUSP : "Fighters Against Useless System Preferences" :D

YES


######


(In reply to Katrin Fischer from comment #21)
> > == Pretty sure they should be > No ==
> > Or just share if it's empty/default or custom.
> > AdlibrisCoversURL
> > EmailAddressForSuggestions
> > ILS-DI:AuthorizedIPs
> > NewItemsDefaultLocation
> > OpacHiddenItems
> > OpacHiddenItemsExceptions
> > ReplyToDefault
> > RestrictedPageLocalIPs
> > RestrictedPageTitle
> > ReturnpathDefault
> > SelfCheckAllowByIPRanges
> > UpdateItemLocationOnCheckin
> 
> I'd go for not sharing whenever in doubt. I think they would not gain us
> much, but have the potential to make people insecure about sharing when
> turning up on Hea maybe?


«have the potential to make people insecure» If there was a way to know what
was shared without looking at the code. ^^"
But yes, if it's not useful let's not shared these.


> > == Maybe false positive, could be yes (share) instead of no ==
> > OverDrivePasswordRequired
> > OverDriveUsername
> > NovelistSelectStaffEnabled
> > NovelistSelectView
> > OAI-PMH:AutoUpdateSets
> > OAI-PMH:MaxCount
> > opaclanguages
> > OpacLocationOnDetail
> > OPACResultsLibrary
> > RESTOAuth2ClientCredentials
> > SyndeticsAuthorNotes
> > SyndeticsCoverImages
> > SyndeticsCoverImageSize
> > SyndeticsEditions
> > SyndeticsExcerpt
> > SyndeticsReviews
> > SyndeticsSeries
> > SyndeticsSummary
> > SyndeticsTOC
> 
> Everything that turns a feature on/off (boolean) is probably ok. Prefs set
> up with strings might not be very helpful and more dangerous.

It seems most of these are not useful, especially if there is a main syspref
shared that already tells that OverDrive, Novelist, OAI-PMH, Syndetics is in
use.
I interpreted "> No" as: "there is/could be private info"
But I should have filtered the above list to not put the obviously not useful
ones.

> opaclanguages would be interesting to see, but would need some extra
> processing as it's a string of language codes separated by pipe - as a
> string useless, you'd want to list how often which language is installed.

opaclanguages, yes very interesting! Should the processing be on Koha's side or
Hea's side?

So besides opaclanguages (which might not be shared directly) any other prefs
from this list worth sharing?


> > Are backends lists an issue? Or is it actually very useful?
> > ILLOpacbackends
> 
> These are not the installed ones, but what works in OPAC, so maybe not.

Not sharing right?


> > Could some codes be so rare that they are equivalent of sharing the library
> > name?
> > MARCOrgCode
> > 
> > That should be ok right?
> 
> The MARCOrgCode is the unique identifier of a library - so it IS equivalent
> to sharing the library name. Official MARCOrgCodes can be looked up easily.

Thanks for the info. I though it was pointing to e.g. the Library Of Congress
in the USA, not the library itself. So yeah, not sharable.


> > == Maybe a typo in the list ==
> > ArticleRequestsMandatoryFieldsItemsOnly
> > ↓
> > ArticleRequestsMandatoryFieldsItemOnly
> > 
> > OpacSuppressionByIPRangeµ
> > ↓
> > OpacSuppressionByIPRange
> 
> Where is the typo?

In the file in_DB_but_not_shared


> > == Not in the UI (Administration › System preferences) what does it mean? ==
> > ElasticsearchIndexStatus_authorities
> > ElasticsearchIndexStatus_biblios
> > INTRAdidyoumean
> > OPACdidyoumean
> 
> These are set up on their own configuration pages, but systempreferences is
> used for storage. That's why they are not showing in the regular GUI.

Ok, no worries then.


> > OpacMainUserBlock
> > opacheader
> 
> Both of those have been moved into News and should no longer be present,
> where did you spot them as prefs?

In the file in_DB_but_not_shared. It seems Joubu got them from the DB. So maybe
updatedatabase spared them.


> > printcirculationslips
> 
> This one has its own bug somewhere I think.

bug 10014
bug 17845


######


(In reply to Katrin Fischer from comment #22)
> Hm, why is seearchengine not turning up in the list, didn't we start the
> discussion there?


It's not marked as no in the file in_DB_but_not_shared so I assumed it will be
shared right?

######


(In reply to Jonathan Druart from comment #23)
> Victor, we don't want more sysprefs.

It was a joke after I went through almost all sysprefs (in_DB_but_not_shared)
in the UI ^^" (To double-check what data they could contain)
Even knowing the number of them I though 1.5 hours would be enough, but wrong!


> The goal was to double-check, from the whitelist I provided, if they were
> all valid and relevant

wait, which is the whitelist? I might have gone totally in the wrong direction
😱


> we don't want personal data to be shared.

No misundestanding on this. This what I had in mind.


> Don't rethink/redo the whole process please.


So "in_DB_but_not_shared" was the wrong file to check?? 😱

-- 
You are receiving this mail because:
You are watching all bug changes.