[Phpmyadmin-devel] RFE #1123

[Marc Delisle]

Ashutosh Dhundhara a écrit :
> On Fri, Aug 8, 2014 at 12:37 AM, Marc Delisle <marc at infomarc.info> wrote:
> 
>> 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
>>
> Hi Marc,
> 
> What if a user has access to multiple databases and the default database
> 'phpmyadmin' does not exists?
> Lets say the user visits database 1 > Operation tab where he agrees to the
> choice to create pma tables in that database.
> 
> Now for the current session the configuration storage is up and working.
> Now when next time he logs into PMA, there will be again a warning for
> configuration storage on home page. But when he will visit database 1 >
> Operation tab, everything will become fine again.

Hi Ashutosh,
I said above "probably the verification won't be possible from the
home page, only from a db-specific Operations page".

> 
> But what if he visits database 2 > Operation tab before database 1. He will
> get a choice to create pma tables in that database too. If he agrees to
> create then there will be two different sets of pma tables because pmadb
> name can't be remembered.
> What should be done in this case?

I don't think that we can further help this user; he will have to use 
different sets of the phpMyAdmin configuration storage. There is no 
zero-conf way of remembering which db contains thess tables. Doing a 
search in each db the user has access to, to find a set of configuration 
storage tables, is not a good idea.

However, when creating the set in db1, we should give the user a warning 
that this set will only apply to this database, and that to have just 
one set, he should follow the doc explaining this.

-- 
Marc Delisle (phpMyAdmin)