| ../irclogs/#mantishelp.2009-11-05.log | ||
| --- scribe started --- | 00:00 | |
| CIA-22 | Mantisbt: vboctor * re580d34cf917 /core/file_api.php: Fixes #11117: Unable to get files attached to ALL_PROJECTS - thanks to watergad. | 04:04 |
|---|---|---|
| CIA-22 | Mantisbt: vboctor master-1.2.x * r0b7510c09713 /core/file_api.php: Fixes #11117: Unable to get files attached to ALL_PROJECTS - thanks to watergad. | 04:04 |
| CIA-22 | Mantisbt: vboctor * r3af3ab3e1af6 /core/authentication_api.php: Fixes #11125: Auto-focus on password field when re-authenticating address. | 07:03 |
| CIA-22 | Mantisbt: vboctor master-1.2.x * rf9de1f5a2d98 /core/authentication_api.php: Fixes #11125: Auto-focus on password field when re-authenticating address. | 07:04 |
| CIA-22 | Mantisbt: vboctor * r9d2ebf2fc8e9 /core/filter_api.php: Fixes #11124: The 'sticky_issues' value stored in the mantis_filter_table is not always stored correctly. | 07:17 |
| CIA-22 | Mantisbt: vboctor master-1.2.x * r9025cc676b2d /core/filter_api.php: Fixes #11124: The 'sticky_issues' value stored in the mantis_filter_table is not always stored correctly. | 07:20 |
| CIA-22 | Mantisbt: hickseydr master-1.2.x * r896c5e52a926 / (41 files in 9 dirs): Merge branch 'master-1.2.x' of mantisbt.org:mantisbt into master-1.2.x | 07:20 |
| dhx_m | doh | 07:20 |
| vb123 | hi | 07:51 |
| vb123 | dhx_m: ? | 07:51 |
| dhx_m | vb123: hi :) | 08:03 |
| vb123 | hi dhx_m | 08:06 |
| dhx_m | nice to see you on IRC :) | 08:06 |
| dhx_m | your new plugin is quite interesting | 08:07 |
| vb123 | I haven't been on it for a while. | 08:07 |
| vb123 | glad you liked it. | 08:07 |
| vb123 | did you see the refreshed version? | 08:07 |
| dhx_m | I was looking at similar things just a short while ago (Ubiquity from Mozilla, OpenCog, etc) | 08:07 |
| dhx_m | yep | 08:07 |
| dhx_m | btw thanks for fixing the sticky issues bug | 08:10 |
| dhx_m | that one has been frustrating me for ages heh | 08:10 |
| vb123 | no worries about the filtering bug. | 08:10 |
| vb123 | I hate filtering though! | 08:10 |
| vb123 | this one counts as 2 ;) | 08:10 |
| dhx_m | one of the reasons I didn't fix it myself before :p | 08:10 |
| vb123 | relating to MantisCmd | 08:10 |
| vb123 | I'm thinking of "f filtername" to activate a saved filter. | 08:10 |
| vb123 | rather than specifying the filtering on the command line itself. | 08:10 |
| vb123 | this is in addiition to common filters like "mine" | 08:10 |
| dhx_m | instead of implementing filters into the command line... | 08:10 |
| dhx_m | such as "delete all issues with a priority higher than normal" | 08:10 |
| dhx_m | or "view all issues with a target version of 1.2.0" | 08:10 |
| vb123 | I was referring to the latter. | 08:11 |
| dhx_m | that seems to be what Ubiquity and other similar native language command prompts are heading towards | 08:11 |
| dhx_m | hmm | 08:11 |
| dhx_m | so it'd be a two step process to filter in your case? | 08:11 |
| dhx_m | ie. | 08:11 |
| dhx_m | f some-saved-filter | 08:11 |
| dhx_m | v | 08:11 |
| dhx_m | (now you see a list of issues matching the filter) | 08:11 |
| dhx_m | d * | 08:11 |
| dhx_m | (now you're asked to confirm that all issues shown should be deleted?) | 08:12 |
| dhx_m | etc | 08:12 |
| vb123 | correct | 08:12 |
| vb123 | that would keep the language simpler | 08:12 |
| dhx_m | I can see how that works, seems quite reasonable to me | 08:12 |
| dhx_m | instead of specifying long complex commands | 08:12 |
| dhx_m | you instead ask people to enter short commands to filter things down | 08:13 |
| dhx_m | makes sense to me | 08:13 |
| vb123 | you can still has filter xxx yyy hhh jjjjj | 08:13 |
| vb123 | but filter is separate from deletee | 08:13 |
| dhx_m | yep | 08:13 |
| dhx_m | so you start with "all issues" (or a default filter) | 08:13 |
| dhx_m | and then to perform actions on multiple issues | 08:14 |
| dhx_m | you apply filters one by one, updating the list of issues as you go | 08:14 |
| dhx_m | until you get down to just the issues you're interested in | 08:14 |
| dhx_m | rather than start with all issues and specify all the filter arguments as one long complex line of commands? | 08:14 |
| vb123 | scope then execute | 08:15 |
| vb123 | yes | 08:15 |
| dhx_m | yep | 08:15 |
| dhx_m | that way you can also save progress as you go | 08:15 |
| dhx_m | and get back to it quickly | 08:15 |
| vb123 | commands have simple scopes like: none (like mu to default to current user), mu vboctor (simple scope), mu * (* for issues would be all matching current filter). | 08:16 |
| vb123 | mu is a bad example. | 08:16 |
| dhx_m | I understand though | 08:16 |
| vb123 | actually "mu *" can redirect you to Manage Users page. | 08:16 |
| dhx_m | it's one command at a time, rather than dealing with piping and logic operations, etc | 08:16 |
| dhx_m | it'd be neat if the commands could be made fairly similar between pages | 08:17 |
| dhx_m | so "mu" to switch to the manage users view | 08:17 |
| vb123 | what do you mean? | 08:17 |
| dhx_m | then you apply filters in the same way you'd apply them to bugs | 08:17 |
| dhx_m | and the shortcut keys to delete/edit users would match that of bugs | 08:17 |
| dhx_m | so: | 08:17 |
| vb123 | mu v* | 08:18 |
| dhx_m | mu (switch to manage users mode) | 08:18 |
| vb123 | filtering users can work if we support this i nthe first place. | 08:18 |
| dhx_m | f name=david (or some other way to add a filter) | 08:18 |
| dhx_m | d (delete all users named david) | 08:19 |
| dhx_m | which would be similar to handling bugs in that "f" and "d" commands are the same | 08:19 |
| dhx_m | and one doesn't need to remember that bd = bug delete, ud = user delete, etc | 08:19 |
| vb123 | I'm attempting to limit the commands to be shortcuts to features that are already supported. | 08:19 |
| vb123 | so all the functionality / access checks are done in the core code. | 08:20 |
| vb123 | the cmd processor just redirects to a URL. | 08:20 |
| dhx_m | yeah I like that :) | 08:20 |
| dhx_m | but it always has to redirect to a confirmation page doesn't it? | 08:20 |
| dhx_m | otherwise you'd get issues with CSRF tokens | 08:20 |
| vb123 | for actions like delete, yes. Unless we hace some force flag. | 08:21 |
| vb123 | url pages have to protect themselves anyway, and hence, CSRF is not a specific issue for MantisCmd. | 08:22 |
| dhx_m | yep | 08:22 |
| dhx_m | but for something like bug_stick.php and bug_unstick.php | 08:22 |
| dhx_m | those are commands without user confirmation | 08:22 |
| dhx_m | yet they still use CSRF | 08:22 |
| dhx_m | so we'd really need bug_stick_page.php and bug_unstick_page.php in the middle to make it work with MantisCmd | 08:23 |
| vb123 | you mean the tokens? | 08:23 |
| dhx_m | yep | 08:23 |
| dhx_m | Mantis should really be forcing CSRF tokens to be used whenever data is sent via POST | 08:23 |
| vb123 | we will have to work around this. | 08:23 |
| vb123 | so far the cmdline uses only GET | 08:24 |
| dhx_m | and POST should be used whenever we're modifying any data within Mantis | 08:24 |
| dhx_m | yep, GET/view is OK | 08:24 |
| vb123 | I would rather have a smaller set of actions that apply changes. For example, pick 123 to self assign. | 08:25 |
| vb123 | resolve 123 | 08:25 |
| vb123 | btw, do you want access to the MantisCmd repo? | 08:26 |
| dhx_m | back sorry | 08:46 |
| dhx_m | yeah I'd be interested in adding some commands, it looks quite simple to do | 08:47 |
| dhx_m | I guess it is a case of conventions for command naming, etc | 08:47 |
| dhx_m | one suggestion is to create an array of commands with multiple columns | 08:49 |
| dhx_m | ie. | 08:49 |
| dhx_m | hmmm scrap that ;) | 08:50 |
| vb123 | dhx_m: I've added you to MantisCmd. | 09:31 |
| dhx_m | cool, I'll see what I can do :) | 09:33 |
| dhx_m | I'm a little busy until the later part of November though | 09:34 |
| dhx_m | which is why I haven't committed much lately | 09:34 |
| vb123 | no worries!' | 09:38 |
| dhx_m | it's been good to see quite a lot of commits lately | 09:39 |
| dhx_m | 1.2.0 final is looking like it'll be quite solid | 09:39 |
| dhx_m | it's getting a lot of testing | 09:39 |
| vb123 | yep, I actually think we should think of 1.2.0 final or at least rc3 very soon. | 09:40 |
| vb123 | The bug that is blocking in my mind is that if you logout, then use a link like http://www.mantisbt.org/bugs/view.php?id=11111 ---you will be asked to login even though our bug tracker supports anonymous login. | 09:41 |
| dhx_m | wasn't that fixed recently? I can't remember for sure though | 09:42 |
| vb123 | I got the impression from John that it is fixed. However, it still doesn't work on our live instance. | 09:43 |
| vb123 | nuclear_eclipse: what's up with the above issue? | 09:43 |
| dhx_m | hmm yeah it still is a problem I see | 09:47 |
| dhx_m | 11088 is also highly user visible | 09:47 |
| dhx_m | bug 11088 | 09:47 |
| * nuclear_eclipse wishes Victor didn't wait until 4AM to get online... | 13:43 | |
| dhx_m | :) | 13:45 |
| CIA-22 | Mantisbt: jreese master-1.2.x * r2aac6b773a75 /core/plugin_api.php: Fix #11090: NOTICE when soft dependencies not met | 14:17 |
| CIA-22 | Mantisbt: jreese * rb0b8cd4b5b03 /core/plugin_api.php: Fix #11090: NOTICE when soft dependencies not met | 14:17 |
| paulr_ | moo | 20:07 |
| paulr_ | john? | 20:07 |
| vb123 | nuclear_eclipse: are you there? | 20:12 |
| vb123 | I've reported several issues again product matrix php notices. | 20:12 |
| nuclear_eclipse | hi vb123 | 20:13 |
| vb123 | you either don't have error reporting set or it is not taking effect on the plugins code. | 20:13 |
| vb123 | can you fix mantisbt code to make sure we have the strict error reporting by default and that helps surface the errors I reported. | 20:13 |
| nuclear_eclipse | there are pieces of plugin code that was not originally written by me, so likely cause is that the other devs didn't change their error reporting settings | 20:13 |
| vb123 | that makes a sense then. | 20:14 |
| paulr_ | it's up to dev's to set error reporting imo | 20:14 |
| vb123 | however, I can tell you the experience is going to be bad for users who have error reporting on. All plugins have notices. | 20:14 |
| nuclear_eclipse | bug 11090 was just a simple problem of "not enough testing" :P | 20:14 |
| paulr_ | in a production site | 20:14 |
| paulr_ | shouldn't really have error reporting on | 20:14 |
| vb123 | I'm OK with disabling it on production, but we should have them on by default for dev. | 20:15 |
| vb123 | In the past we have suggested a developer mode that enables error reporting by default. | 20:15 |
| paulr_ | dev's should really be able to turn on php error reporting | 20:15 |
| vb123 | For example, auto set to developer mode if URL contains localhost or 127.0.0.1 | 20:15 |
| paulr_ | it's not really *that* hard to set up php etc | 20:16 |
| vb123 | We managed to get our core team into this habbit, but it would be easier if the plugin developers get this by default. | 20:16 |
| paulr_ | (you need to set up php to report errors anyway | 20:16 |
| nuclear_eclipse | vb123: that wouldn't always work -- I have to list my hostname rather than localhost | 20:16 |
| vb123 | nuclear_eclipse: I agree it is not perfect. However, it is better than nothing. | 20:16 |
| vb123 | I personally think we should have ON by default even in production. | 20:17 |
| paulr_ | erm, no | 20:17 |
| paulr_ | do you run your production asp.net sites in debug/trace mode? :) | 20:17 |
| vb123 | no I don't, by we have detailed error reporting that we can set as off by default. | 20:17 |
| paulr_ | the thing is | 20:17 |
| paulr_ | if you install php | 20:17 |
| vb123 | however, I would still get the exception / error on production. | 20:17 |
| paulr_ | you have the option at that point to configure php.ini for debug type stuff | 20:18 |
| paulr_ | you have option in config | 20:18 |
| paulr_ | I think if someone is going to write a plugin | 20:18 |
| paulr_ | we should be able to consider them able to install php | 20:19 |
| paulr_ | with some sensible settings | 20:19 |
| paulr_ | if they can't | 20:19 |
| paulr_ | there's a good chance the plugin will be crap and full of issues | 20:19 |
| vb123 | ok, we have a lot of crap then on git.mantisforge.org | 20:20 |
| paulr_ | i'm hesitant to add logic to dynamically try and detect whether ones in debug mode | 20:21 |
| paulr_ | as tbh | 20:21 |
| paulr_ | it's something someone dev'ingphp should really be able to set | 20:21 |
| vb123 | at least we should have one config option that tunes MantisBT to dev vs production environment. | 20:22 |
| paulr_ | personally, I often find when dev'ing I end up needing to disable our error handler completely | 20:23 |
| paulr_ | as it gets in the way | 20:23 |
| vb123 | in the way of what? doesn't it tell you about errors that might be hard to find otherwise? | 20:24 |
| paulr_ | no | 20:24 |
| paulr_ | as I turn our handler off | 20:24 |
| paulr_ | and just use xdebug | 20:24 |
| paulr_ | on it's own | 20:24 |
| paulr_ | in some cases, i've had our error handler make things more difficult | 20:25 |
| paulr_ | the only thing our error handler does | 20:25 |
| paulr_ | is generate a nice pretty webpage when an error occurs (or try to) | 20:25 |
| paulr_ | I dont really need/want that | 20:25 |
| paulr_ | I just want the error details | 20:25 |
| paulr_ | plain text suffices | 20:25 |
| vb123 | ok, that's fine. I just want the average php developer to find out about their errors. | 20:26 |
| vb123 | I expect a lot of average developers to develop plugins that will affect the quality of MantisBT. | 20:26 |
| vb123 | so at least, I would like to avoid breaking MantisBT. I'm ok with their plugin being broken. | 20:27 |
| paulr_ | I guess the question is whether one considers a warning to a be a break | 20:27 |
| vb123 | even thought I would hope it won't be broken in a way that puts security holes. | 20:27 |
| vb123 | in my environment it is. | 20:27 |
| paulr_ | I'm just thinking | 20:27 |
| paulr_ | I tend to run php-next-version | 20:27 |
| paulr_ | tends to generate new warnings ;/ | 20:28 |
| paulr_ | it probably really requires guidance on what we have available atm | 20:28 |
| paulr_ | if anything | 20:28 |
| paulr_ | we need to drop some config variables | 20:28 |
| paulr_ | where we allow micro-management of warnings/debug etc | 20:29 |
| paulr_ | and just ahve a 'debug mode?' yes/no | 20:29 |
| vb123 | yes, I think we should have a debug mode. | 20:29 |
| vb123 | we can then have the error reporting on set when debug mode = true. | 20:29 |
| vb123 | only set | 20:29 |
| vb123 | with all settings as 'halt'. | 20:30 |
| paulr_ | the problem really comes when some lib we use generates a warning | 20:30 |
| paulr_ | tbh | 20:30 |
| paulr_ | most of mantis code doesn't generate warnings | 20:30 |
| paulr_ | (at least not for very long) | 20:31 |
| vb123 | agreed. early versions of MantisBT used to generate a lot of warnings until we started using the strict error reporting. | 20:32 |
| vb123 | the tricky part is that when we use non-core MantisBT core (via libraries or plugins) in our environment, we will probably get some warnings. | 20:32 |
| paulr_ | nod | 20:32 |
| paulr_ | and the question is whether we start fixing those | 20:33 |
| * giallu is around | 20:33 | |
| paulr_ | (for most part, php warnings are fairly obvious fixeS) | 20:33 |
| vb123 | do we log the errors at the moment? similar to logging emails, ldap, etc? | 20:33 |
| paulr_ | not sure | 20:33 |
| vb123 | the fixes are obvious, but they can cause the wrong behavior until they are fixed. Hence, it is important to see them. | 20:33 |
| vb123 | Maybe we should make the error handler always log the errors, which can be viewed using the EventLog plugin or by directing to a file. | 20:34 |
| paulr_ | seems a bit pointless or well | 20:34 |
| paulr_ | tbh | 20:34 |
| paulr_ | depends who your thinking of | 20:35 |
| paulr_ | i'd kinda expect core devs to have a clue | 20:35 |
| paulr_ | end users dont really need to see errors + shouldn't get | 20:35 |
| paulr_ | so the question is, are we saying plugin authors dont have a clue? | 20:35 |
| vb123 | Eventlog would only be accessible to developers / admins. | 20:35 |
| vb123 | we can ask them to look at it as part of support. | 20:35 |
| paulr_ | it's just fairly rare our code actually generates warnings | 20:36 |
| paulr_ | we tend to throw enough at it ;) | 20:36 |
| vb123 | plugin developers have a clue, they develop a plugin, it works, they publish it. They don't have as much experience on getting this to work robustly on all environments, without warnings, etc. | 20:36 |
| paulr_ | nof | 20:36 |
| paulr_ | nod | 20:36 |
| paulr_ | what i need to do however at some point soon | 20:37 |
| vb123 | note that our core code gets tested a lot compared to plugins. At least, I'm referring to testing in dev environment. | 20:37 |
| vb123 | that is why I decided to download all plugins and give them a try. | 20:37 |
| paulr_ | is try to merge th current ldap api with my work version ;/ | 20:37 |
| paulr_ | so I can upgrade mantis at work | 20:37 |
| vb123 | yep, I've done a lot of fixes in LDAP. | 20:37 |
| vb123 | The main thing that we are missing now, is the ability to connect to multiple OUs or LDAP servers. | 20:37 |
| paulr_ | i'm not sure i'm happy with some of them | 20:37 |
| * paulr_ has support for multiple ou's | 20:38 | |
| paulr_ | I think the new code might generate more queries | 20:38 |
| vb123 | You should port this into core then. | 20:38 |
| vb123 | which part are you referring to? | 20:38 |
| vb123 | that will generate more queries. | 20:38 |
| paulr_ | I need to checkb | 20:38 |
| paulr_ | but when I read it in july, I noted it down in notebook as something to check | 20:39 |
| vb123 | ok. | 20:39 |
| vb123 | I think the main changes were: | 20:39 |
| vb123 | 1. Added simulation mode which allowed me to find and fix issues with MantisBT when using LDAP. Doesn't test integration with LDAP iteself. | 20:40 |
| paulr_ | incidently - the thing I dont like is having some simulation thing in the main ldap api file | 20:40 |
| paulr_ | we should have a copy of ldap api for that | 20:40 |
| vb123 | 2. Update native fields on login form LDAP to remove LDAP knowledge after knowledge. | 20:40 |
| vb123 | native fields like email and realname. | 20:40 |
| vb123 | 3. auto-creation of MantisBT on first login of LDAP users. | 20:41 |
| paulr_ | in fact, now i remember :) | 20:44 |
| vb123 | ? | 20:45 |
| paulr_ | ldap_escape_string I believe is incomplete | 20:45 |
| paulr_ | storing an md5 hash of an ldap password in db is a security risk | 20:46 |
| paulr_ | the point of using ldap would be so you dont have passwords stored elsewhere in less secure formats | 20:46 |
| paulr_ | I think where we changed the way we abstract the api calls they could lead to more calls, or at least if we collapsed them back down, I reckon we could reduce number of ldap calls and add functionality | 20:47 |
| vb123 | We can have the LDAP storage of password as optional. | 20:47 |
| paulr_ | are people requesting it? | 20:47 |
| paulr_ | it seems kinda silly to add | 20:47 |
| paulr_ | as what happens atm if someone uses SHA1() or whatever for auth and ldap | 20:48 |
| vb123 | The question is whether we support hybrid of LDAP / normal or not. And whether we want to support switching from LDAP to completely native. | 20:49 |
| vb123 | I think we need to have a per user auth mode and a global auth mode | 20:49 |
| vb123 | On user login, we convert the user to the global mode. | 20:49 |
| vb123 | we could also have a couple of global auth modes. For example, LDAP + MD5. | 20:49 |
| vb123 | LDAP users would continue to use LDAP, otherwise, they will be converted to MD5 (e.g. from plain) | 20:49 |
| paulr_ | but that's something to do when doing auth plugin's imo | 20:50 |
| paulr_ | not now | 20:50 |
| vb123 | Correct :) --- is this happening anytime soon? | 20:50 |
| paulr_ | i've not touched much for about 2-3 months now, although starting to find more time | 20:51 |
| vb123 | great. | 20:51 |
| paulr_ | my main issue atm is i want to try and make db stuff work realiably | 20:51 |
| paulr_ | been looking at moodle's approach | 20:51 |
| vb123 | I'm assuming you are planning this for 1.3.x | 20:51 |
| paulr_ | as dhx/john know | 20:51 |
| paulr_ | moodle moved from adodb to their own abstraction gpl laye | 20:51 |
| paulr_ | well | 20:51 |
| paulr_ | we've branched | 20:51 |
| paulr_ | trunk and 1.2 | 20:51 |
| paulr_ | so yes | 20:52 |
| paulr_ | it's something for trunk | 20:52 |
| vb123 | agreed. I just want to make sure we don't port to 1.2.x | 20:52 |
| paulr_ | we've already ported too much imo | 20:52 |
| vb123 | also to avoid very big changes until 1.2.0 gold is out. To keep the merging simple. | 20:52 |
| vb123 | the best way to avoid porting too much is to get 1.2.0 released. | 20:53 |
| paulr_ | we've added new features into 1.2 since rc2 | 20:53 |
| paulr_ | which is stupid | 20:53 |
| vb123 | whick ones r y refering to? | 20:54 |
| paulr_ | or even rc1 | 20:54 |
| paulr_ | lets see | 20:54 |
| paulr_ | 2009-10-06John Reese | 20:54 |
| paulr_ | to be fair | 20:55 |
| paulr_ | probably more since rc1 then rc2 | 20:55 |
| vb123 | correct, that is my feeling too. | 20:55 |
| vb123 | we need help in closing 1.2.0 if you have cycles. | 20:56 |
| vb123 | including untargetting issues from 1.2.x | 20:56 |
| paulr_ | since the bump to 1.3.0dev on trunk (11th July 2009) | 20:56 |
| paulr_ | i've only got around to reviewing commits | 20:57 |
| paulr_ | i've got a list of 19 things I want to check based on those commits | 20:57 |
| paulr_ | :( | 20:57 |
| vb123 | i actually think we should have 1.2.0 on the roadmap and 1.2.x. | 20:57 |
| vb123 | 1.2.0 are the musts before releasing 1.2.0 | 20:57 |
| vb123 | 1.2.x is for dot builds after then. | 20:57 |
| paulr_ | for example | 20:58 |
| paulr_ | http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff;h=61804a9da622dd0519fea853924bdab5bddbd933 | 20:58 |
| paulr_ | changing the logic of ini_set | 20:58 |
| paulr_ | when reading that I thought at first glance that it would break compression on iis | 20:59 |
| paulr_ | I think I then concluded it doesn't, but whilst concluding that that using the 'recommended' settings for compression handlers | 20:59 |
| paulr_ | that it breaks that error handler | 20:59 |
| paulr_ | and whilst trying to work out if that is actually the case, needing to diagnose ob_* calls | 21:00 |
| paulr_ | which then lead to concluding that the utf8 lib calls ob_* every time it's called (aka a few thousand times) | 21:00 |
| paulr_ | so I first need to replace some of the utf8 library functions with my own version so I can work out why the error handler broke | 21:01 |
| paulr_ | which is a nice fun exercise | 21:01 |
| paulr_ | which may as well lead to why the utf8 library varies output of functions to php6/perl utf8 functions | 21:02 |
| paulr_ | maybe | 21:51 |
| paulr_ | we should run an ldap.mantisbt.org service | 21:51 |
Generated by irclog2html.py