Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Trivial
-
Resolution: Won't Fix
-
Affects Version/s: 4.4.0
-
Fix Version/s: Unscheduled
-
Component/s: None
-
Labels:None
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
totten & I discussed the fairly common scenario where an extension wants to add a single setting to a contribution page or such like. Since they can't easily add a column to the table we get into the scenario of potentially many tables with one setting in each (& potentially many joins)
So we agreed it made sense to add a 'settings' or 'configuration' column to entities that are about configuration (ie we don't think it would be performant to add to contact, membership, participant, other contact related fields but it makes sense on less frequently accessed objects ie. my initial thoughts are
- contribution page
- event
- uf group
- batch
(other debatables are custom field specs & uf_field specs)
The change in core is simply the addition of a field 'settings' to each of these tables (long text). We would describe them on the wiki as storing a json array of settings keyed at the top level by the extension's key.
We should perhaps also add to the api the ability to save to them. This begs the question as to whether the api supports
1) json encoded string (only) - caller has all responsibility
2) array which api json encodes
3) key which api adds to the api (allowing caller to only set their own key - in which case we are getting into something more complex to unset the key)
totten - please review above & comment & then assign to me.