Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
09:00 < ibennetch> Hello, and welcome to the monthly meeting of the phpMyAdmin developers. Let's jump right in. 09:00 < nisargjhaveri> Hi Marc. 09:00 < nisargjhaveri> Hi everyone 09:00 < ibennetch> First up, the human readable URL proposal. 09:00 < Marc9> About this, I wonder what's the point, taking into account that we need a valid token 09:01 < Marc9> which is quite unhuman! 09:01 < zixtor> Still the hash microhistory part is quite annoying and can be well traded for HTML5 API 09:01 < zixtor> which would clean URL quite a bit 09:02 < ibennetch> I have to confess I'm not familiar with this HTML5 API, but it sounds like a good thing to implement. 09:02 < nijel> I agree with zixtor here, using HTML5 history api would be much cleaner 09:02 -!- Warped [~Warped@unaffiliated/warped] has joined #phpmyadmin 09:02 < Marc9> zixtor, should this be another feature request 09:02 < zixtor> Marc9 I think this is one part of this RFE we are discussing 09:03 < ibennetch> According to FAQ 4.8 we can already pass things like pma_username, db, and table as URL query strings. 09:04 < Marc9> ibennetch I'm not sure this is still working 09:04 < nijel> as for human URLs, I think it could work even with token stuff, we already bypass some parameters even with missing token 09:04 < zixtor> It is working I think 09:04 < ibennetch> Yeah, it still does seem to work; I tested it earlier 09:05 < Marc9> ok 09:05 < ibennetch> THought I didn't fully test it, at least pma_username and db work here :) 09:05 < zixtor> Also, would index.php/ be a good looking solution? If we are talking of prettier URLs 09:06 < nisargjhaveri> Also, about token, I don't know how exactly it works. But, can't we use any other passing mechanism, like cookie for it? 09:07 -!- chealer [~pcloutier@pdpc/supporter/student/chealer] has joined #phpmyadmin 09:07 < ibennetch> Of course the problem with FAQ 4.8 is that you're putting your username and password in the URL :\ 09:07 < nisargjhaveri> And, index.php/ is not a really good solution. But I am under impression that most users have access to rewrite rules. 09:07 < zixtor> Personally, I would be content with just HTML5 API and would not go any more prettying 09:07 < Marc9> Nisarg I don't believe that we found a secure solution to avoid passing a token 09:07 < nijel> nisargjhaveri: we can not use cookie for that, that would not prevent csrf 09:08 < nijel> what might be better approach though is to require it only for POST requests and make all GET requests read only... 09:08 < Marc9> nijel this would require massive changes 09:09 < chealer> hi 09:10 < zixtor> Currently we primarily use GET requests I think in ajax..js for non-form stuff 09:10 < Marc9> zixtor what about all our links? 09:11 < nijel> Marc9: indeed, but would make lot of things easier... also per RFC 7231, the POST method should be used for any context in which a request is non-idempotent 09:11 < zixtor> Yeah right, for links we use GET requests 09:11 < chealer> in particular if $_GET is used 09:11 < ibennetch> I agree with zixtor that right now we should go to the HTML5 API but not do any more prettying. We can't require a user to have rewrite rule access, and need to prevent CSRF. We could try to move towards nijel's proposal of read-only GET requests, but I'm not sure it's worth the effort at the moment. 09:12 < zixtor> ibennetch: rightly put 09:12 < Marc9> so we keep this RFE open 09:13 < zixtor> can we open an RFE for nijel proposals 09:13 < nijel> zixtor: I will do that... 09:14 < ibennetch> Also, the URL doesn't always seem to match the current page; I'm not sure if that's related to the microhistory or not because I do see, for instance, tbl_sql *somewhere* in the URL when I'm on the SQL tab. 09:14 < ibennetch> But it's so far back in the URL that I'm not sure what page I'm actually on just by looking at the URL. 09:14 < ibennetch> Which would be interesting to improve 09:15 < zixtor> ibennetch: thats because of microhistory 09:15 < ibennetch> Great, thanks nijel for opening the second proposal. 09:15 < Marc9> ibennetch I mostly do not look at the URL :) 09:15 < ibennetch> Thanks zixtor 09:15 < ibennetch> Marc9: :) 09:15 < ibennetch> Okay, we seem to agree about this so let's move on to the pivot table 09:16 < Marc9> For this one I wrote "probably out of scope" 09:16 < zixtor> Looking at the PivotTable.js example posted by Madhura, I agree it is out of our scope, not required of us, plus the data handling limitation. 09:17 < Marc9> plus the 11 years delay ;) 09:17 < ibennetch> We try to allow users to visualize their data, but we're not a full-out data analysis tool. I agree that it's beyond the scope 09:17 < ibennetch> ha 09:17 < nijel> I also think it's out of scope 09:17 < ibennetch> Okay, great. Then about "Unite structure and relation view" 09:18 < ibennetch> I'm happy with the current system, actually. 09:18 < zixtor> I find the current tab improvement good enough :) 09:18 < Marc9> I remember when we had long vertical pages and would like to avoid that 09:18 < ibennetch> I like the tab that Madhura added and personally don't need to see the relation edit display under the table structure. 09:19 < ibennetch> One way we could improve this is to show a read-only list of existing relations under the Information area. 09:19 < ibennetch> In an expandable box like Indexes 09:19 < ibennetch> Then refer the user to the Relation View tab to edit or create them. 09:19 < Marc9> ibennetch yes but maybe users would expect this to be editable 09:21 < ibennetch> It seems no one is in favor of this, so shall we reject it and move on? 09:21 < ibennetch> Auto-updater 09:21 < zixtor> agreed 09:21 < nijel> okay 09:21 < Marc9> yes, let's reject 09:21 < ibennetch> The problem with the auto-updater is the direct filesystem access it requires. 09:22 < zixtor> I am in favor of providing this feature for users having write access. 09:22 < nijel> I think it's good idea to have something like this, even if it won't work in all cases 09:22 < nijel> see for example Piwik's documentation on this topic: http://piwik.org/docs/update/ 09:23 < nisargjhaveri> Auto-updater would be nice to have! 09:23 < chealer> I agree with nijel. it has to be a best effort, we can never cover all scenarios 09:24 < Marc9> Can we imagine that the UI would make a test to see if filesystem is writable, then offer the auto-update if so? 09:24 < ibennetch> I don't feel strongly about this -- it would be nice, but only for a certain set of users. 09:24 < ibennetch> Yes, Marc9 I think that's reasonable. 09:24 < chealer> what's important is not to try something unsure and fail cryptically. ideally, don't even offer upgrading if we can detect it won't work. 09:24 < chealer> ...exactly as Marc9 said. I think that should be possible. 09:25 < Marc9> I'll reopen this RFE 09:25 < ibennetch> I could volunteer to write up a proposal of how this should work, in the wiki I suppose. 09:26 < ibennetch> If that would be helpful. 09:26 < Marc9> ibennetch, better use the current RFE 09:26 < chealer> ...and it's important to be honest about the possibilities and shortcome in marketing material. 09:26 < ibennetch> There we can discuss the various ways it could fail and prevent them :) 09:26 < Marc9> 1458 09:26 -!- madhuracj [~email@example.com] has joined #phpmyadmin 09:26 < ibennetch> Okay, let's go on to the Users vs Accounts terminology. 09:26 < ibennetch> Hello madhuracj 09:26 < madhuracj> Hello everyone 09:27 < Marc9> Hi Madhura 09:27 < chealer> I only found an auto-updater in Wordpress, but I was surprised to see how well it works. I would never keep our WordPress nearly as up-to-date as it is if it wasn't for the auto-updater. 09:27 < zixtor> chealer: agreed, would keep many users up to date 09:28 < chealer> It works perfectly here (but then, I have a single install, and it's on our server). 09:28 < zixtor> lets move to next 09:28 < Marc9> Users vs account was initiated by chealer 09:28 < Marc9> As a reminder, the menu tab was Privileges 09:28 < Marc9> I suggest "User accounts" 09:29 < zixtor> long reading ;) 09:30 < Marc9> Note that bug 4973 is about two issues 09:30 < zixtor> if I get it correctly, an Account is uniquely identified with User plus applicable Host. So I agree that we should use the word "Account" in the UI. 09:30 < Marc9> let's concentrate for now on the terminology issue 09:30 < zixtor> But I don't fully get the Anonymous user related point made in the RFE. 09:30 < chealer> thanks marc. I see there are 2 tab. the general one is titled "Users" here. but for a specific schema, the tab is titled "Privileges". 09:30 < ibennetch> I'm okay with changing to "User accounts" for the "Users" tab 09:31 < Marc9> chealer, here Privileges is the appropriate menu 09:31 < ibennetch> I'm not as sure about the specific table or database tab; as I think Privileges is a good description of what it shows (privileges on that object). 09:31 < Marc9> it's the privileges on some db 09:32 < Marc9> so, "User accounts", then under it, "Overview" and "Groups" ? 09:32 < chealer> Marc9: hum, I see a "Users" tab on demo.phpmyadmin.net, after I click the house for example 09:33 < ibennetch> I worry a bit about the size of the text. 09:33 -!- SPF|Cloud [uid11755@wikipedia/Southparkfan] has quit [Quit: Connection closed for inactivity] 09:33 < ibennetch> "User accounts" would be our longest tab here 09:34 < Marc9> chealer what's your point? 09:34 < chealer> ibennetch: I agree, I think "Accounts" would be OK even if "User accounts" is a bit clearer. 09:34 < ibennetch> On that page, we can talk about "Remove selected user accounts" or "User accounts overview", but I'm hesitant about changing the tab name 09:36 < ibennetch> For the tab only, I think "Users" is clear enough what is meant. Accounts just doesn't seem quite as clear, even though of course we're referring to the same thing I still like Users for the tab name. 09:36 < Marc9> that's why I wanted User accounts :) 09:37 < ibennetch> :) 09:37 < Marc9> also I gave a reference to MySQL manual where they clearly talk about accounts 09:38 < ibennetch> I've just tested and the space used for "User accounts" is long, but acceptable to me. 09:38 < ibennetch> I can go along with "User accounts" 09:39 < ibennetch> And yes, I realize that MySQL is making their terminology about accounts instead of users, so we should also try to keep up. 09:39 < Marc9> maybe in a future version we can remove "User" but keeping it right now is a good transition IMO 09:39 < ibennetch> So seems there's no further comment on the "User accounts" tab, should we discuss the anonymous user portion of this? 09:40 < ibennetch> Yes, good point. 09:40 < Marc9> ibennetch, this is not part of the meeting 09:40 < ibennetch> Okay 09:40 < ibennetch> Then we're on to the configuration storage naming scheme 09:40 < ibennetch> Some variables are without spaces/underscores, some have underscores. 09:41 < ibennetch> We should standardize moving forward. 09:41 < Marc9> I would prefer underscores 09:41 < zixtor> I would prefer the underscore config names for better readability. 09:41 < ibennetch> note that I'm not proposing changing existing variables, only moving forward. 09:41 < nijel> I also agree with underscores 09:42 < madhuracj> I also prefer having underscores 09:42 < ibennetch> Okay, thanks. I'll find somewhere to document that 09:42 < madhuracj> So I'll change the new config table name 09:42 < ibennetch> Finally about the CTRL-Enter to submit. 09:42 < ibennetch> Thanks madhuracj 09:43 < ibennetch> I think the CTRL-enter thing is very unobtrusive. 09:43 < Marc9> SF seems down right now 09:44 < zixtor> We should note that browser's implicit form submission mechanism (i.e. submit on pressing Enter) doesn't work not only for textarea but for dropdowns as well. So, quite different from console or grid edit, the Insert page is a raw form similar to many other forms across PMA, like db_qbe, tbl_search, tbl_structure, tbl_change (insert page) etc... Where ever we use anything apart from input text field. 09:44 < zixtor> So we may want to make a comprehensive change across PMA if we are dealing with it 09:44 < nijel> I like to have CTRL+enter working ... but preferably in all textareas (being addicted to this behaviour from GitHub) 09:46 < Marc9> While I might not use this often, I can understand why some need keyboard shortcut for any form submission, so I'm in favor 09:46 < zixtor> Also the existing PR also does it on any type of field present in the table tr. 09:46 < Marc9> nijel, would you say that ctrl+enter looks like becoming more popular? 09:47 < ibennetch> So if I'm on a non-textarea, I can use enter or ctrl-enter to submit, right zixtor ? 09:47 < ibennetch> (in the PR) 09:47 < zixtor> Right ibennetch 09:47 < nijel> Marc9: not sure how much, but I've seen it on several websites 09:48 < ibennetch> I think that's great. 09:48 < zixtor> so this may require comprehensive change all across similar forms in PMA 09:48 < Marc9> zixtor, you mean everywhere there is a textarea or drop-down? 09:49 < zixtor> Anywhere we have non input text fields 09:49 < zixtor> because Enter works in input text fields only I think 09:50 < Marc9> Maybe it can be done at the jQuery level, quite high (body) ? 09:50 < ibennetch> I can ask Deven to look in to incorporating that in to his pull request 09:50 < zixtor> yeah we can write it at high level, but handler will be for just the form elements ;) 09:50 < Marc9> ibennetch good idea 09:51 < ibennetch> We have less than ten minutes left in the meeting 09:51 < Marc9> zixtor yes, I just wanted the need to change a lot of scripts 09:51 < Marc9> should we discuss sf-related issues here (now that some publicity has been done) ? 09:52 < ibennetch> Is there some issue to discuss? 09:53 < ibennetch> I don't mind 09:53 < Marc9> tracker moving and mailing lists 09:54 < zixtor> I am well in favor of moving mailing lists to own server maybe 09:54 < ibennetch> I'm working on the mailing lists. 09:55 < ibennetch> That way we can integrate all of our lists -- team@ info@ and devel@ and so on all in one place. 09:55 < ibennetch> Still working on exporting the existing list membership and archives, so it's in progress but slower than I anticipated. 09:55 < Marc9> yes; I have asked Olivier about old team list archive 09:56 < zixtor> nice 09:56 < ibennetch> nijel has been quite helpful through my work as well. 09:56 < Marc9> about trackers, we were discussing about whether to move existing issues or not 09:56 < Marc9> (to github issues) 09:56 < ibennetch> Four minutes in the official meeting; I can stay a bit later myself. 09:57 < nijel> I don't think we can get rid of the backlog quickly and using two trackers at the same time might be confusing.... 09:57 < ibennetch> Yeah, this is a difficult issue no matter what. Ideally we would be able to automate moving the issues and leaving a link to the new issue tracker, but I think we weren't sure whether that could be automated. 09:58 < ibennetch> Even if we could clear the backlog, I think we should have historical items around -- closed as "wont-fix" for instance. 09:58 < Marc9> to remove confusion, on github this is called Issue, which is more neutral than bugs or rfe 09:59 < Marc9> I would be able to live with two systems 09:59 < ibennetch> Surely we're not the first to try this. I wonder if github has any suggestions. 10:00 < Marc9> would it be confusing to have in the Changelog, bug #1000 and issue #1000 ? 10:01 < chealer> sorry, back from the fire 10:02 < chealer> Marc9: quite likely :-| 10:02 < madhuracj> I feel it would be less confusing to only have the new issue numbers 10:02 < chealer> I guess there could be a note about it at the top, or URL-s could be used for a while. 10:03 < Marc9> madhuracj please clarify 10:04 < madhuracj> In out website we can point users to the GitHub issue tracker and only use issue numbers 10:04 < Marc9> madhuracj you mean after moving all old issues, right? 10:04 < madhuracj> If someone is refering to the old changelogs we can place a link in SF trackers pointing to the new GitHub tracker 10:04 < madhuracj> Yes 10:05 < nisargjhaveri> I think, it would be better if everything is at one place. 10:05 < Marc9> madhuracj but we did not find a way to automate this linking 10:05 < nisargjhaveri> Also, automation should be possible, at the very least some crawling should work? 10:06 < Marc9> if automation is not possible, I volunteer to do a manual linking, but only for currently open bug and rfe artifacts :) 10:07 < chealer> does GitHub allow bumping the next issue number (to SourceForge's)? 10:07 < Marc9> (that is, if the move script works correctly) 10:07 -!- gigo1980_ [~gigo1980@pD954D713.dip0.t-ipconnect.de] has joined #phpmyadmin 10:07 < nijel> automation should be possible, but would require some scripting - there is SF.net API to add comments 10:09 < Marc9> is the goal to move all artifacts, or just open ones? 10:11 < ibennetch> I have doubts about whether we'll be able to also migrate comments, and if we update all of the sf tracker items with the new URL that will be a lot of email notifications. I'm uncertain of what I think the best path should be. 10:11 < nijel> I'd move all if possible (to have everything in one place) 10:11 < ibennetch> I agree that moving everything is ideal. 10:12 -!- gigo1980_ [~gigo1980@pD954D713.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] 10:13 < nisargjhaveri> I can probably help with automating whatever is possible. 10:13 < Marc9> nisargjhaveri what would be your time frame? 10:14 -!- Dragooon [~shitizgar@simplemachines/customizer/Dragooon] has joined #phpmyadmin 10:14 < ibennetch> I do suggest first asking Github if they have any tools to make this easier, but at the same time realize that's rather unlikely. 10:14 < Marc9> ibennetch I had forgotten about the email notifications 10:15 < nisargjhaveri> Marc9, Not sure. If someone else is willing, please do it. :) 10:15 < Marc9> nijel, do you believe it's possible to test the moving script, to a dummy repo ? 10:15 < nijel> I've just found this: https://github.com/cmungall/gosf2github, which also allows mapping usernames 10:16 -!- SPF|Cloud [uid11755@wikipedia/Southparkfan] has joined #phpmyadmin 10:16 < Marc9> I would like to see what happens when we move two different trackers (bug, rfe) to one issue system 10:16 < nijel> Marc9: we should definitely test it on separate repo (preferably in someones home, so it does not look official) 10:18 < Marc9> Note that the API does not grant permission to create the tickets as 10:18 < Marc9> if they were created by the original user, so if your token was 10:18 < Marc9> generated from your account, it will look like you submitted the 10:18 < Marc9> ticket and comments. 10:18 < Marc9> this is for gosf2github 10:20 < Marc9> labels look fine :) https://github.com/nijel/weblate/issues 10:20 < nijel> yes, the tickets and comments would be created by the bot, the (mapped) user is mentioned in comment text 10:20 < chealer> hehe, "newbie" 10:21 < Marc9> nijel I see 10:21 < Marc9> nijel do you want to test this newly found script? 10:22 < Marc9> Also, would we keep the old tickets in place, so that the links in older changelogs still work? 10:22 < chealer> of course, if open issues are not moved, there's a higher risk of getting duplicates (unless a warning to users can be displayed) 10:24 < Marc9> chealer we will close submission for new tickets on sf 10:25 < nijel> Marc9: I can test the script and see how it works 10:25 < chealer> Marc9: yes. I mean if I go search for an issue I am experiencing on GitHub and don't find it, I may report it even if it exists on SF. so I waste my time, and developers too. 10:25 < Marc9> nijel good; it looks more promising than the other script 10:26 -!- Dragooon [~shitizgar@simplemachines/customizer/Dragooon] has quit [Quit: My Mac has gone to sleep. ZZZzzz...] 10:26 < nijel> it would be great if somebody could look into option to add comments to sf.net trackers 10:26 < Marc9> chealer true but we already have this problem; the real problem is our backlog 10:27 < Marc9> nijel, even if this generates tons of email notifications? 10:29 < madhuracj> Only the developers will get tons of emails, right? Others will only get emails for their issues. 10:30 < nisargjhaveri> We can tell people to unsubscribe for a while? :P 10:30 < nisargjhaveri> Or if we migrate mailing lists also, can we filter it after that? 10:30 < Marc9> madhuracj I'm not sure how the tracker mailing lists work 10:31 -!- zixtor [31f9bc5e@gateway/web/freenode/ip.184.108.40.206] has quit [Ping timeout: 246 seconds] 10:32 < Marc9> I have to leave soon 10:32 < ibennetch> Users can subscribe to the entire mailing list for each of the trackers. How many people did so I have no idea. 10:32 < ibennetch> Whether project administrator can see that through SourceForge I don't know. 10:32 < ibennetch> (can see the list of users, I mean) 10:32 < ibennetch> Otherwise, people only get notifications of their issues) 10:33 < Marc9> 34 subscribers to the bugs tracker list 10:33 < Marc9> 14 for the rfe tracker list 10:34 < Marc9> bye all 10:34 -!- zixtor [31f9bdd3@gateway/web/freenode/ip.220.127.116.11] has joined #phpmyadmin 10:34 -!- Marc9 [~firstname.lastname@example.org] has quit [Quit: Leaving] 10:34 < ibennetch> By Marc9 Thanks for the info 10:34 -!- nisargjhaveri is now known as nisargjh|cloud 10:34 < zixtor> Bye all 10:34 -!- madhuracj [~email@example.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 10:35 -!- zixtor [31f9bdd3@gateway/web/freenode/ip.18.104.22.168] has left #phpmyadmin  10:36 -!- nisargjh|cloud is now known as nisargjhaveri 10:37 -!- nisargjhaveri is now known as nisargjh|cloud 10:38 < chealer> bye 10:39 < ibennetch> by chealer thanks for attending 10:39 -!- chealer [~pcloutier@pdpc/supporter/student/chealer] has left #phpmyadmin  10:43 < ibennetch> Thanks to all for attending
Clone this wiki locally
Press h to open a hovercard with more details.