| ../irclogs/#mantishelp.2010-01-27.log | ||
| --- scribe started --- | 00:00 | |
| nuclear_eclipse | dhx_m: there? | 03:39 |
|---|---|---|
| nuclear_eclipse | dhx_m: when you get a chance, I made the API changes to source integration that we discussed earlier | 03:43 |
| nuclear_eclipse | if you get a chance, can you look at the two last commits at http://git.mantisforge.org/w/source-integration.git?a=shortlog;h=refs/heads/redesign ? | 03:43 |
| nuclear_eclipse | any feedback you care to offer would be greatly appreciated | 03:44 |
| dhx_m | nuclear_eclipse: you write code fast :) | 05:59 |
| alemayo | which way would you suggest to add custom status levels on per project basis? I have read http://www.mantisforge.org/dev/manual/en/administration_guide/admin.customize.enums.html but this seems to work only globally ... | 06:28 |
| alemayo | it is of course possible to set the configuration options on per project base via the config database --- but I also need to always alter the translation string? | 06:28 |
| dhx_m | alemayo: bug 11041 | 06:34 |
| dhx_m | http://www.mantisbt.org/bugs/view.php?id=11041 | 06:34 |
| dhx_m | that blocks per-project custom statuses | 06:35 |
| alemayo | so that's just impossible ? | 06:35 |
| alemayo | hm | 06:35 |
| alemayo | okay, we could still use our terminology plugin to just rename a basic set of statuses for different projects | 06:36 |
| dhx_m | well it should be possible to get per-project statuses working | 06:36 |
| alemayo | how hard would that be ? | 06:36 |
| dhx_m | I imagine it's a bit of debugging and fiddling around within Mantis' core | 06:44 |
| dhx_m | not too much work though | 06:44 |
| dhx_m | alemayo: I might have it fixed now, just checking | 07:03 |
| alemayo | in master-1.3.x ? | 07:03 |
| mantisbot | Bug 11041 - dhx - open - confirmed | 07:05 |
| mantisbot | set_status_threshold doesn't work on a per-project basis - http://www.mantisbt.org/bugs/view.php?id=11041 | 07:05 |
| dhx_m | both :) | 07:11 |
| alemayo | it's fixed ? | 07:20 |
| alemayo | so what would be the way now to have custom statuses per project? we still need to fix the language string per project, don't we ? | 07:20 |
| dhx_m | well the status enum string isn't translatable at the moment | 07:23 |
| dhx_m | neither are any other enum strings | 07:23 |
| dhx_m | afaik | 07:23 |
| dawitaya_ | hi | 07:24 |
| dawitaya_ | hello dh_m is it possible to make Assign To must field on report issues | 07:24 |
| dhx_m | dawitaya: hi, that functionality isn't built in at present | 07:26 |
| dhx_m | so you'd have to hack bug_report_page.php and bug_report.php | 07:26 |
| dhx_m | the category is currently forced, so you can use that as an example | 07:27 |
| alemayo | dhx_m: but there are a lot of enum translations in the lang files as far as I remember | 07:32 |
| dhx_m | I haven't looked at it in detail gyi | 07:33 |
| dhx_m | *fyi | 07:33 |
| alemayo | for example on http://www.mantisforge.org/dev/manual/en/administration_guide/admin.customize.enums.html it says that we also have to fix the s_.... language consnts | 07:34 |
| dawitaya_ | dhx_m: why assignto not define on constant_inc.php | 07:56 |
| dawitaya_ | dhx_m Ok I found it they name it handlet Id thanks | 08:52 |
| alemayo | dhx_m: without s_status_enum_string no custom configurations ... | 11:47 |
| alemayo | dhx_m: that's really a hassle, because it makes that whole custom-status-on-per-project-basis very ugly :( | 11:48 |
| dhx_m | can't you set it in the database config | 11:48 |
| dhx_m | using the "complex" data type | 11:48 |
| alemayo | can I set s_xxxx in the database config ? | 11:53 |
| dhx_m | oh, strings... | 11:54 |
| alemayo | jep | 11:54 |
| dhx_m | I forgot about those | 11:54 |
| alemayo | they destroy that whole db-config concept concerning enums :( | 11:54 |
| dhx_m | unfortunately not | 11:54 |
| dhx_m | yeah it does | 11:54 |
| dhx_m | we really need per-project language files I guess | 11:55 |
| alemayo | that's a bit the idea of our Terminology plugin | 11:55 |
| alemayo | oh it's working via the plugin :) | 11:57 |
| dhx_m | :) | 11:57 |
| alemayo | but of course it is not smart enough | 12:05 |
| alemayo | the terminology plugin checks what is the currently selected project | 12:05 |
| alemayo | what if we view issues from all of the projects that have different statuses | 12:05 |
| alemayo | I am wondering if the configuration backend is smart enough in this case to select the proper g_status_enum_string per bug | 12:05 |
| alemayo | anyway -- in the practial use the projects will be quite well seperated | 12:06 |
| alemayo | maybe we should just add a whole bunch of statuses on a global base and limit the ones that are accessible per project by the workflow configuration | 12:06 |
| dhx_m | not with config_get | 12:11 |
| dhx_m | well it's possible if you pass a project ID to config_get | 12:11 |
| rolfkleef | alemayo: that's what we have done | 12:11 |
| dhx_m | I suppose | 12:11 |
| dhx_m | rolfkleef: welcome :) | 12:19 |
| alemayo | rolfkleef: how many different stati / projects are you handling with mantis ? | 12:20 |
| rolfkleef | alemayo: we try to keep it simple, so we have two main workflows right now | 12:25 |
| rolfkleef | 1) issues in projects and SLAs: new-feedback-acknowledged-confirmed-in work plan-testing-resolved-closed | 12:25 |
| rolfkleef | 2) project management/acquisition: new-information-proposal-contract-in progress-closure-closed | 12:26 |
| alemayo | how does your status_enum_string look like ? | 12:26 |
| rolfkleef | so that second workflow is only in our "Project Management" project | 12:27 |
| rolfkleef | g_status_enum_string = "10:new,15:acknowledged,20:feedback,25:information,35:proposal,37:contract,40:confirmed,50:assigned,60:inprogress,70:testing,75:evaluation,80:resolved,90:closed" | 12:28 |
| alemayo | ok .. an then you clicked a lot in the workflow configuration? | 12:31 |
| rolfkleef | yes | 12:32 |
| rolfkleef | set the default for all projects to workflow 1, then override for that one project to create workflow 2 | 12:32 |
| rolfkleef | you'll normally see only the stati from 1) under the view_all_bug_page list, and only those from 2) when you're in that specific project | 12:35 |
| alemayo | yes ... | 12:35 |
| alemayo | the problem is, I am we are not yet sure for how many projects we will use mantis | 12:35 |
| alemayo | they might have different workflows each | 12:36 |
| alemayo | I am considering to add maybe some statuses like 51:step1, 52:step2, 53:step3 and so on and overwrite them on per project basis in the lang_... | 12:36 |
| alemayo | and I found out that our current workflow always flows backwarts .. we first assign and then the handler changes to confirmed ... so that means from value 50 to 40 ... | 12:37 |
| alemayo | maybe 60:step1,61:step2,...68:step9 ... that's somehow more flexible | 12:40 |
| alemayo | but I start seeing the limits of the multi-project configurations that are possible | 12:40 |
| rolfkleef | yes, a lot of different workflows is hard - and we also had more statuses/stati earlier on, but went back to less again | 12:42 |
| rolfkleef | we've switched off the automatic switching of status when you assign an issue | 12:42 |
| rolfkleef | and also relabeled "assigned" to "in work plan" | 12:42 |
| rolfkleef | rationale: we try to assign an issue as soon as possible, so that someone is the "owner" and responsible to make sure it moves forward | 12:43 |
| alemayo | yes, similar to what we do | 12:43 |
| alemayo | so basically everything between new and assigned is not really used | 12:44 |
| rolfkleef | yes it is - that's why we relabeled "assigned": our interpretation of that status as "in work plan" is that the assigned person is doing the associated work in the coming one or two weeks | 12:46 |
| alemayo | you did that relabling in s_status_enum_string ? | 12:46 |
| rolfkleef | phase 1 is "intake", new-feedback-acknowledged-confirmed (with the assigned person overseeing it happens) | 12:47 |
| rolfkleef | phase 2 is "plan and do", taking a couple of "confirmed" issues and putting them in your workplan ("in work plan"), with priority of what needs to go first, and the moving those to testing/resolved | 12:48 |
| rolfkleef | so yes, $s_status_enum_string='10:new,15:acknowlegded,20:feedback,25:information,35:proposal,37:contract,40:confirmed,50:in work plan,60:in progress,70:testing,75:closure,80:resolved,90:closed'; | 12:49 |
| alemayo | I am not so happy with mixing two different workflows into the status_enum_string ... | 12:50 |
| alemayo | It's confusing somehow | 12:50 |
| alemayo | rolfkleef: which kind of work is your company/unit doing? is it software development? | 12:50 |
| rolfkleef | well, there are more things in Mantis I am not so happy with :-) but once done, it's easy to work with | 12:51 |
| alemayo | because we absolutly don't:) mostly we are totally abusing mantis ... | 12:51 |
| rolfkleef | we're doing mainly web platform development and hosting, yeah | 12:51 |
| rolfkleef | but I've tried to abuse mantis some years ago for the work flows in a funding organisation as well | 12:52 |
| rolfkleef | that didn't go well because a lot of the "software dev" elements of issues are pretty much hard-wired into Mantis still, and it's not easy to completely change the layout of pages AND be able to upgrade to newer versions | 12:54 |
| alemayo | mh ... we did pretty much customization using various plugins | 13:06 |
| alemayo | but in parallel we are also evaluation BPMN software now ... | 13:06 |
| rolfkleef | would sure be interesting to have a BPMN <-> Mantis config tool to document/generate the work flows in Mantis | 13:22 |
| nuclear_eclipse | dhx_m: still there? | 15:18 |
| HarvesterOfBeer | hola | 17:23 |
| HarvesterOfBeer | is there an ETA for the 1.2 release? | 17:23 |
| HarvesterOfBeer | we are contemplating some code customizations to our 1.1.8 install and I don't want to have to re-do them if 1.2 is around the corner... | 17:24 |
Generated by irclog2html.py