View Issue Details

IDProjectCategoryView StatusLast Update
0019630mantisbtcode cleanuppublic2015-04-17 06:35
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Summary0019630: Config naming conventions

This issue was raised as part of:

I would rename this to timeline_view_threshold (similar to roadmap_view_threshold).

TagsNo tags attached.




2015-04-17 01:06

manager   ~0049428

From @dregad:

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
config_defaults_inc.php:1484:$g_view_summary_threshold = MANAGER;
config_defaults_inc.php:1601:$g_view_sponsorship_total_threshold = VIEWER;
config_defaults_inc.php:1608:$g_view_sponsorship_details_threshold = VIEWER;
config_defaults_inc.php:2102:$g_view_attachments_threshold = VIEWER;
config_defaults_inc.php:2539:$g_view_bug_threshold = VIEWER;
config_defaults_inc.php:2598:$g_view_handler_threshold = VIEWER;
config_defaults_inc.php:2605:$g_view_history_threshold = VIEWER;
config_defaults_inc.php:2655:$g_view_proj_doc_threshold = ANYBODY;
config_defaults_inc.php:2791:$g_roadmap_view_threshold = VIEWER;
config_defaults_inc.php:2803:$g_timeline_view_threshold = VIEWER;
config_defaults_inc.php:3020:$g_view_configuration_threshold = ADMINISTRATOR;
config_defaults_inc.php:3832:$g_tag_view_threshold = VIEWER;
config_defaults_inc.php:3896:$g_time_tracking_view_threshold = DEVELOPER;
config_defaults_inc.php:4014:$g_due_date_view_threshold = NOBODY;
(list edited to remove a few configs which match the regex but are actually not view thresholds)

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.



2015-04-17 01:06

manager   ~0049429

From @vboctor:

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:


rather than


You get my point.



2015-04-17 01:07

manager   ~0049430

From @dregad:

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)



2015-04-17 01:08

manager   ~0049431

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).



2015-04-17 06:30

developer   ~0049435

Last edited: 2015-04-17 06:35

View 2 revisions

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

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).

The existing model errors out on use of old config

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>
config_defaults_inc.php: $g_view_history_threshold = VIEWER;
custom local config: $g_view_history_threshold = DEVELOPER;

AFTER: the system displays history for all users, no errors... <pre>
config_defaults_inc.php: $g_history_view_threshold = VIEWER;
obsolete.php: config_obsolete( 'view_history_threshold', 'history_view_threshold' );
custom local config: $g_view_history_threshold = DEVELOPER;

Admin checks do detect this:
The configuration option view_history_threshold is now obsolete
it is currently defined in config_inc.php, as well as in the database configuration for:

All Users: All Projects


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).

Issue History

Date Modified Username Field Change
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