Save bugs as Draft

General discussion of Mantis.

Moderators: Developer, Contributor

Post Reply
hgaland
Posts: 8
Joined: 30 May 2005, 09:12
Location: Switzerland

Save bugs as Draft

Post by hgaland »

Hello, This is my first post on this forum.

I have posted a feature request on Mantis Site last week (Save bugs as Draft ....http://bugs.mantisbt.org/view.php?id=5628) but I still have no feedback.
My idea was to save a bug report as draft and come back later to post it as new.
This is possible with actual version (1.0.0a2) but this implies to give bug modification rights to reporters. My idea is to have the possibility to give modification rights only to the fields displayed when declaring the new bug in the issue reporting form (as long as it is not in the NEW_ or upper status) and to add a button (Save as Draft) to this form.

I think this will be an interesting feature, so I post it on the forum. What do you think about that.
thraxisp
Developer
Posts: 509
Joined: 14 Feb 2005, 03:38
Location: Ottawa, Canada
Contact:

Post by thraxisp »

You might be able to do this by changing an existing status (or adding a new one). You could create a status before new (Draft). When the reporter promotes it to new, the new bug messaging takes place.

I'd have to think this through, but it should work.
vboctor
Site Admin
Posts: 1293
Joined: 13 Feb 2005, 22:11
Location: Redmond, Washington
Contact:

Post by vboctor »

Another option is to add a mantis_bug_draft_table that is used to store these issues until they are submitted into the system. This means that bug_report has to be able to store in this table, bug_update_*_page has to be able to read from the draft, bug_update has to be able to update in the draft, and bug_view_*_page has to be able to view a draft. Also we need My Drafts section in the My View page to view a list of these issues. This will keep the drafts separate from the issues and will only submit an issue once they user requests that. At this stage the issue will be assigned an id, added to the mantis_bug_table, and the notifications will be sent.

That's just another way of implementing the feature. If we are "ever" going to implement this feature, then we need to compare the pros and cons of both options.

Regards,
Victor
MantisConnect
http://www.futureware.biz/mantisconnect
hgaland
Posts: 8
Joined: 30 May 2005, 09:12
Location: Switzerland

Post by hgaland »

thraxisp wrote:You might be able to do this by changing an existing status (or adding a new one). You could create a status before new (Draft). When the reporter promotes it to new, the new bug messaging takes place.

I'd have to think this through, but it should work.
I already though about this new "Draft" status and made a prototype in my workflow. It is possible to let the reporter to promote it, but if he needs to update information before doing that (because he was interrupted when posting his bug), he needs access to bug informations. As in mantis it is no possible to select wich information can then be updated, he is allowed also to set informations that are not in submission forms (simple and detailed) and he is not responsible of (ETA, projection...).

Not Good.....
hgaland
Posts: 8
Joined: 30 May 2005, 09:12
Location: Switzerland

Post by hgaland »

vboctor wrote:Another option is to add [....]

That's just another way of implementing the feature. If we are "ever" going to implement this feature, then we need to compare the pros and cons of both options.

Regards,
Victor
MantisConnect
http://www.futureware.biz/mantisconnect
This is the ideal solution, you are right. But it seems a little complexe and huge in developments.

My first idea was just:
To add a button in submit form in order to save the case in status DRAFT.
To declare thresholds to be able to view the button Update bug information and to modify just some bug infomation (defined in an array) as long as the the status is not NEW.

Of course we need, as you wrote, a change also in My View to see Draft Items.

I am not a specialist and may be this solution will require the same amount of work....

For the moment, the only solution I found is to invite users to put detailed information in a special word document (they can update later) and to put the link in the detailed information field. The problem is that they can continue once the case is in treatment and this is not acceptable in case of specifications or cost evaluation.

I think it will be a really nice feature, because in the real world reporters never have enought time to write a detailed request (with all reproduction details and screen captures) in one shot and within a short time (before connection time out) ....
hgaland
Posts: 8
Joined: 30 May 2005, 09:12
Location: Switzerland

Post by hgaland »

I did the implementation in our test system based on version 1.0.0a3.

You will find in #5628 (http://bugs.mantisbt.org/view.php?id=5628) the files modified to implement the feature. If the solution is acceptable for you, you can implement it in the feature release. It will be my contribution.

Enjoy it anyway !!!

FEATURE OVERVIEW
====================
All MANTIS usual access level threshold or feature defined with config_defaults_inc.php and config_inc.php are respected, including workflow features and action groups (view_all_bug_page). The only deference is that once an issue is DRAFT, it is considered as now modifiable for everybody except the reporter or at least a manager access level (global or project).

In addition, as long as the issue is not NEW, the reporter or manager can update SOME FIELDS and save again. But they cannot add NOTES (nor update or delete existing notes), send reminders or create childs.
The fields that can be updated are those available form the simple or detailed submission form.

IMPLEMENTATION GUIDE
====================
In : config_inc.php
# Activate draft feature by setting the value to DRAFT
$g_bug_draft_status = DRAFT; # instead of '%bug_submit_status%';

#define workflow components if required
$g_status_enum_workflow[DRAFT]= '10:new'; # for instance
$g_set_status_threshold = array(
NEW_ => REPORTER,
FEEDBACK => MANAGER,
ACKNOWLEDGED => MANAGER,
CONFIRMED => MANAGER,
ASSIGNED => MANAGER,
VALIDATED => REPORTER,
RESOLVED => DEVELOPER,
CLOSED => MANAGER );

#finaly you may need/want to tune Email setting to
# avoid notifications as long as issue is draft using
# $g_default_notify_flags, $g_notify_flags
Post Reply