#4984 Undefined <feature>work upon upgrade to new version

[phpMyAdmin bot]

This report is related to user submitted report #11887 on the phpmyadmin error reporting server.

[Madhura Jayaratne]

For extra features offered by phpMyAdmin, <feature>work parameters are used to check whether each feature is active. These are defined at https://github.com/phpmyadmin/phpmyadmin/blob/RELEASE_4_4_11/libraries/relation.lib.php#L421-L438.
PMA_getRelationsParam() returns these values cached in the session and these values will not go undefined unless in a version upgrade. Caching is essential IMO and my suggestion is to mark this ticket as wont-fix requiring the user to re-login upon upgrade.

[Marc Delisle]

Madhura,
do you think that a version upgrade explains all occurrences of this incident?

[Madhura Jayaratne]

I see two patterns in accessing these variables
$cfgRelation = PMA_getRelationsParam(); $cfgRelation['menuswork']
or
$GLOBALS['cfgRelation']['menuswork']

Value for $GLOBALS['cfgRelation'] is set inside PMA_getRelationsParam(). So I do not see any other way of some <feature>work variable being not set, other than in a version upgrade

[Marc Delisle]

Makes sense, so marking as "won't fix" also makes sense (unless someone starts to add isset() verifications everywhere).

[Madhura Jayaratne]

I think adding isset() verification does not make sense as these variables are always defined except in an upgrade. In fact, these variables can be used to avoid isset() check for other pmadb variables. For example:
if ($cfgRelation['menuswork']) { $groupTable = PMA_Util::backquote($cfgRelation['usergroups']); }

[Madhura Jayaratne]

I think it's better to put this in docs. https://github.com/phpmyadmin/phpmyadmin/pull/1791

[Marc Delisle]

Let's hope users will read the doc :) because we have a ton of these error reports.

[Michal Čihař]

How about storing version number in the session and if that differs from current one force logout?

[Marc Delisle]

That would work (except with the 'config' auth).