| ../irclogs/#mantishelp.2009-04-17.log | ||
| --- scribe started --- | 00:00 | |
| * daryn_away is away: Gone away for now | 04:48 | |
| dhx_m | this resolution field is broken :( | 04:58 |
|---|---|---|
| dhx_m | all the resolutions are hardcoded into Mantis | 04:58 |
| dhx_m | I've been thinking that there should be a few thresholds introduced | 04:59 |
| dhx_m | bug_resolved_resolution | 04:59 |
| dhx_m | bug_closed_resolution | 04:59 |
| dhx_m | or something like that | 04:59 |
| dhx_m | where resolution < bug_resolved_resolution denotes an open ticket resolution | 05:00 |
| dhx_m | bug_resolved_resolution <= resolution < bug_closed_resolution denotes a fixed ticket (successfully completed) | 05:00 |
| dhx_m | resolution >= bug_closed_resolution denotes a ticket that was not fixed (not completed) | 05:01 |
| dhx_m | I don't know what good names would be | 05:04 |
| daryn_away | dhx_m what do you mean resolutions are hard coded? you can configure all of them and the resolved resolution is configurable as well...not sure about closed | 05:05 |
| dhx_m | core/summary_api.php: | 05:06 |
| dhx_m | # These resolutions are considered fixed | 05:06 |
| dhx_m | if( FIXED == $c_res_s[$j] ) { | 05:06 |
| dhx_m | and there is a similar line below that to denote which resolutions are deemed "not fixed" | 05:06 |
| daryn_away | hm | 05:06 |
| dhx_m | afaik, there isn't any resolution threshold at the moment | 05:06 |
| dhx_m | except for reopening bugs | 05:07 |
| dhx_m | FIXED is widely used throughout the code | 05:07 |
| daryn_away | you can configure all of the enum strings...so you at least could fake it | 05:07 |
| dhx_m | effectively making custom enum of the resolution field useless/dangerous | 05:08 |
| dhx_m | I've always been confused about the difference between RESOLVED and CLOSED in Mantis | 05:08 |
| dhx_m | in my setup, RESOLVED is used for tickets that have been completed | 05:09 |
| dhx_m | CLOSED is used for tickets that weren't completed | 05:09 |
| dhx_m | is that the intention? | 05:09 |
| daryn_away | well i haven't been around forever but my understanding is that resolved is...devs have resolved the problem | 05:10 |
| daryn_away | closed means...customer has accepted the solution/fix | 05:10 |
| dhx_m | ok, that makes sense | 05:10 |
| daryn_away | or...resolution if it wasn't fixed | 05:10 |
| daryn_away | there is a bit of crossover between status and resolution though...i bit confusing | 05:11 |
| dhx_m | yep, agreed... I think the resolution field is fairly useless in my setup | 05:11 |
| dhx_m | I'd much rather use statuses to indicate the state of a bug | 05:12 |
| dhx_m | rather than a mix of status and resolution | 05:12 |
| dhx_m | $g_bug_resolution_fixed_threshold = RESOLUTION_FIXED; | 05:15 |
| dhx_m | $g_bug_resolution_not_fixed_threshold = RESOLUTION_UNABLE_TO_DUPLICATE; | 05:15 |
| dhx_m | I was thinking of those two thresholds | 05:15 |
| dhx_m | this allows people to set custom resolutions for open, fixed and not fixed bugs | 05:15 |
| dhx_m | and you can have multiple resolutions in those ranges | 05:16 |
| dhx_m | although I would suggest changing the custom order of resolutions so "REOPENED" comes after "OPEN" | 05:16 |
| dhx_m | that would completely break upgrading though :( | 05:17 |
| daryn_away | dhx_m could probably write a conversion script | 05:32 |
| dhx_m | yep, I'll leave it for now to make it easier | 05:33 |
| dhx_m | my current patch will be backwards compatible as such | 05:33 |
| dhx_m | I doubt enough people use the resolution field to care | 05:35 |
| daryn_away | :) | 05:35 |
| daryn_away | they'll care if you break it | 05:35 |
| dhx_m | yep, which is something I'm trying to avoid at the moment :) | 05:36 |
| daryn_away | way past bedtime in CST...night all | 05:39 |
| dhx_m | cya :) | 05:41 |
| dhx_m | OK my branch should be complete and ready to pull from http://git.mantisforge.org/w/mantisbt/dhx.git?a=shortlog;h=refs/heads/10330 | 09:58 |
| dhx_m | initial testing says it is OK... but I haven't tested all the new configuration options yet | 09:58 |
| kenguest | moin | 10:07 |
| dhx_m | hey | 10:07 |
| kenguest | jusst checking in ;-) | 10:07 |
| kenguest | which of the latest releases should I use? the 1.1 or 1.2 tree? | 10:08 |
| kenguest | and is there a plug-in for Evolution yet? ;-) | 10:08 |
| dhx_m | depends on what you want to do... I'd recommend 1.2 because it has loads of bugs fixed, new features galore and you can use all the plugins that are now available | 10:09 |
| dhx_m | however it is generally considered less tested... | 10:09 |
| dhx_m | and I haven't heard anything about an Evolution plugin? | 10:09 |
| dhx_m | what exactly would that entail? | 10:09 |
| kenguest | it'd probably entail me writing it ;-) | 10:10 |
| kenguest | there's a "Task" manager section in Evolution that's got a kinda dumbed down interface. | 10:10 |
| kenguest | allows bare-bones entry of tasks | 10:10 |
| kenguest | thought it might be an interesting addition | 10:11 |
| dhx_m | how would you interface between Mantis and Evolution? | 10:11 |
| dhx_m | it sounds to me like the only easy way that'd work is if you write an Evolution plugin that polls your Mantis installation | 10:11 |
| kenguest | http component, config screen for url & login details | 10:12 |
| dhx_m | unless.. can you add tasks automatically via email? | 10:12 |
| kenguest | ooh. well I've just written an email parser for our new document management system. | 10:12 |
| kenguest | is something like that in mantis? email parsing? | 10:12 |
| dhx_m | usually with Mantis, you'd write a plugin which is called via a plugin hook whenever something interesting happens | 10:13 |
| dhx_m | ie. new bug, updated bug, etc | 10:13 |
| dhx_m | then your plugin can do whatever it likes | 10:13 |
| dhx_m | or maybe you could just write an Evolution plugin to take emails sent from Mantis... check if you've been assigned to them | 10:14 |
| dhx_m | and it'll add them to your Evolution tasks list automatically | 10:14 |
| dhx_m | once you get an email stating that the ticket is resolved, your Evolution plugin marks it as resolved within Evolution as well | 10:14 |
| kenguest | with evo you can right=click on an email and select "Convert to task" | 10:15 |
| kenguest | then you can classify it and set end & start dates etc | 10:16 |
| kenguest | I'd need to think about it more ;-) | 10:16 |
| kenguest | hmm. think I'll go with 1.2.0a3 | 10:18 |
| kenguest | afterall, it'll only get tested if people try it, right? ;-) | 10:18 |
| giallu | dhx_m, ETA_TWO_TO_THRESS_DAYS typo? | 10:22 |
| dhx_m | giallu: I fixed that in one of the later commits | 10:23 |
| giallu | ah sorry, I'm looking at the first patch actually | 10:23 |
| giallu | did you applyed a consistent nameing then? for instance | 10:23 |
| dhx_m | no problem :) there aren't really that many fixups... except the BugData class | 10:23 |
| giallu | ah no, it's ok | 10:24 |
| dhx_m | kenguest: probably a good idea to do that, yes :) | 10:24 |
| giallu | dhx_m, right now, I'm not a fan of defines though | 10:24 |
| dhx_m | giallu: what is the alternative? | 10:24 |
| giallu | it's harder to customize | 10:24 |
| giallu | of course it's not your fault ;) | 10:25 |
| dhx_m | doesn't that mean we have to get rid of PHP based configuration | 10:25 |
| dhx_m | in favour of configuration stored in the database? | 10:25 |
| giallu | yes, I'd really like that, but probably is longer term... | 10:25 |
| dhx_m | yeah, now I've learnt a little bit more about Mantis internals, I know which parts really are antique | 10:26 |
| giallu | I mean, I'd expect to set few key parameters on config file, all the rest, including customizations, at the web admin interface | 10:26 |
| giallu | of course I'm dreaming... | 10:26 |
| dhx_m | I'd expect the config file to simply define configuration for connecting to the database | 10:27 |
| giallu | yeah | 10:27 |
| dhx_m | and probably path information as well | 10:27 |
| dhx_m | just the basics to get things up and running | 10:27 |
| giallu | anyway, I appreciate your work there | 10:27 |
| dhx_m | the email notification needs a big overhaul... especially in terms of configuration of when you're notified | 10:28 |
| dhx_m | it basically doesn't play nicely with custom statuses | 10:28 |
| giallu | I have that on my todo list for ages | 10:28 |
| dhx_m | the graphing/summary feature is also severely out of date, and doesn't factor in custom configuration | 10:28 |
| dhx_m | yep | 10:28 |
| dhx_m | then you have nice things like the plugin system :) | 10:29 |
| dhx_m | I actually think it might be easiest to rip out outdated features like the summary/graphing | 10:29 |
| dhx_m | and put them into plugins | 10:30 |
| dhx_m | so it makes it easier to fix the core Mantis code | 10:30 |
| dhx_m | really all it needs is some more subsystems (done with OO PHP in classes) | 10:30 |
| dhx_m | a lot of things can be put into plugins for better modularity... notifications being a major one that comes to mind | 10:31 |
| justabaka | hello there :) | 10:48 |
| dhx_m | hey | 10:48 |
| giallu | dhx_m, I'm not really sure I want notifications as plugins, but I'd surely like it the OOP way... | 10:49 |
| dhx_m | I just think it is best to rip out as much code as possible from the core which relates to "do I send a notification or not" | 10:50 |
| dhx_m | and handle it all generically in a module/plugin/whatever | 10:50 |
| dhx_m | even if it is similar in nature to plugin hooks... but they're notification hooks instead | 10:51 |
| justabaka | err, a little question: is signup bugged since like... 1.1.6? I'm testing 1.2.0a3, but it still registers a user even if you didn't type anything into the sugnup form | 10:51 |
| dhx_m | so once your notification handler has been called by a hook, it looks up the corresponding notification setting(s) from the database to determine who needs to be notified | 10:52 |
| dhx_m | where notification could be done via: email, IRC, twitter, SMS, whatever | 10:52 |
| giallu | justabaka, oh, never noticed. is there a bug open fog this? | 10:54 |
| justabaka | giallu, i'm trying to search for it, but I do believe like there isn't. Also I'm not fairly sure, it might be some kind of a misconfiguration on my server... But there are no errors being logged. I'm confised | 10:56 |
| justabaka | There's a message 'confirmation hash does not match' on other installations, but not in my case -_- | 10:58 |
| kenguest | hmm. 'APPLICATION WARNING #300: String "manage_import_issues_link" not found.' | 11:08 |
| mantisbot | New bug: Bug 10346 - kavanu - open - new | 11:12 |
| mantisbot | New bug: Configuration of release status behaviour - http://www.mantisbt.org/bugs/view.php?id=10346 | 11:12 |
| dhx_m | what a weird feature | 11:16 |
| dhx_m | actually I guess it has its uses | 11:17 |
| dhx_m | in some setups it could be handy | 11:17 |
| dhx_m | kenguest: what language do you use? | 11:18 |
| kenguest | dhx_m: mostly php, though I code in others too | 11:26 |
| dhx_m | nah, I meant the locale language for Mantis... English, Russian, etc :) | 11:27 |
| dhx_m | I'm not sure if your error is occurring because of a missing string in your language of choice? | 11:27 |
| dhx_m | I don't know if it defaults back to English for missing strings... I simply haven't tried ;) | 11:27 |
| kenguest | ah. English - whatever the default it | 11:28 |
| kenguest | is | 11:28 |
| kenguest | hmm. is it possible to turn off the display of certain fields in bug_report_page.php and view.php pages? | 11:48 |
| kenguest | maybe have view.php only display certain fields if there's data in them ;-) | 11:48 |
| dhx_m | currently no | 12:09 |
| dhx_m | bug fields need to have some value stored in them (they can't be NULL) | 12:09 |
| kenguest | even if it's just the default value? | 12:10 |
| dhx_m | you could implement that if you want | 12:13 |
| dhx_m | but most people wouldn't consider it a good idea to do so? | 12:13 |
| dhx_m | the fact that it has a default status may be deliberate | 12:14 |
| dhx_m | ie. default priority of "NORMAL" | 12:14 |
| kenguest | well, it obviously would be configurable. | 12:14 |
| kenguest | thing is one of the guys in work here wrote his own bugtracker because sales & such were afraid of the huge form in [a previous version of] mantis | 12:15 |
| kenguest | that bugtracker is well...buggy and under utilised... | 12:16 |
| dhx_m | hmm | 12:20 |
| dhx_m | well you can disable a lot of fields completely in the latest git trunk of 1.2.x | 12:20 |
| dhx_m | I'd be very happy to see the other fields have on/off settings as well :) | 12:21 |
| dhx_m | although I think we're actually quite close to having the ability to turn off all non-essential stuff | 12:21 |
| kenguest | cool | 12:21 |
| dhx_m | in my installation, most of the default fields are turned off | 12:22 |
| nuclear_eclipse | morning all | 12:43 |
| dhx_m | hi :) | 12:44 |
| nuclear_eclipse | http://www.mantisbt.org/wiki/doku.php/mantisbt:notification_requirements | 12:44 |
| dhx_m | nice :) | 12:45 |
| dhx_m | is that approach using the plugin hook system? | 12:45 |
| nuclear_eclipse | it's an eventual target of mine | 12:45 |
| nuclear_eclipse | yeah, although I'm not really planning to rip out the existing system, just give a big overhaul and "eventify" it | 12:46 |
| dhx_m | I guess you could say that is ripping it out though :p | 12:47 |
| dhx_m | what would be neat is being able to write: | 12:47 |
| dhx_m | send_notification('name_of_notification', ...something); | 12:47 |
| dhx_m | and the notification system does the rest for you | 12:47 |
| nuclear_eclipse | well, that's the goal :) | 12:48 |
| dhx_m | although I'm not sure how possible that would be | 12:48 |
| nuclear_eclipse | I'm planning to keep the selection of who to notify as close to the existing system as possible, with only a bit of extension to support new notification systems, and make events that plugins can hook to send notifications via other mediums, like IRC, Twitter, IM, etc | 12:49 |
| dhx_m | one of the problems I noticed with the current system today is with user configuration of what notifications they want to receive | 12:50 |
| nuclear_eclipse | but I'm more or less not planning to start on that until after a 1.2 release | 12:50 |
| dhx_m | what I think we really need is a new table that maps user_id, notification_name and some other columns like min_threshold, max_threshold, whatever else | 12:51 |
| nuclear_eclipse | actually, I really like the way configuration of notifications works in the config files via g_notify_flags, that's clever and useful | 12:51 |
| dhx_m | although I'm not a big fan of thresholds | 12:51 |
| dhx_m | I'd love to see a more OO approach to bugs | 12:51 |
| nuclear_eclipse | well, paul_ might be taking care of that for you ;) | 12:51 |
| dhx_m | :) | 12:51 |
| dhx_m | ie. you create a status_closed.php "plugin" | 12:52 |
| dhx_m | which is an extension to a default class | 12:52 |
| dhx_m | and you can override functions like change_status_to(new_status) | 12:52 |
| dhx_m | it'd be so much work though, I doubt it'll ever happen | 12:53 |
| dhx_m | so much work... you'd essentially be writing a new bug tracker | 12:53 |
| nuclear_eclipse | re #23 on my tracker... | 12:53 |
| dhx_m | yep | 12:54 |
| nuclear_eclipse | I assume in your case a global configuration for that would suffice, eg, not per-repo? | 12:54 |
| dhx_m | correct, that should be OK | 12:54 |
| dhx_m | I don't know of any SCM software which doesn't have compatibility between new versions of the client and old servers | 12:55 |
| nuclear_eclipse | and btw, the Git plugins don't use any client binaries except curl as a fallback if you don't have the ability to file_get_content() from a URL | 12:55 |
| nuclear_eclipse | they just parse the output from viewers, rather than needing to clone a repository locally | 12:55 |
| dhx_m | ah ok | 12:56 |
| dhx_m | so maybe it'd just be a specific option to WebSVN/the other SVN thingo | 12:56 |
| nuclear_eclipse | since Git doesn't allow you to query a remote repo like SVN does ;) | 12:56 |
| dhx_m | :) | 12:56 |
| nuclear_eclipse | I had considered adding this a while ago myself. and just never got around to it =\ | 12:57 |
| dhx_m | yep no hurry | 12:57 |
| dhx_m | I hardcoded it into mine | 12:57 |
| dhx_m | #24 is more important :) | 12:57 |
| nuclear_eclipse | "This should be a fairly easy task of ...." haha | 12:58 |
| nuclear_eclipse | funny | 12:58 |
| dhx_m | also with #23 I was a bit uneasy with security | 12:58 |
| dhx_m | lol | 12:58 |
| nuclear_eclipse | what would the security worry be? | 12:59 |
| dhx_m | whether it is OK to let the administrators execute any file on the server | 12:59 |
| dhx_m | because Mantis administrators probably shouldn't have that level of access | 13:00 |
| nuclear_eclipse | I would assume so, and not see any problem with that; if they can set up Mantis, PHP is letting them do anything they want.... | 13:00 |
| dhx_m | I was more concerned about a bug in Mantis letting someone use an administrator account to execute their own binary on the server | 13:01 |
| nuclear_eclipse | although I think I'd rather implement #23 as a "enter the directory that contains the svn binary" | 13:01 |
| dhx_m | I'd be much happier if when updating the scm_path, the executable was called to check the --version output or something like that | 13:01 |
| dhx_m | yep | 13:02 |
| dhx_m | that sounds OK as well | 13:02 |
| nuclear_eclipse | I think if you're worrying about Mantis administrators doing hokey things, they shouldn't be administrators :P | 13:02 |
| dhx_m | I was more worried about Mantis having a bug that lets a hacker execute files via a hacked administrator account | 13:03 |
| dhx_m | or something along those lines | 13:03 |
| nuclear_eclipse | oh | 13:03 |
| nuclear_eclipse | I think the risk is probably sufficiently low to just not consider that a problem | 13:03 |
| dhx_m | similar to how lots of other PHP software take file uploads very seriously | 13:03 |
| dhx_m | so that executable files aren't updated in directories where Apache will execute those files | 13:03 |
| dhx_m | yeah | 13:03 |
| dhx_m | if you force the executable to be called 'svn' it should be pretty much a non-issue | 13:04 |
| nuclear_eclipse | yeah, I would assume so | 13:04 |
| dhx_m | except if the path string can be manipulated in a way so that the executable called isn't actually 'svn' anymore | 13:04 |
| dhx_m | ie. the path is changed to: | 13:04 |
| kenguest | hmm. http://www.mantisbt.org/bugs/view.php?id=8814 - this not fixed? | 13:04 |
| nuclear_eclipse | kenguest: it should be | 13:05 |
| dhx_m | /bin/badapp --something --blah / | 13:05 |
| nuclear_eclipse | dhx_m: I was planning to do a is_dir( $path ) first to make sure it's a valid directory | 13:05 |
| dhx_m | ah, problem solved then :) | 13:05 |
| kenguest | nuclear_eclipse: looks like there's a patch in there already | 13:06 |
| kenguest | :( | 13:06 |
| nuclear_eclipse | well, I would do that at the time of updating the config | 13:06 |
| nuclear_eclipse | kenguest: it was fixed as part of my recent update for bug 7790 and bug 10228 | 13:07 |
| mantisbot | Bug 7790 - exk72 - fixed - resolved | 13:07 |
| mantisbot | Links protected by brackets are not processed properly - http://www.mantisbt.org/bugs/view.php?id=7790 | 13:07 |
| mantisbot | Bug 10228 - SteffenPoulsen - fixed - resolved | 13:07 |
| mantisbot | No way to avoid or escape the rendering plugin for part of a text - http://www.mantisbt.org/bugs/view.php?id=10228 | 13:07 |
| * nuclear_eclipse updates tracker to latest code | 13:09 | |
| dhx_m | :) | 13:09 |
| dhx_m | if you get time, you may be interested in http://git.mantisforge.org/w/mantisbt/dhx.git?a=shortlog;h=refs/heads/10330 | 13:09 |
| kenguest | nuclear_eclipse: thanks | 13:09 |
| nuclear_eclipse | kenguest: refresh bug 8814, it looks perfect now :) | 13:10 |
| mantisbot | Bug 8814 - hardfi - fixed - resolved | 13:10 |
| mantisbot | problem posting FTP access string - http://www.mantisbt.org/bugs/view.php?id=8814 | 13:10 |
| dhx_m | 10336 "Added ability to view other users My View page" is interesting | 13:12 |
| dhx_m | minus the obvious errors ;) | 13:12 |
| dhx_m | $t_view_as = $_POST["view_as_id"]; | 13:12 |
| dhx_m | :o :o | 13:12 |
| nuclear_eclipse | yeah... | 13:13 |
| * daryn_away is away: Gone away for now | 13:21 | |
| * daryn is back. | 13:23 | |
| dhx_m | :) | 13:25 |
| nuclear_eclipse | dhx_m: just pushed an implementation for #23 - would appreciate some testing to make sure it works on more than just my test machine :) | 14:12 |
| dhx_m | sure, thanks :) | 14:12 |
| dhx_m | will get it done tomorrow when I have a bit more time to try it out properly | 14:13 |
| nuclear_eclipse | ok, no problem | 14:13 |
| nuclear_eclipse | I also pushed a fix for #25 | 14:16 |
| nuclear_eclipse | that was a problem of me being an idiot :P | 14:16 |
| dhx_m | thanks :) | 14:22 |
| dhx_m | you made quick work of those two bugs :) | 14:23 |
| nuclear_eclipse | well, the second one was cake, I didn't even really try, and I found the bug in the code :P | 14:47 |
| smt | hello | 15:21 |
| smt | does mantis works with mysql 5? | 15:21 |
| kenguest | yes | 15:22 |
| smt | ok thanks | 15:22 |
| kenguest | I'm using mantis 1.2.0a3 against mysql 5.0.67 | 15:22 |
| kenguest | no problems | 15:22 |
| smt | ok :) | 15:22 |
| mantisbot | New bug: Bug 10347 - fedchyk - open - new | 16:14 |
| mantisbot | New bug: Incorrect breadcrumbs in extra dropdown for subprojects - http://www.mantisbt.org/bugs/view.php?id=10347 | 16:14 |
| paul_ | moo | 17:24 |
| * paul_ pokes nuclear_eclipse | 17:24 | |
| paul_ | dhx_m: lo? | 17:24 |
| nuclear_eclipse | lme is back | 17:27 |
| paul_ | nuclear_eclipse: you know what i'm going to ask ;p | 17:27 |
| nuclear_eclipse | not yet ;) | 17:28 |
| paul_ | :( | 17:28 |
| * nuclear_eclipse will do that now... | 17:28 | |
| nuclear_eclipse | linky | 17:28 |
| paul_ | http://git.mantisforge.org/w/mantisbt/paul.git?a=shortlog;h=refs/heads/dates | 17:29 |
| paul_ | http://git.mantisforge.org/w/mantisbt/paul.git?a=shortlog;h=refs/heads/bugobjects | 17:29 |
| nuclear_eclipse | you should upload a master branch so I have a diff point of reference :P | 17:33 |
| * paul_ STARES | 17:34 | |
| paul_ | just diff within the branch | 17:34 |
| paul_ | http://git.mantisforge.org/w/mantisbt/paul.git?a=commitdiff;h=7d26292daa2ea0c3ee087722694b3ea130bac384 | 17:34 |
| paul_ | think that's one | 17:34 |
| nuclear_eclipse | k | 17:35 |
| paul_ | http://git.mantisforge.org/w/mantisbt/paul.git?a=commitdiff;h=caeea25caef8e2ece7a0ce4adeb771a00955d26c;hp=2e32e0f16c8680ed8085253278b8061278cf2449 | 17:35 |
| paul_ | that I believe is the 2nd | 17:35 |
| nuclear_eclipse | ty | 17:35 |
| paul_ | (albeit with a TODO (of where to set default_timezone | 17:35 |
| nuclear_eclipse | which is more "important" to review first? | 17:35 |
| paul_ | both :) | 17:35 |
| nuclear_eclipse | ie, if I don't get enough time to review both... | 17:36 |
| paul_ | do bugobjects | 17:36 |
| paul_ | as i'm included to do similar to what i've done there to userprefs this weekend | 17:36 |
| nuclear_eclipse | ok | 17:36 |
| paul_ | daryn_: did you get a chance to rerun schema conversation ? :) | 17:37 |
| paul_ | (and good afternoon :P | 17:37 |
| nuclear_eclipse | paul_: why do you use ReflectionClass as opposed to the standard object inspection functions? | 18:26 |
| windsurf_ | I'm not receiving emails when a note is left on a bug. I've got the checkmark in my account checked, and in config_defaults_inc.php bugnotes is set to ON. | 18:26 |
| windsurf_ | am I missing something? | 18:26 |
| nuclear_eclipse | windsurf_: what server are you using? | 18:26 |
| windsurf_ | it's a LAMP stack... | 18:26 |
| windsurf_ | not sure exactly what you're asking | 18:27 |
| nuclear_eclipse | make sure you configure your local MTA to allow outbound email sending - by default, Debian-based distros are configured for local relay only | 18:27 |
| windsurf_ | i see... | 18:27 |
| windsurf_ | so i might need to tweak something in cpanel | 18:27 |
| windsurf_ | (that's what i have access to with my host) | 18:28 |
| nuclear_eclipse | oh | 18:28 |
| paul_ | nuclear_eclipse: i've got a suspicion that the standard ones dont return the right output | 18:28 |
| paul_ | what you thinking of? get_object_Vars or whatever iti s? | 18:28 |
| nuclear_eclipse | you may need to specify SMTP server settings in your config_inc.php if you can't get mail working through the norma methods | 18:29 |
| nuclear_eclipse | paul_: something like that | 18:29 |
| nuclear_eclipse | windsurf_: you probably need to talk to your host to figure out what settings you need to use to get mailing working | 18:29 |
| nuclear_eclipse | paul_: also, what is the point of switching everything to protected and then using __get()/__set()? why not just keep them all as public properties? | 18:30 |
| paul_ | right the standard ones | 18:31 |
| nuclear_eclipse | meaning? | 18:31 |
| paul_ | e.g. get_object_Vars dont show protected properties | 18:31 |
| paul_ | the reason for using protected properties | 18:31 |
| paul_ | is so I can cast ints to ints | 18:32 |
| paul_ | i.e. if we have a function | 18:32 |
| nuclear_eclipse | that seems a dubious reason... | 18:32 |
| paul_ | that returns a bugid | 18:32 |
| paul_ | we should return (int)bugid | 18:32 |
| paul_ | by using ->var and __set to ensure we are putting in an int | 18:33 |
| paul_ | we dont need to do (int)bugdata->var whenever we use ->var | 18:33 |
| nuclear_eclipse | it seems to me that the majority of your work is just adding more function calls to our already-gigantic function trace.... | 18:33 |
| paul_ | as we know that __get will return a var | 18:33 |
| paul_ | well, not really | 18:33 |
| windsurf_ | nuclear_eclipse: thanks, i'll try smtp, should work. What about port, apparently i need 26 | 18:34 |
| nuclear_eclipse | although I like the use of $bug->id, having that now translate to a function call.... | 18:34 |
| paul_ | take the current bug_create | 18:35 |
| paul_ | $c_project_id = db_prepare_int( $p_bug_data->project_id ); | 18:35 |
| paul_ | $c_reporter_id = db_prepare_int( $p_bug_data->reporter_id ); | 18:35 |
| paul_ | $c_handler_id = db_prepare_int( $p_bug_data->handler_id ); | 18:35 |
| paul_ | $c_reproducibility = db_prepare_int( $p_bug_data->reproducibility ); | 18:35 |
| paul_ | we *simplify* that | 18:35 |
| paul_ | by doing it within a __get switch statement | 18:35 |
| nuclear_eclipse | well, right, but we don't need __get()/__set() to simplify that... | 18:35 |
| paul_ | we could implement | 18:35 |
| paul_ | function set_project_id | 18:35 |
| windsurf_ | found it | 18:36 |
| paul_ | we can't do anything else can we? | 18:36 |
| windsurf_ | class.smtp.php | 18:36 |
| nuclear_eclipse | paul_: db_prepare_int( $x ) --> (int) $x | 18:36 |
| paul_ | db_prepare_int only does (int) atm | 18:36 |
| paul_ | but the point remains | 18:37 |
| paul_ | we need to remember to cast everything everywhere | 18:37 |
| nuclear_eclipse | but my point is that with __get(), $var->prop now makes a function call, instead of just a structure lookup | 18:37 |
| nuclear_eclipse | I'm just expressing a tiny concern; I'm not trying to say it's a failure or anything :P | 18:38 |
| * paul_ nods | 18:38 | |
| paul_ | your spot on correct though | 18:38 |
| nuclear_eclipse | I've never really been fond of private properties anyways, because you only ever seem to be hiding things from yourself when you do that :/ | 18:38 |
| paul_ | what i'm basicallythinking is | 18:39 |
| paul_ | atm | 18:39 |
| paul_ | we're opening up plugins to access bugs | 18:39 |
| paul_ | or more | 18:39 |
| paul_ | opening up ourselves to user plugins | 18:39 |
| paul_ | if we've got some code that expects ->reporter_id to be an int | 18:39 |
| paul_ | (and lets say for sake of argument there's a security risk if it's a string | 18:39 |
| paul_ | either in a plugin or internally or whatever | 18:40 |
| paul_ | we can use __set/__get to ensure reporter_id is always an int | 18:40 |
| nuclear_eclipse | agreed; I like the principle of using __set(), but I think __get() is a little more dubious | 18:40 |
| paul_ | Did __get in 0.0219860076904 seconds | 18:42 |
| paul_ | Did -> in 0.0219769477844 seconds | 18:42 |
| paul_ | -- | 18:43 |
| paul_ | Did __get in 0.15332698822 seconds | 18:43 |
| paul_ | Did -> in 0.121922016144 seconds | 18:43 |
| paul_ | 100,000 interations of: | 18:43 |
| paul_ | $test2 = new foo2; | 18:43 |
| paul_ | $test2->b; | 18:43 |
| nuclear_eclipse | perhaps try profiling a run of `$b = new BugData; $x = $b->id + $b->user_id; ...` with and without the __get() function... | 18:44 |
| paul_ | and oops | 18:45 |
| paul_ | that first __Get | 18:45 |
| paul_ | was a __get on something that is public | 18:45 |
| paul_ | it drops to 0.34 if what you are getting is protected | 18:45 |
| paul_ | Did __get(200000) in 0.543648958206 seconds | 18:46 |
| paul_ | Did ->(200000) in 0.162312984467 seconds | 18:46 |
| paul_ | for x=x+b+bb | 18:47 |
| paul_ | seems to go from 0.162->0.167 if you do x=x+(int)b+(int)bb | 18:48 |
| nuclear_eclipse | right, so like I assumed, the overhead of __get() calls is noticeable, although perhaps not enougt to matter compared to the latency of database requests and so farth | 18:49 |
| paul_ | incidently | 18:49 |
| paul_ | if we remove the switch() statement from __get | 18:50 |
| paul_ | it drops from 0.54->0.50/1 | 18:50 |
| paul_ | i'm just running this on a test class atm of: | 18:50 |
| paul_ | class foo { private $a; protected $b = 1; protected $bb = 1; protected $c; private $d; static $e | 18:50 |
| nuclear_eclipse | ok | 18:50 |
| paul_ | i.e. if we put functions inside the class, I dont know if that will affect the speed of __get (i'm guessing *not* | 18:50 |
| nuclear_eclipse | I would assume not | 18:51 |
| paul_ | ofc, the other point you raise is valid | 18:51 |
| paul_ | if we are using __set | 18:51 |
| paul_ | to cast | 18:51 |
| nuclear_eclipse | __get() should only ever be called for properties | 18:51 |
| paul_ | if a properties is public, it will still go via __Get right ? | 18:51 |
| nuclear_eclipse | right | 18:51 |
| nuclear_eclipse | with __get(), you have to handle your own data-hiding, as the public/protected/private loses all of its context | 18:52 |
| paul_ | i'm just wondering if i've done 'protected' for the sake of it more | 18:53 |
| paul_ | i.e. we could use public on most things | 18:53 |
| paul_ | although in a sense, this is mainly semantics we can fiddle with - it's internal to bug api | 18:53 |
| windsurf_ | nuclear_eclipse: new info: the 'lost your password' email works, but i'm not getting emails when i create an issue or add a note to one. So, i guess my smtp stuff is all working. any other thoughts? | 18:53 |
| nuclear_eclipse | I think a "better" solution would be to a) keep everything public, and then b) drop __get() and only use __set() for casting/validating | 18:53 |
| paul_ | as we can use __Set to define protected | 18:54 |
| nuclear_eclipse | windsurf_: $g_email_receive_own = ON in your config_inc | 18:54 |
| paul_ | the thing i kinda need thoughts on is: | 18:54 |
| paul_ | for strings e.g. summary | 18:54 |
| paul_ | ahh now I recall | 18:55 |
| paul_ | for strings e.g. summary | 18:55 |
| paul_ | I think I was half thinking | 18:55 |
| paul_ | we'd deny ->summary | 18:55 |
| nuclear_eclipse | why? | 18:55 |
| paul_ | and say you have to call either raw(), edit(), display() | 18:55 |
| nuclear_eclipse | :( | 18:55 |
| paul_ | which would prepare a string for display or return thee raw string | 18:55 |
| nuclear_eclipse | I think that's starting to get too complicated... | 18:56 |
| paul_ | atm, bug api is slow for reports | 18:56 |
| paul_ | as if you look at some of the summary stuff we do | 18:56 |
| paul_ | get bug | 18:56 |
| paul_ | prepare_bug_display() which calls string_display about 20 times | 18:56 |
| paul_ | get next bug | 18:56 |
| nuclear_eclipse | I'm not even sure why we do the bug_prepare_* stuff anyways... | 18:56 |
| paul_ | I think it's just an 'easy' way to make sure we never do ->summary without putting it via string_display | 18:56 |
| nuclear_eclipse | why don't we just defer string_display() until we actually display it, like everything else in Mantis? | 18:57 |
| * paul_ shrugs :) | 18:57 | |
| paul_ | part of me thinks however | 18:57 |
| paul_ | if bug api makes the author using it think | 18:57 |
| paul_ | 'what am i doing with this data' | 18:58 |
| paul_ | i.e. the you have to call either raw(), edit(), display() comment | 18:58 |
| paul_ | when we get plugins displaying summary information | 18:58 |
| paul_ | we're not going to have security issues from people forgetting to call string_display | 18:58 |
| paul_ | similarly, there's performance differences between string_display, string_display_line etc | 18:58 |
| nuclear_eclipse | paul_: I don't like that sort of contcept | 18:59 |
| nuclear_eclipse | it should be up to the plugin to use the data appopriately, because what's to stop a plugin from doing ->raw() and displaying that anyways? | 18:59 |
| paul_ | nothing, but you'd hope it would encourage people to think :) | 19:00 |
| nuclear_eclipse | I think it makes more sense for everything to always be "call string_display*() when you output something", and be as consistent as possible about that throughout all of mantis | 19:00 |
| nuclear_eclipse | paul_: nothing will encourage idiots to think ;) | 19:00 |
| paul_ | that was one reason | 19:00 |
| nuclear_eclipse | idiots will leap the tallest hurdles in their way just to keep from having to think about what they're doing.. | 19:01 |
| paul_ | the other reason was, | 19:01 |
| paul_ | by using ->edit() and ->display(), I need to worry less about introducing security bugs by removing prepare_bug_* :) | 19:01 |
| paul_ | (as it'd make changes, block->__get summary and test ;p | 19:02 |
| nuclear_eclipse | I'm not sure how it changes anything; you'll already need to find and replace all existing uses of bug_prepare_* anyways... | 19:02 |
| paul_ | bug_prepare prepares 20 strings of a bugdata object | 19:02 |
| paul_ | that then get used :) | 19:02 |
| windsurf_ | nuclear_eclipse: thanks | 19:02 |
| paul_ | so I drop one function call | 19:03 |
| paul_ | but the 'secure' output that function call used to give us | 19:03 |
| paul_ | might be used in 30 places | 19:03 |
| nuclear_eclipse | well, right, but I'm not quite sure how that's any different than needing to call ->display() for anything you need to output... | 19:03 |
| paul_ | anyway, bored of discussion now ;) | 19:03 |
| nuclear_eclipse | at least using string_display() is more consistent with the rest of the codebase | 19:03 |
| nuclear_eclipse | windsurf_: you're welcome | 19:04 |
| paul_ | i'll remove the __Get | 19:04 |
| paul_ | make protected->public | 19:04 |
| paul_ | and drop display() etc | 19:04 |
| paul_ | as an aside | 19:04 |
| paul_ | one thnig the __get would give us | 19:04 |
| paul_ | we could define ->reporter_name | 19:04 |
| paul_ | or what i was thinking ->attachmentcount | 19:05 |
| paul_ | i.e. make life a bit easier for someone using bugdata | 19:05 |
| paul_ | anyway, if i make those changes and test a bit | 19:06 |
| windsurf_ | nuclear_eclipse: ok, so that's working, the only thing that doesn't seem to work is email notification when a note is added to a bug | 19:06 |
| paul_ | that should be fine to commit right? | 19:06 |
| nuclear_eclipse | I think that's starting to introduce complexities and behavior hiding that's not as necessary, because then ->reporter_name='Jack' becomes undefined, and once again breaks consistency, ie, you'd then need to implement that sort of thing on *every* data object we use, rather than just using the already existent function call for user_get_name( $bug->reporter_id ) | 19:06 |
| nuclear_eclipse | but yes, with the changes you mentioned, I would agree with you pushing that to 1.2.x | 19:07 |
| paul_ | got time for dates? | 19:07 |
| paul_ | ;p | 19:07 |
| paul_ | also | 19:07 |
| paul_ | i've started looking at /admin and utf8 | 19:07 |
| nuclear_eclipse | maybe in a short bit I'll look at that | 19:07 |
| nuclear_eclipse | windsurf_: by default, bug notes only send notifications to users that have "touched" that bug, eg, the reporter, the handler, anyone who updated it, and anyone monitoring it | 19:08 |
| nuclear_eclipse | windsurf_: see $g_notify_flags in config_defaults_inc, and if you want to change anything, make the changes in your config_inc | 19:09 |
| windsurf_ | nuclear_eclipse: so i can put the same vars in config and that overrides config_defaults because it gets included later or something? | 19:16 |
| nuclear_eclipse | yep | 19:16 |
| windsurf_ | still having trouble. I have users that are reporters and users that are developers. I want all activity on an issue to have email notifications to both types of users... | 19:35 |
| windsurf_ | i think i've only managed to get developers receiving notifications of stuff that reporters are doing | 19:36 |
| nuclear_eclipse | windsurf_: if you change $g_notify_flags[xxx]['threshold_min'] = REPORTER, then it will make sure everybody receives a message for the given action, but note that it will likely result in a lot of email, and may not be what your users want | 19:37 |
| windsurf_ | nuclear_eclipse: so that works for creating issues, and changing status, but not adding notes to a bug | 19:44 |
| windsurf_ | i don't think i've ever gotten a notification for that | 19:44 |
| nuclear_eclipse | hmmm | 19:44 |
| windsurf_ | i think i might have seen that is a bug out there... | 19:44 |
| nuclear_eclipse | windsurf_: what version are you using? | 19:44 |
| windsurf_ | 1.1.2 i think | 19:44 |
| nuclear_eclipse | oooh.... | 19:45 |
| windsurf_ | confirmed | 19:45 |
| windsurf_ | should i upgrade? | 19:45 |
| nuclear_eclipse | yes, not only to fix that, but for a large amount of security fixes | 19:45 |
| windsurf_ | ohhh | 19:45 |
| windsurf_ | ok :) | 19:45 |
| windsurf_ | does it affect my strings and html templates? i fiddled with that a fair bit | 19:45 |
| windsurf_ | guess we'll see. | 19:46 |
| nuclear_eclipse | if you've modified any of the core code, it most likely will | 19:46 |
| nuclear_eclipse | you could always save a diff of your changes and then try to apply those changes back to 1.1.6.... | 19:46 |
| nuclear_eclipse | hi giallu | 19:46 |
| nuclear_eclipse | giallu: make a decision about phpmailer in 1.1.x; I want to release :P | 19:47 |
| giallu | hi | 19:47 |
| giallu | nuclear_eclipse, if you want to release, _you_ decided ;) | 19:47 |
| windsurf_ | nuclear_eclipse: true | 19:48 |
| giallu | nuclear_eclipse, I guess it's ok to go ahead | 19:48 |
| giallu | let's break stable later... | 19:48 |
| nuclear_eclipse | I'm not sure I have a correct idea of a) the severity of the bug, or b) the effort required to update phpmailer... | 19:48 |
| giallu | nuclear_eclipse, updating phpmailer is easy, backporting related stuff is harder | 19:49 |
| nuclear_eclipse | that's mostly what I meant :P | 19:49 |
| giallu | :P | 19:49 |
| giallu | so I don't think we can rush this now | 19:49 |
| nuclear_eclipse | effort required = time to update phpmailer + time to backport all phpmailer fixes/changes | 19:49 |
| giallu | I think we could: | 19:49 |
| giallu | 1. release 1.1.7 now | 19:49 |
| windsurf_ | nuclear_eclipse: how do i do an update, am i supposed to ftp up a new version then click the upgrade 'cause nothing really eventful happened, is it just modifying the db? | 19:50 |
| giallu | 2. update phpmailer | 19:50 |
| giallu | 3. backport most important fixes | 19:50 |
| nuclear_eclipse | windsurf_: between minor versions, there are no db schema changes, so it should just be a matter of uploading the new code | 19:50 |
| giallu | 4. release a 1.1.8rc so it gets tested in the wild... | 19:50 |
| windsurf_ | nuclear_eclipse: ok thanks | 19:50 |
| nuclear_eclipse | giallu: sounds like a plan | 19:51 |
| nuclear_eclipse | I try to pop a release sometime tonight or over the weekend | 19:51 |
| giallu | ok | 19:51 |
| giallu | thank you | 19:51 |
| nuclear_eclipse | still gotta prepare my presentation for barcamp tomorrow :P | 19:51 |
| paul_ | nuclear_eclipse: your moving to ohio? | 19:52 |
| nuclear_eclipse | yes, at the end of July | 19:52 |
| paul_ | how comes? | 19:52 |
| paul_ | or more what's in ohio | 19:52 |
| nuclear_eclipse | family for both my wife and me | 19:53 |
| * paul_ wonders how old nuclear_eclipse is | 19:53 | |
| nuclear_eclipse | we both grew up in Ohio, and we only live here in Rochester because of university | 19:53 |
| nuclear_eclipse | <- 23 | 19:53 |
| paul_ | young marriage ;) | 19:53 |
| nuclear_eclipse | 24 in ten days :P | 19:53 |
| paul_ | and both daryn+giallu have kids? | 19:53 |
| nuclear_eclipse | we've actually been married for almost four years now ;) | 19:54 |
| nuclear_eclipse | we were dating since early high school | 19:54 |
| paul_ | on a different subject briefly | 19:54 |
| * giallu has 2 | 19:54 | |
| paul_ | can i collapse a branch into 1 commit? | 19:54 |
| paul_ | 2? | 19:54 |
| nuclear_eclipse | yes | 19:54 |
| paul_ | how? | 19:54 |
| paul_ | I thought you had 1 baby? | 19:54 |
| giallu | git rebase --interactive | 19:54 |
| nuclear_eclipse | or git merge --squash | 19:54 |
| giallu | paul_, see http://www.gnome.org/~federico/news-2008-08.html#git-rebase-interactive | 19:55 |
| nuclear_eclipse | paul_: see `man git-rebase` or `man git-merge` :P | 19:55 |
| paul_ | giallu: i'm gonna break stuff ;) | 19:55 |
| * daryn has...10 today | 19:55 | |
| giallu | paul_, I'm at 2 since Nov 2008 | 19:55 |
| paul_ | daryn: 10 kids????? | 19:55 |
| daryn | 4 bio, 3 full time foster, 3 weekend foster | 19:55 |
| giallu | oops 2007 ;) | 19:55 |
| daryn | that they are trying to place with us long term | 19:56 |
| daryn | my wife is insane | 19:56 |
| daryn | soon i will be too | 19:56 |
| paul_ | you get paid for fosters? | 19:56 |
| nuclear_eclipse | how do you have weekend foster kids? | 19:56 |
| daryn | yeah. | 19:56 |
| daryn | this was emergency | 19:56 |
| paul_ | was yea at me or john? | 19:56 |
| daryn | you can do respite care too | 19:56 |
| daryn | yeah was at you, but believe me, it really isn't the money | 19:57 |
| paul_ | and how come you have 3 weekend only? | 19:57 |
| daryn | they don't pay enough to deal with most of these kids | 19:57 |
| daryn | they were removed from the home last night and needed a quick place. we're on call permanently | 19:58 |
| paul_ | 'the home' being parental home or childrens home? | 19:58 |
| daryn | parental | 19:58 |
| daryn | police removal | 19:58 |
| nuclear_eclipse | fun! | 19:59 |
| daryn | oh, yeah! | 20:00 |
| paul_ | hmm, how old are these 7 kids? | 20:00 |
| daryn | 17,11,11,10,8,7,5 | 20:00 |
| paul_ | do they tend to settle down 'ok' (Well) | 20:02 |
| daryn | mmm....depends on the day | 20:02 |
| daryn | the 17 year old and our four are typically fine. the two boys, 11 and 8, are a handful | 20:03 |
| paul_ | how old are your 4? | 20:03 |
| daryn | 11,10,7,5 | 20:03 |
| paul_ | nuclear_eclipse: let me know if your gonna look at dates too btw | 20:17 |
| paul_ | daryn: did you say you ran the new upgrade? | 20:17 |
| * paul_ forgets | 20:17 | |
| nuclear_eclipse | I'm doing a cursory glance atm | 20:17 |
| daryn | no...sorry | 20:20 |
| paul_ | daryn: can you try before you go for w/e | 20:24 |
| daryn | k. what am i looking for this time? | 20:24 |
| paul_ | you said it was slow | 20:24 |
| paul_ | to upgrade | 20:24 |
| paul_ | so i've tried to group upgrades together | 20:24 |
| daryn | ah, yes. ok | 20:24 |
| paul_ | i.e. all of bug table into 1 run not 3 runs | 20:24 |
| nuclear_eclipse | paul_: /me thinks we need a date_api.php ;) | 20:45 |
| nuclear_eclipse | paul_: just to make sure I understand, dates branch currently does nothing but add a constant and start adding data points for selecting user timezones, but no actual data manipulation yet for timezones? | 20:50 |
| * nuclear_eclipse heads out | 21:04 | |
| nuclear_eclipse | cheers | 21:04 |
| paul_ | nuclear_eclipse: no we dont | 21:06 |
| paul_ | and no | 21:06 |
| paul_ | there's a manage page | 21:06 |
| paul_ | and it converts data | 21:06 |
| * paul_ wonders if daryn went for w/e too | 21:09 | |
| daryn | not yet... | 21:09 |
| daryn | i'm an hour behind john | 21:09 |
| paul_ | reckon you'll have time to run script before your off? | 21:12 |
| daryn | paul_ here goes... | 21:33 |
| daryn | hm...still running | 21:37 |
| daryn | done...took 5:21 | 21:39 |
| daryn | last updated seems wrong | 21:41 |
| daryn | all are 12-31-1969 18:00 | 21:41 |
| daryn | paul_? | 21:44 |
| daryn | well...i gotta run. i don't think it's working right. | 21:48 |
| daryn | chat later | 21:48 |
| paul_ | 12-31-1969 18:00 is probably = 1 unixtimestamp | 22:33 |
| paul_ | hmm | 22:33 |
Generated by irclog2html.py