| ../irclogs/#mantishelp.2010-01-13.log | ||
| --- scribe started --- | 00:00 | |
| alemayo | good morning | 07:02 |
|---|---|---|
| alemayo | is there any theme support in mantis ? | 07:02 |
| kirillka | alemayo: mo. Not. | 07:03 |
| alemayo | kirillka: but there are some beginnings to do something like that ? because there are now all this $tpl_ ... variables in the view page and so on .. | 07:05 |
| kirillka | alemayo: try see bug 10409 | 07:07 |
| kirillka | mantisbot: ping | 07:07 |
| kirillka | http://www.mantisbt.org/bugs/view.php?id=10409 | 07:07 |
| alemayo | okay thanks | 07:23 |
| alemayo | what is that mantisbot for ? | 07:23 |
| mantisbot | Bug 10409 - enisseo - open - feedback | 08:02 |
| mantisbot | New graphic design draft - http://www.mantisbt.org/bugs/view.php?id=10409 | 08:02 |
| mantisbot | pong | 08:02 |
| alemayo | when I am on a plugin's page and switch the project, it seems to jump back to "Main". is that a bug or am I integrating my plugin in a wrong way. | 08:38 |
| alemayo | bug 11389 | 09:48 |
| alemayo | mantisbot: bug 11389 | 09:48 |
| mantisbot | Bug 11389 - am-gtz - open - new | 10:57 |
| mantisbot | [patch] set_project does not jump properly to a plugin page - http://www.mantisbt.org/bugs/view.php?id=11389 | 10:57 |
| mantisbot | Bug 11389 - am-gtz - open - new | 10:57 |
| mantisbot | [patch] set_project does not jump properly to a plugin page - http://www.mantisbt.org/bugs/view.php?id=11389 | 10:57 |
| morphium_ | Good morning :) Is it possible with mantisbt 1.2 to summarize the times for projects / categories, or only per issue at the moment? | 11:23 |
| dhx_m | back | 12:23 |
| dhx_m | morphium_: times? time tracking information? | 12:23 |
| dhx_m | morphium_: check out the TimeCard plugin at git.mantisforge.net for a more modern take on time tracking (more features, etc) | 12:24 |
| morphium_ | yeah but mantisbt is implementing it now, so I tend to using the built in system | 12:28 |
| dhx_m | the truth is, the built-in system is likely not going to be there in the future | 12:28 |
| dhx_m | not for a while... | 12:28 |
| dhx_m | but the general push is to get a lot of these features into official plugins | 12:29 |
| dhx_m | much like MantisGraph, etc | 12:29 |
| morphium_ | so why did they even announce & start it in 1.2? | 12:29 |
| alemayo | is it possible to define different number ranges for different projects (so that the bug ids look continues for the projects) | 12:30 |
| dhx_m | morphium_: I'm confused by what you mean there... care to elaborate? | 12:31 |
| dhx_m | alemayo: no, it wouldn't make sense from the perspective of copying bugs between projects, etc | 12:32 |
| alemayo | dhx_m: I know ... but we will provide one central mantis installation for different departments that would not copy / move between each other --- the stuff is just well seperated. | 12:35 |
| alemayo | another thing .... I for 1.2.0rc1 I made a hack to allow subcategories (gives you two selection boxes for the category). First you select a master category, i.e. "Hardware" and then the second box is updated to "purchase" , "text" and so on | 12:52 |
| alemayo | I think it is not possible to make that as a plugin as the necessary events are not there .. | 12:53 |
| alemayo | but I could also try to make a patch and add a configure variable like g_subcategories ... | 12:53 |
| dhx_m | alemayo: maybe you're better off using different Mantis installations side-by-side if you need to have separate IDs for each project? | 12:55 |
| dhx_m | alemayo: feel free to add/request more plugin events... we're really adding them on an as-needed basis | 12:56 |
| dhx_m | alemayo: just file a new bug with the event you want, where you want it in the code (when it'll trigger) and a reasoning behind why the event is needed/what it can be used for | 12:56 |
| alemayo | dhx_m: I was thinking a central mantis installation is easier to manage -- especially because you already have all those config options on per project base ... but maybe you a rights | 12:59 |
| dhx_m | alemayo: well, it is :) | 13:01 |
| alemayo | is it :) ? | 13:01 |
| dhx_m | alemayo: it's just that having multiple bug IDs (dependent on project) is a little confusing when we want to support moving bugs between projects | 13:02 |
| dhx_m | alemayo: we'd have to change the bug ID (not a good idea at all) during move operations | 13:02 |
| alemayo | dhx_m: you are right .... my boss wanted that feature not me :-) | 13:02 |
| dhx_m | alemayo: it's a commonly requested feature and it sounds great until you start looking into it further :) | 13:02 |
| alemayo | dhx_m: or we just block the move operation between such prjects :) | 13:02 |
| morphium_ | dhx_m: I mean, why did they introduce it in 1.2 if they don't plan to continue to develop the feature directly in mantisbt? | 13:04 |
| dhx_m | alemayo: there was a bug report on the official tracker that I'll never find again, essentially discussing the topic of multiple bug ID counters (per project, etc) in more depth | 13:04 |
| dhx_m | morphium_: are you talking about SOAP support for time tracking? | 13:04 |
| alemayo | dhx_m: ah by the way .. the search function also needs polishing :) | 13:09 |
| alemayo | mantisbot: find the bug that dhx_m mentioned | 13:10 |
| dhx_m | alemayo: yeah, although proper search functionality is generally outside the scope of what is possible with PHP | 13:10 |
| dhx_m | ... or most other web programming languages | 13:10 |
| alemayo | dhx_m: despite the moving issue, such multiple bug id scopes should be easy to implement, aren't they ? | 13:23 |
| dhx_m | alemayo: I guess | 13:31 |
| dhx_m | alemayo: you'd need to have project-specific prefixes | 13:31 |
| dhx_m | alemayo: 1{bugid} for project A, 2{bugid} for project B, etc | 13:32 |
| dhx_m | or alphabetical prefixes (A00000001, B00000002, etc) | 13:32 |
| dhx_m | specifying ranges wouldn't work | 13:32 |
| dhx_m | as you can't really predict what happens when you use all IDs in a range | 13:33 |
| alemayo | the ranges must just be big enough :) | 13:38 |
| alemayo | what is the differences between custom functions and plugins ? | 13:40 |
| alemayo | basically I have to overwrite almost all of what is happening in print_category_option_list | 13:41 |
| alemayo | I could maybe make some event that is fired on top of print_category_option_list, and when it returns true, we just do not execute the remaining part of print_category_option_list | 13:42 |
| alemayo | or is that maybe better to be done with some custom function ? | 13:42 |
| alemayo | but I guess custom functions are more or less legacy and will be replaced by plugins soon or later ? | 13:43 |
| mantisbot | alemayo: Error: "find" is not a valid command. | 14:04 |
| dhx_m | alemayo: custom functions are deprecated... it essentially was a method you could use to replace parts of Mantis (logic/display) with your own code | 14:18 |
| dhx_m | well at least I think it's deprecated :) | 14:19 |
| alemayo | alright | 14:21 |
| alemayo | I prefer that plugin stuff anyways ... | 14:21 |
| alemayo | do I have to define new events somewhere ? | 14:21 |
| alemayo | or I just put my <?php event_signal( 'EVENT_CATEGORY_SELECTBOX', array( $f_category_id ) ) ?> | 14:21 |
| alemayo | into the code? | 14:21 |
| daryn | core/events_inc.php ... i think | 14:23 |
| alemayo | http://www.mantisbt.org/bugs/view.php?id=11391 | 14:24 |
| alemayo | but I do not feel so good with my event -- it is somehow hacky :( | 14:25 |
| daryn | :) | 14:25 |
| daryn | have you been chatting with nuclear_eclipse at all? he's the plugin jedi master | 14:26 |
| alemayo | no | 14:26 |
| alemayo | I am chatting with dhx_m most of the time :-)) | 14:26 |
| dhx_m | also see previous commit history for when we've added events in the past | 14:26 |
| nuclear_eclipse | alemayo: hello young padawan :P | 14:26 |
| dhx_m | to give you a rough idea of what needs to change when adding events | 14:26 |
| dhx_m | daryn: hi :) | 14:26 |
| dhx_m | nuclear_eclipse: hi :) | 14:26 |
| daryn | greetings | 14:26 |
| daryn | happy new year everyone...it's been awhile | 14:27 |
| nuclear_eclipse | thank you :) | 14:27 |
| dhx_m | happy new year to you as well | 14:27 |
| daryn | thanks | 14:28 |
| daryn | i see lots of commits since i've been on...any closer to 1.2 final? | 14:29 |
| dhx_m | I'm not sure what we're waiting for anymore | 14:29 |
| nuclear_eclipse | we're waiting on paul_____ | 14:29 |
| nuclear_eclipse | as usual it seems | 14:29 |
| dhx_m | for what bug ids? | 14:29 |
| dhx_m | 11153: truncated downloads is the only one open on the roadmap | 14:30 |
| nuclear_eclipse | he doesn't create bugs for them, as usual :P | 14:30 |
| dhx_m | and I can't even reproduce it | 14:30 |
| alemayo | ah by the way .... | 14:30 |
| daryn | we need to ban him from gaming and the pub until he finishes! | 14:30 |
| alemayo | currently I am working against 1.2.0rc2 --- maybe it makes more sense to work on the latest 1.2.0 version, mh ?? | 14:30 |
| * alemayo should really have a look at this GIT stuff | 14:31 | |
| daryn | yes do look at git | 14:31 |
| daryn | makes it much easier to keep up to date | 14:31 |
| nuclear_eclipse | if anything, use a nightly build | 14:31 |
| dhx_m | alemayo: yes use 1.2.x git master for development :) | 14:31 |
| dhx_m | especially if you plan on adding plugin events | 14:32 |
| alemayo | ah | 14:32 |
| alemayo | hm | 14:32 |
| daryn | nuclear_eclipse did you see my note on a new bug change status event? | 14:32 |
| nuclear_eclipse | yeah, I just haven't had the chance to actually look into it yet | 14:32 |
| paul_____ | eve takes up too much time | 14:32 |
| dhx_m | paul_____: and here he is! | 14:33 |
| daryn | ok. cool. i just added it in my dev branch but not comfortable enough with plugins to just push it | 14:33 |
| paul_____ | djwjere | 14:33 |
| paul_____ | ? | 14:33 |
| paul_____ | dhx_m: where? | 14:33 |
| paul_____ | nuclear_eclipse: I've got a horrible merge conflict ;/ | 14:33 |
| dhx_m | paul_____: oh I meant you had arrived amidst this flurry of activity :) | 14:33 |
| daryn | paul_____ you're banned from gaming...and the pub...until 1.2 final is released | 14:34 |
| daryn | :) | 14:34 |
| nuclear_eclipse | paul_____: this is why you shouldn't be holding your branches forever and ever.... | 14:34 |
| paul_____ | nuclear_eclipse: I wasn't :) | 14:35 |
| paul_____ | it got created at xmas | 14:35 |
| paul_____ | I'm gonna start running codesniffer rules against mantis code base | 14:36 |
| paul_____ | so inconsistent code gets pulled out as it gets commited | 14:36 |
| daryn | shouldn't that be a precommit hook? | 14:37 |
| dhx_m | yeah precommit | 14:37 |
| nuclear_eclipse | paul_____: just focus on your ldap and columns fixes for now so we can *please* move on with releasing 1.2... | 14:37 |
| paul_____ | nuclear_eclipse: I actually read the ldap code | 14:37 |
| paul_____ | and have conclude I can ignore the password commits | 14:37 |
| dhx_m | nuclear_eclipse: are they really important enough to wait on? why not leave those fixes for 1.3.x? | 14:37 |
| paul_____ | dhx_m: I guess a more important question to answer that would be how short/long will 1.2 exist for | 14:38 |
| alemayo | is anybody using eclipse PDT for Mantis development /// is the mantis git plugin good ? | 14:38 |
| dhx_m | paul_____: IMO keep release cycles short? | 14:38 |
| paul_____ | well, some people on core team seem to like OS packages | 14:39 |
| paul_____ | where OS wants to have mantisand everything the same for 5 years at a time | 14:39 |
| dhx_m | paul_____: otherwise we get to the point where all the users are stuck on 1.2.x (with bugs) and we've fixed them all in 1.3.x.... that will be released in 3 years time | 14:39 |
| paul_____ | maybe we should change our release numbering | 14:40 |
| nuclear_eclipse | dhx_m: I just don't want new API's to be changed immediately between 1.2 and 1.3.... | 14:40 |
| paul_____ | "Mantis 2009.1" | 14:40 |
| dhx_m | nuclear_eclipse: I think we're going to have to... our API is begging for dramatic change (towards OO) | 14:41 |
| dhx_m | paul_____: I like that too | 14:41 |
| nuclear_eclipse | dhx_m: it would be one thing for an api to change, but he wants to change/revert stuff that just got added to 1.2, and at that point, I think it would be better to have the API change happen right away rather than adding api options only to remove them again... | 14:42 |
| dhx_m | yep | 14:43 |
| dhx_m | unless of course fixing/reverting changes is a lot of cost, and providing an interim temporary "will be gone in 12 months" fix would be better? | 14:43 |
| paul_____ | dhx_m: there's 2 issues - 1) ldap api should support >1 server, >1context etc | 14:46 |
| paul_____ | 2) columns api spams config table atm | 14:46 |
| paul_____ | I see 2 as lesser importance | 14:46 |
| dhx_m | columns API sucks IMO :p | 14:46 |
| paul_____ | nah | 14:46 |
| paul_____ | it's fine | 14:46 |
| dhx_m | well, it's not too bad | 14:46 |
| paul_____ | it's just implemented in 3 places | 14:46 |
| dhx_m | in comparison | 14:46 |
| dhx_m | yep | 14:47 |
| paul_____ | we use helper_api to check permissions | 14:47 |
| paul_____ | we use columns api to check permissions | 14:47 |
| paul_____ | and we use a custom function | 14:47 |
| paul_____ | :) | 14:47 |
| dhx_m | helper_api = ugliest code architecture ever.... and print_api | 14:47 |
| dhx_m | lol | 14:47 |
| dhx_m | really what we need to do is focus on stripping content from logic | 14:47 |
| dhx_m | PHPTAL :) | 14:48 |
| daryn | :D | 14:48 |
| paul_____ | ew | 14:49 |
| daryn | phptal rocks, paul_____ | 14:50 |
| dhx_m | yep TAL is a nice idea for templating ;) | 14:51 |
| paul_____ | brb | 14:51 |
| paul_____ | need to change ip settings a sec | 14:51 |
| daryn | i got the login page converted using tal and that new design... i know, big deal...but it works! | 14:52 |
| dhx_m | cool :) | 14:53 |
| azneita | is there any way of changing mantis time to that of another timezone? instead of UTC | 15:31 |
| azneita | my server time is set to Asia/Manila time but the mantis time is still set to UTC | 15:32 |
| nuclear_eclipse | azneita: in 1.2, there is a way to specify the preferred timezone, otherwise, it's based on PHP's configured timezone | 15:32 |
| azneita | i'm running 1.1.8. that means i should tinker with php instead, right? | 15:34 |
| nuclear_eclipse | yep | 15:34 |
| azneita | will do just that, thanks | 15:34 |
| nuclear_eclipse | it should be an option in your php.ini | 15:34 |
| azneita | that's now taken cared of. now, is it possible to change the timestamps to reflect the changes made on date? | 15:38 |
| nuclear_eclipse | azneita: that would require some sort of script to individually update all the timestamps to the new timezone.. =\ | 15:39 |
| azneita | that's more or less the answer i'm hoping to hear :) | 15:40 |
| azneita | again, many thanks! | 15:40 |
| nuclear_eclipse | you're welcome | 15:40 |
| superfly6 | hi | 17:03 |
| paul_____ | nuclear_eclipse: there? | 20:30 |
| paul_____ | dhx_m: there? | 21:04 |
| nuclear_eclipse | paul_____: here now | 21:17 |
| paul_____ | sec | 21:18 |
| paul_____ | can i generate a patch file from 3 changessets in one go? | 21:24 |
| paul_____ | http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a45059af-47a8-4c96-afe3-93dab7b5b658 | 22:53 |
| dhx_m | paul_____: hi | 23:09 |
| paul_____ | dhx_m: gonna see if I can get that working | 23:19 |
| paul_____ | for testing ldap stuff :) | 23:19 |
| dhx_m | paul_____: are you referring to creating a patch file? | 23:19 |
| paul_____ | I was | 23:20 |
| dhx_m | paul_____: I think you might need to create a branch | 23:20 |
| dhx_m | and then rebase that branch to bring all 3 commits together as one | 23:20 |
| dhx_m | then format-patch on the new 3-in-1 commit? | 23:20 |
| dhx_m | then you can delete the branch if not needed anymore | 23:21 |
| dhx_m | if you don't need to get back to 3 separate commits, just rebase the branch you're working off | 23:21 |
| paul_____ | nn | 23:44 |
| dhx_m | cya :) | 23:45 |
Generated by irclog2html.py