[Phpmyadmin-devel] RFE #1123

[Marc Delisle]

Ashutosh Dhundhara a écrit :
> On Wed, Aug 6, 2014 at 2:46 AM, Marc Delisle <marc at infomarc.info> wrote:
> 
>> Le 2014-08-05 14:35, Ashutosh Dhundhara a écrit :
>>> Hi,
>>>
>>> I was starting to work on RFE #1123
>>> <https://sourceforge.net/p/phpmyadmin/feature-requests/1123/> (Zeroconf
>>> PMA tables support).
>>>
>>> Is it something like enabling/disabling the PMA configuration storage
>>> feature through UI with default table names?
>>>
>>> Also, automatically create these tables when user has enabled this
>>> feature through UI?
>> Hi Ashutosh,
>>
> 
> Thanks Marc and Isaac.
> 
> The RFE was a bit confusing but the insight provided by you both clarified
> everything.
> However, I have a few queries and I am posting them in-line.
> 
> 
>> I have read again the RFE and the comments in the ticket; then I read
>> the details of your proposal on google-melange.com.
>>
>> I don't have all the answers but can give you some pointers; others can
>> give ideas too or contradict mine :)
>>
>> * The solution has to work for a single-user installation and also for a
>> multi-user installation
>>
> 
> How single-user and multi-user installation is going to affect this feature?
> Is it something like if the user does not have access to the database
> defined in the
> directive $cfg['Servers'][$i]['pmadb'], then create the pma tables in the
> database on which he/she
> has access?

It is current for a single-user installation to not bother creating a 
control user; when there is no control user, the logged-in user is used 
also to access the pmadb.

In a multi-user installation, there is normally a distinct control user 
defined.

So please test both situations.

> 
> 
>> * Priority should go to use the values from config.inc.php (the control
>> user, pmadb and all pmadb tables) if present. This is mainly for
>> backward compatibility and also because I suspect it's the only way to
>> support a multi-user installation
>>
>> * In case there is no such configuration, the logic could check the
>> presence of the default database name and table names, as suggested in
>> examples/create_tables.sql
>>
>> * I'm not sure on which panel is the best place to do this verification,
>> but it could be at the same places where the warnings about the
>> configuration storage are currently done (home page and each database >
>> Operations page
>>
>> * If this default database name "phpmyadmin" does not exist, the logic
>> could look for the default table names in the current database (this is
>> in case the user has access to only one database)
> 
> 
> Lets say user sees the warning on homepage. Then how to decide the current
> db?

Good question; so probably the verification won't be possible from the 
home page, only from a db-specific Operations page.

Anyway, we could not ask the user to choose a db to store the 
configuration storage, because this choice could not be remembered (as 
this is a zero-conf mechanism).

> Is it something like creating these tables in the first database on which
> the user has CREATE access?

No, because it won't be possible to know which db contains the 
configuration storage, when the user opens another database.

> 
> 
>> * If the default db and/or default table names are not found, the logic
>> could pop a dialog, offering to create these in the current db and
>> asking for confirmation; I hope it's possible to directly read
>> examples/create_tables.sql for this, in order to avoid discrepancies
>> between the logic and changes in create_tables.sql
>>
>> * Something will have to be done with the logic that gives a warning
>> about the configuration storage; it would probably lose its purpose
>>
> 
> Yes Marc. We will have to do something for this.
> How about keeping this message/warning intact and when the user clicks on
> 'here' of "To find out why click here
> <http://127.0.0.1/pma/chk_rel.php?token=ee04c7e45192bb15a4151248028e905f>.",
> the user
> will be directed to diagnostic page as it is currently done. And on that
> page we can provide a link with text something like "Fix it" and when user
> will click this link, the new logic will be executed?

Good idea. This way, either the user can fix it manually (in a way that 
permits to have just one configuration storage) but will require 
configuration, or will be able to use the zero-conf mechanism (which 
will produce the pma_ tables in his current db).
> 
> 
>> * Maybe we'll need a new directive in config.inc.php, so that the
>> installer can decide that the zero conf is active or not (would be
>> active by default)
>>
>> * I am not in favor of designing a UI to set up the configuration
>> storage, as this already exists in /setup (with the goal of producing a
>> config.inc.php)
>>
>> * I am not in favor of programmatically creating a .php file in the
>> installation directory or doing any modification in config.inc.php

-- 
Marc Delisle (phpMyAdmin)