| ../irclogs/#mantishelp.2010-07-12.log | ||
| --- scribe started --- | 00:00 | |
| mantisbt_27964 | hi all | 08:44 |
|---|---|---|
| mantisbt_27964 | I have a quick question: is there a way to set up a list of approvers in Mantis? Sometimes one solution has to be approved not by only one person | 08:45 |
| dhx_m | odd terminology... | 09:30 |
| mantisbt_27964 | another question: | 10:48 |
| dhx_m | I didn't answer your first? :) | 10:49 |
| dhx_m | oh I get the point of your first question | 10:49 |
| dhx_m | it's not possible at the moment | 10:49 |
| mantisbt_27964 | when a new user is created the Email on Status change and the Email on priority change is unchecked by default? How can I change it to be checked | 10:49 |
| dhx_m | but definitely something we'd be aiming to implement | 10:49 |
| mantisbt_27964 | oh ok | 10:49 |
| mantisbt_27964 | thanks for answering the 1st :) | 10:49 |
| dhx_m | you can sort of work around it though | 10:49 |
| dhx_m | by setting up two status levels and only allowing certain people to use the first status and another set of approvers to use the second status | 10:50 |
| mantisbt_27964 | acually I have no php knowledge and problem is not that urgent, so I think I will live with one approver | 10:50 |
| mantisbt_27964 | yeah | 10:50 |
| mantisbt_27964 | thats what I thought | 10:50 |
| mantisbt_27964 | however its obviously can create lots of phases | 10:50 |
| dhx_m | but it's not the same as requiring 2 people to approve a change to a bug | 10:50 |
| dhx_m | it's something I was looking at fixing with an overhaul of the access system to use RBAC | 10:51 |
| mantisbt_27964 | but its ok, I will work it out somehow. Since our process is still formulating, I will push fwd to have one approver only | 10:51 |
| dhx_m | but it's just some ideas at the moment... no code written | 10:51 |
| mantisbt_27964 | later if this gonna be implemented we can change | 10:51 |
| dhx_m | 2nd question... | 10:51 |
| dhx_m | * @todo Unused | 10:53 |
| dhx_m | * @global int $g_default_email_on_status | 10:53 |
| dhx_m | */ | 10:53 |
| dhx_m | $g_default_email_on_status = 0; | 10:53 |
| dhx_m | * @todo Unused | 10:53 |
| dhx_m | * @global int $g_default_email_on_priority | 10:53 |
| dhx_m | */ | 10:53 |
| dhx_m | $g_default_email_on_priority = 0; | 10:53 |
| dhx_m | email/notifications is also *very* high on the agenda to rewrite | 10:53 |
| dhx_m | it's currently in a very bad shape relative to the rest of MantisBT | 10:53 |
| mantisbt_27964 | acually I have a third as well... resolved state is prior to the closed state. I assume - and correct me if I am wrong - by the default process an issue can go to CLOSED when the originator of the issue approved the solution at the RESOLVED state | 10:54 |
| dhx_m | old buggy code :( | 10:54 |
| mantisbt_27964 | will it change to the 1.3.0? | 10:54 |
| dhx_m | it's too early to say what will change with 1.3.0... afaik filters will be redone | 10:54 |
| mantisbt_27964 | sounds great | 10:55 |
| dhx_m | no other code has been written for 1.3.0 with respect to notifications, RBAC or the other major change proposed: a new fields API | 10:55 |
| dhx_m | it's just a case of developer time (it's a hobby/side project for most developers) | 10:55 |
| dhx_m | afaik we no longer have any developers who are paid to work on MantisBT | 10:56 |
| mantisbt_27964 | I am sorry to hear that | 10:56 |
| dhx_m | quality patches are committed fairly quickly though if anyone submits some :) | 10:57 |
| mantisbt_27964 | I try to push the company to delegate Mantis as prefered system. I wont forget to mention to donate if the project is successful | 10:57 |
| dhx_m | with projects like this, money isn't an issue... it's more valuable to have developers who are paid by their companies to work on MantisBT as part of their jobs | 10:58 |
| mantisbt_27964 | it wont hurt though :) | 10:59 |
| dhx_m | the reason being that the best changes/work is done by those who have a reason for making the changes | 10:59 |
| dhx_m | ie. their company wants an issue tracker with issue X and to make that happen, they have to write their own code... so they decide to pick an open source issue tracker to improve (rather than write their own from scratch) | 11:00 |
| dhx_m | donations are good for projects that have a GSoC (Google Summer of Code) program or equivalent setup | 11:00 |
| dhx_m | but then you have to start worrying about legalities/taxes (internationally too) which is complex/time consuming | 11:01 |
| mantisbt_27964 | oh ok | 11:01 |
| mantisbt_27964 | I see now | 11:01 |
| dhx_m | (not trying to discourage help, just pointing out the difficulties involved) | 11:01 |
| mantisbt_27964 | :) | 11:03 |
| mantisbt_27964 | can you check this out: | 11:03 |
| mantisbt_27964 | resolved state is prior to the closed state. I assume - and correct me if I am wrong - by the default process an issue can go to CLOSED when the originator of the issue approved the solution at the RESOLVED state | 11:03 |
| mantisbt_27964 | so I think the closed status is the final status of a bug | 11:06 |
| dhx_m | that has probably changed completely in http://git.mantisbt.org/?p=mantisbt.git;a=commit;h=035a1302792ada9ba36ed1d729542ea629de8cca | 11:06 |
| mantisbt_27964 | but the documentation says changelog shows issues in the resolved state | 11:06 |
| dhx_m | that commit (for 1.3.0) fixes many bugs related to changing of statuses | 11:06 |
| dhx_m | $g_allow_reporter_close toggles the feature you refer to | 11:07 |
| dhx_m | if I understand you correctly | 11:07 |
| dhx_m | basically it allows the reporter to bypass the usual check to see if they're allowed to change the status from resolved => closed | 11:08 |
| mantisbt_27964 | I am fine with that | 11:08 |
| mantisbt_27964 | I try to do the following process: | 11:08 |
| mantisbt_27964 | assigne - accepted - in work - in review - verification - RESOLVED - CLOSED | 11:09 |
| mantisbt_27964 | verification to RESOLVED need a manager approval | 11:09 |
| mantisbt_27964 | and when its done the customer evaluates the solution and moves the issue to the closed staet | 11:09 |
| mantisbt_27964 | state | 11:10 |
| mantisbt_27964 | but if changelog shows the resolved issues only then when its closed it wont show up there | 11:10 |
| mantisbt_27964 | I think I have a hard time to understand the diff between roadmap (which I found GREAT) and changelog | 11:10 |
| dhx_m | roadmap = lists bugs targeted towards versions that have yet to be released (with the 'released' flag on versions) | 11:11 |
| mantisbt_27964 | yes | 11:11 |
| dhx_m | changelog = lists bugs targeted towards versions that have already been released (but not flagged as 'obsolete') | 11:11 |
| mantisbt_27964 | hmmm | 11:11 |
| dhx_m | regarding manager approval of status changes, use $g_set_status_threshold | 11:12 |
| mantisbt_27964 | and is that true that an issue only shows up there if its status is resolved? | 11:12 |
| mantisbt_27964 | yeah I have no problems with the manager approval thing | 11:12 |
| mantisbt_27964 | and the reporter can close the issue | 11:12 |
| dhx_m | the changelog only shows resolved issue | 11:12 |
| dhx_m | *issues | 11:12 |
| mantisbt_27964 | I am just wondering about the changelog thing | 11:12 |
| dhx_m | the roadmap shows everything | 11:12 |
| dhx_m | (in terms of status) | 11:12 |
| mantisbt_27964 | is there a way to remove the changelog tab (I wont use it in the close future and will turn on later) | 11:13 |
| dhx_m | if you've setup a custom workflow I *strongly* recommend you go through config_defaults_inc.php and check all the access levels to see if you need to change them | 11:13 |
| dhx_m | you'd have to modify the code to do that (quite easy to do though) | 11:13 |
| dhx_m | see core/html_api.php in the print_menu() function | 11:14 |
| dhx_m | search for: | 11:14 |
| dhx_m | # Changelog Page | 11:14 |
| dhx_m | if( access_has_project_level( config_get( 'view_changelog_threshold' ) ) ) { | 11:14 |
| dhx_m | $t_menu_options[] = '<a href="' . helper_mantis_url( 'changelog_page.php">' ) . lang_get( 'changelog_link' ) . '</a>'; | 11:14 |
| dhx_m | } | 11:14 |
| dhx_m | and delete that | 11:14 |
| dhx_m | oops | 11:14 |
| mantisbt_27964 | I think I have configured my process fine by using the forms in the mantis, so no problems with that! | 11:14 |
| dhx_m | just set $g_view_changelog_threshold to 999 | 11:14 |
| dhx_m | more precisely, set it to NOBODY (a constant) | 11:15 |
| mantisbt_27964 | sweeet! | 11:15 |
| mantisbt_27964 | problem solved :) | 11:15 |
| dhx_m | :) | 11:15 |
| mantisbt_27964 | even better to set to administrator | 11:16 |
| mantisbt_27964 | I am an admin | 11:16 |
| mantisbt_27964 | so I can use it to experiment with its behaviour | 11:16 |
| dhx_m | yep | 11:16 |
| mantisbt_27964 | but not let the users confused by that until I can not explain them very well what it is | 11:16 |
| mantisbt_27964 | are you familiar with the summary graphs? | 11:19 |
| dhx_m | kind of | 11:19 |
| dhx_m | those graphs are old code | 11:19 |
| mantisbt_27964 | http://www.mantisbt.org/bugs/view.php?id=12159 | 11:19 |
| dhx_m | a little bit buggy with respect to fonts | 11:19 |
| mantisbt_27964 | I have filed this issue today | 11:19 |
| mantisbt_27964 | do you have any idea about it? | 11:20 |
| dhx_m | try using JpGraph instead of ezC? | 11:20 |
| dhx_m | it looks to me like a case of missing fonts or something of that nature | 11:20 |
| dhx_m | fyi JpGraph is a commercial alternative so it might not be satisfactory for you on licensing grounds | 11:21 |
| mantisbt_27964 | I thought I use jpgraph | 11:22 |
| mantisbt_27964 | but not sure | 11:22 |
| mantisbt_27964 | I just installed the graph 1.0.0 plugin | 11:22 |
| dhx_m | MantisGraph? the one that is bundled with MantisBT? | 11:23 |
| mantisbt_27964 | yes | 11:24 |
| dhx_m | ok | 11:24 |
| dhx_m | there is a configuration page for MantisGraph that has a bunch of options you can try toggling | 11:24 |
| dhx_m | try different fonts, etc | 11:24 |
| mantisbt_27964 | oh | 11:24 |
| mantisbt_27964 | where is that? | 11:24 |
| mantisbt_27964 | I can not see a new tab or so | 11:25 |
| dhx_m | Manage Plugins page, click on MantisGraph | 11:25 |
| mantisbt_27964 | got it | 11:25 |
| mantisbt_27964 | just click on name | 11:25 |
| dhx_m | yep | 11:25 |
| mantisbt_27964 | no it says "bundled". Can I use "jpgraph" for free in a company enviroment? | 11:25 |
| mantisbt_27964 | "now it says..." | 11:26 |
| mantisbt_27964 | it seems I not even have the jpgraph thingy because it gives me an error message (no such file or directory) | 11:26 |
| dhx_m | "JpGraph is released under a dual license. QPL 1.0 (Qt Free Licensee) For non-commercial, open-source or educational use and JpGraph Professional License for commercial use. The professional version also includes additional features and support." | 11:27 |
| dhx_m | perhaps not | 11:27 |
| dhx_m | we can't bundle it with MantisBT like we do ezC | 11:27 |
| mantisbt_27964 | so I guess ezC is the "bundled" | 11:28 |
| dhx_m | yep | 11:28 |
| mantisbt_27964 | I dont think it ttf related. I have tried all the options and I got the same result all the time :( | 11:30 |
| dhx_m | yeah it needs some work (the graphs) | 11:35 |
| mantisbt_27964 | I have another question | 12:05 |
| mantisbt_27964 | lets say I'd like to implement 2 different processes in Mantis, one for SW and one for HW | 12:05 |
| mantisbt_27964 | these for sure have different phase | 12:05 |
| mantisbt_27964 | can I do that? | 12:05 |
| mantisbt_27964 | AND which script is responsible for sending out the mails? I'd like to change the subject of a mail. I know there is no built in funtcion for that, but I guess I can do it manually | 12:11 |
| mantisbt_27964 | I think I have it: email_api.php, email_build_subject | 12:16 |
| mantisbt_27964 | previous question still valid | 12:16 |
| mantisbt_27964 | dhx_m: whats wrong with this script: $p_handler = project_get_field( bug_get_field( $p_bug_id, 'handler' ), 'name' ); | 12:34 |
| dhx_m | mantisbt_27964: sure, you just need 2 projects (where each project can have completely different settings) | 12:40 |
| dhx_m | project_get_field ( handler_id, 'name' ) seems the wrong way around? | 12:41 |
| dhx_m | check project_api.php for documentation of the function | 12:41 |
| mantisbt_27964 | I will do some workaround in the emailing thingy | 12:42 |
| mantisbt_27964 | but yes, there is a chance that we need to setup different phases | 12:42 |
| mantisbt_27964 | is it possible in Mantis? | 12:43 |
| dhx_m | you can have a different workflow for each project | 12:48 |
| mantisbt_27964 | now I see | 12:49 |
| mantisbt_27964 | sweet | 12:49 |
| dhx_m | you store the arrays in the database | 12:50 |
| mantisbt_27964 | I though this setup is applicable for ALL the projects and can not be configured individually | 12:50 |
| dhx_m | note that the UI for adding complex configuration (arrays) is a bit ugly | 12:50 |
| mantisbt_27964 | but now I see I can define a whole bunch of different phases and then apply them for certain projects! | 12:50 |
| dhx_m | the array has to be defined on a single line using integers (not constants) | 12:50 |
| dhx_m | yep | 12:50 |
| dhx_m | everything is per-project | 12:50 |
| dhx_m | including strings | 12:50 |
| mantisbt_27964 | great | 12:50 |
| mantisbt_27964 | I have started testing Mantis 2 weeks ago and I am very impressed! | 12:51 |
| dhx_m | :) | 12:56 |
| mantisbt_27964 | p_handler = project_get_field( bug_get_field( $p_bug_id, 'handler_id' ), 'name' ); gives back the project name | 12:59 |
| mantisbt_27964 | I need the handler name | 12:59 |
| mantisbt_27964 | but p_handler = bug_get_field( $p_bug_id, 'handler_id' ) | 12:59 |
| mantisbt_27964 | gives back a number I guess | 12:59 |
| dhx_m | yes | 12:59 |
| mantisbt_27964 | instead of the username of the handler. So I need to turn the number to a username | 13:00 |
| dhx_m | there should be an example of how to get the handler name in bug_view_inc.php | 13:00 |
| mantisbt_27964 | I think building a custom email subject wont be a very different task. Its a shame that I dont know php good enough | 13:06 |
| mantisbt_27964 | maybe later on when I get the experience I can come out with a script | 13:06 |
| mantisbt_27964 | fingers cross | 13:24 |
| mantisbt_27964 | I will demo the Mantis to managers now | 13:24 |
| nuclear_eclipse | dhx_m: hi | 13:28 |
| lhavelund | Erm, isn't it possible to change the category of an issue after it has been posted? | 21:19 |
| moto-moi | Ofcourse it is possible to change that :) | 21:20 |
| lhavelund | I don't see where :\ | 21:20 |
| moto-moi | just click the 'edit'-button? :) | 21:20 |
| lhavelund | Ahh, right. <_<; | 21:21 |
| lhavelund | I couldn't find it on the view page | 21:21 |
| moto-moi | np :) | 21:22 |
| docgnome | i have some reporters who are suddenly unable to see the report issue link on 1.2.1 | 21:23 |
Generated by irclog2html.py