View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019630||mantisbt||code cleanup||public||2015-04-17 01:06||2015-04-17 06:35|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0019630: Config naming conventions|
This issue was raised as part of:
|Tags||No tags attached.|
Sorry @vboctor but I think @schriftgestalt is right - in terms of consistency, we actually have more settings named $g_view_xxx_threshold than we have $g_xxx_view_threshold:
$ git grep ^\$.view.thresh -- config_defaults_inc.php
That's 9x view_xxx vs 4x xxx_view (not counting the new timeline config). Based on that, I would rather have it like @schriftgestalt originally submitted.
Then we can discuss whether we should update $g_roadmap_view_threshold, $g_tag_view_threshold, $g_time_tracking_view_threshold and $g_due_date_view_threshold for consistency.
I don't think the count is the deciding factor here. It is what we want to consider as the old way of doing it vs. the new way of doing it.
I personally prefer the $g_feature_knob model since it enables nice natural grouping and auto-complete for all configs relating to a feature:
You get my point.
OK fair enough, that makes sense - in that case let's do the update the other way around (I was just thinking about minimizing the number of obsoleted configs)
I think we should use the preferred model for the new configs. For existing configs, our deprecation model is designed for handle these configs within config_inc.php, but it doesn't handle very well the case where these old configs are set in the database (or maybe my recollection is wrong, I haven't checked). We may want at one point supporting the concept of "a" became "b" at retrieval time or we could consider schema change step(s). The existing model errors out on use of old config and possible recommend looking at a different config. That model doesn't distinguish new config being 100% compatible (but just name difference) vs. incompatible field (e.g. enabled flag vs. threshold).
config_obsolete() actually covers both the case of config_inc.php definitions, as well as database configuration. That's something I fixed several years ago (see 0013435).
The limitation is that we only detect obsolete configs in admin checks (config_obsolete() via inclusion of obsolete.php in check_config_inc.php).
In theory, the old config should not be referenced anywhere in the code base after it is obsoleted, the only potential issue might be with plugins. In that case, I think erroring out is the right thing to do.
The more important issue would be for admins who don't run the checks after upgrade, and might therefore see their system silently fall back to a default value. For example:
BEFORE: restricting view of issue history to developers <pre>
AFTER: the system displays history for all users, no errors... <pre>
Admin checks do detect this:
Short of caching the list of obsolete configs in config_api.php and checking for obsolete ones whenever we call config_get(), I don't see how we could avoid that.
IMO it would be unnecessary overhead, and I'm not convinced trying to build a mechanism to automate is actually worth the effort. We already provide a hint about which replacement to use (the 2nd param to config_obsolete()); to go the extra mile, we would have to set some kind of additional flag to indicate 1:1 replacements (renames).
|2015-04-17 01:06||vboctor||New Issue|
|2015-04-17 01:06||vboctor||Note Added: 0049428|
|2015-04-17 01:06||vboctor||Note Added: 0049429|
|2015-04-17 01:07||vboctor||Note Added: 0049430|
|2015-04-17 01:08||vboctor||Note Added: 0049431|
|2015-04-17 06:30||dregad||Note Added: 0049435|
|2015-04-17 06:35||dregad||Note Edited: 0049435||View Revisions|