View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003969 | mantisbt | feature | public | 2004-06-24 01:18 | 2004-07-18 11:31 |
Reporter | masc | Assigned To | masc | ||
Priority | normal | Severity | feature | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 0.19.0a1 | ||||
Fixed in Version | 0.19.0a2 | ||||
Summary | 0003969: Issue Relationships Support | ||||
Description | I'm implementing the relationship feature for Mantis because we absolutely need it at work. The solution is based on relationship_api.php with small changes. I don't know when it is foreseen to release the official implementation of this feature by the developer team. If you are interested, I will be happy to post here the patch. Let me know. Marcello | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
I need to look at the relationship_api.php, I think this was added by Ken long time ago, but I never looked at it. We are definately interested to get this into the development branch. I think it is an important feature to add to Mantis. However, I would suggest that you communicate with us to agree on the approach and the feature set that will be provided. This will reduce re-work and will get it faster into the codebase and hence less merging for you as well. |
|
Reminder sent to prescience Ken, we will need your input on this one. Given that you have implemented this feature in the past. |
|
The implementation is simple. The basic idea is to reuse all the APIs available and the table already available in which to store the relationships.
The last case is the most interesting. Tn case of mother-child relationship, the approach is:
I guess the files to be modified are: Two new files to manage adding and deleting of a relationship. I would like to release a first version by next monday (here in the company there is a strong pressure for that). Let me know. You can contact me directly via email, if you prefer |
|
|
|
vboctor I agree with you on all the points. In my opinion, the 'duplicate ID' information has to be moved to a relationship, then we will need an upgrade script. I'm going to start the work and I will keep you informed. Marcello |
|
Will there be a facility to duplicate a bug? For example, related issues may arise when someone files two issues in one report and you want to split it. How will the relationships be captured? |
|
Re notification... An existing problem with notification, is that lower level users are notified of private reports bugnotes that they can't even read. While I am all for this relationship notification, I see it compounding that problem. |
|
I'm proceeding with the development... |
|
Inviato memorandum a vboctor Victor, The development of the relationship feature is in good shape. Find attached some notes on it. --------------------------------------------------------RELATIONSHIP DEFINITIONS* Child/parent relationship:the child bug is generated by the parent bug or is directly linked with the parent with the following meaningthe child bug has to be resolved before resolving the parent bug (the child bug "blocks" the parent bug)example: bug A is child bug of bug B. It means: A blocks B and B is blocked by A* General relationship:two bugs related each other without any hierarchy dependancebugs A and B are related* Duplicates:it's used to mark a bug as duplicate of an other bug already stored in the databasebug A is marked as duplicate of B. It means: A duplicates B, B has duplicates# Relations are always visible in the email body--------------------------------------------------------ADD NEW RELATIONSHIP- Permission: user can update the source bug and at least view the destination bug- Action recorded in the history of both the bugs- Email notification sent to the users of both the bugs based based on the 'updated' bug notify type.--------------------------------------------------------DELETE RELATIONSHIP- Permission: user can update the source bug and at least view the destination bug- Action recorded in the history of both the bugs- Email notification sent to the users of both the bugs based based on the 'updated' bug notify type.--------------------------------------------------------RESOLVE/CLOSE BUGS WITH BLOCKING CHILD BUGS STILL OPENJust a warning is print out on the form when an user attempts to resolve or close a bug withrelated bugs in relation BUG_DEPENDANT still not resolved.Anyway the user can force the resolving/closing action.--------------------------------------------------------EMAIL NOTIFICATION TO PARENT BUGS WHEN CHILD BUGS ARE RESOLVED/CLOSEDEvery time a child bug is resolved or closed, an email notification is sent directly to all the handlersof the parent bugs. The notification is sent to bugs not already marked as resolved or closed.--------------------------------------------------------STILL TO DOdelete all relationship of a bug (delete bug)add copy relationships with function copy_bugadd clone bug functionality to auto-generate e child bug from a parent bug--------------------------------------------------------modificata il: 06-28-04 15:46 |
|
Aside from bug_copy issues, when are you expecting you will have a possible patch for this feature? |
|
Tomorrow I will release the patch (without the copy bug function reviewed). And next week the copy bug function. |
|
Masc,
|
|
My answer directly in your text: <i>- Please go ahead and fix the issues with bug_copy() when you get a chance.</i> <i>- We need to add a db upgrade step which would import all the data in the duplicate_id and create relations from it. We should add an issue to remove the duplicate_id field later (when we prove that the feature and upgrading is stable! However, we should be able to remove the duplicate_id field from the interface.</i> <i>- Make sure that when you are referring to resolved/closed that you are actually using the $g_resolved_status_threshold, or whatever the config name is.</i> <i>- Will the "clone" or "add child" make a copy of the bug and link it to the original as a parent? If so, I assume in this case we will not copy the history and attachments, right? Maybe we should detail this a bit.</i>
<i>- Are these relationships now displayed in simple/advanced/print view pages</i> |
|
Masc - Excellent work!!! Some comments ... I believe when we clone we should just copy the text fields / some selections. For example: project, category, severity, priority, description, addition information, steps to reproduce, platform, os, os version, build. We should probably not copy the following information: summary, fixed in version, relationships, history, monitor list, attachments, and bugnotes. The preview image looks good. I was imagining something different that I will mention any: Related To: 12345, 12323, 43434, 3434 Where the numbers are hyper linked and the title (bubble) shows the summary and status. The advantage of this approach is that it is compact. However, it is not suitable for the print pages. However, something closer to your suggestion: Related To | 00000123 | status | summary [delete] I also prefer "Related To" rather than "In relation with", but maybe we should get more opinions. With regards to the order of displaying the relationships, it is by type, then relationship creation order? or what? |
|
I have attached my version of the relationship_api.php so you can have a look and give to me your feedback before releasing all the package. Bye |
|
Following are the review comments:
Please when you post the final patch for me to apply, please also include all the modified and added files. I generally prefer using the merge tool rather than the patch tool which most of the time doesn't work for me. |
|
I like "Related To" too - shorter is better as long as it's clear, imho |
|
Here attached the "relationship package". In this version I took into account all your comments. There are some completely new files:
In all the others there are just some adding. Each modification is marked by the tag 'MASC RELATIONSHIP' (generally it is enclosed in between MASC RELATIONSHIP), so you have just to find the tag in source code to identify the change. The source files could be different in other points, not tagged, don't care of them. I have also included a new version of the bug_api.php in which it's resolved two bugs. One related to the missing physical copy of the files attached, the other one related to the default handler (see my comment in the code). The function has now more optional parameteres, and it's used by the bug_create_child.php to create the child bug. I added a new option to enable/disable the functionality: Other information are collected in the head of relationship_api.php. Today we're goint to start to test the fuctionality here in the company. I will not be able to answer to you till next monday due to holidays... :-) I hope you like job done. Marcello |
|
0.19.0 is almost there, and this patch doesn't seem to be part of it... will it wait for 0.20.0? :-( |
|
Nope, we are still in alpha. During alpha we can add more features. If this feature does not make it to 0.19.0rc1 (release candidate), then it will not make it in 0.19.0. I didn't want to add this in 0.19.0a1 for two reasons:
|
|
I patched my version and tried this today. The patch is complicated by other changes in the same files since your snapshot. The file bug_create_child.php seems to be missing from the archive. You also have some other changes intertwined in the files (ability to suppress platform and OS). Hopefully, you will also patch the config_defaults.php file to provide a default value for the controlling switches. Most of the functionality seems to work, except for the child creation. Great work. |
|
Thanks thraxisp for helping out with testing the patch. Marcello, ideally we need a patch against CVS HEAD which includes only changes related to this feature and including all necessary updates to config_defaults_inc.php and the upgrade. As probably mentioned before, please all include all modified and added files in the archive. |
|
Reminder sent to vboctor I tried to upload a new version of the patch but I got the following error: APPLICATION ERROR #503 I guess there is a problem in the config file Marcello PS Victor I submitted some 'minor' bugs related to HTML and so on. Please take them into account for the final release. It takes few minutes to be fixed. If you need support, don't esitate to ask me. |
|
Marcello, please try again to attach the update patch. As usuall please include the diff as well as the added/modified files. |
|
Victor the problem is still present... I'm not able to upload any file. |
|
Marcello, can you please post the latest patch to mantisbt-dev@lists.sourceforge.net. |
|
Version 1.1 of the patch is now applied to CVS. The main feature that is missing at the moment is the upgrade script that will take the duplicate_id field and generate relationships from it. As mentioned before, this field is NOT to be dropped till we are sure that the upgrade script and the bug relationship features are reliable. |
|
While updating strings_portuguese_brazil.txt, I've found this: <pre>$MANTIS_ERROR[ERROR_RELATIONSHIP_ALREADY_EXISTS] = "ERROR: There is already a relationship between these two issues."; Obs: wasn't the "ERROR" prefix been deprecated? <pre>$s_duplicate_of = "has duplicates"; Obs: aren't they swapped? BTW, it is working really nice in the CVS. Good work, masc! edited on: 07-11-04 15:46 |
|
The two remarks of Juliano are correct. |
|
Victor,
|
|
Marcello, I had a look at your admin patch and following are my comments:
|
|
Marcello, we also need to remove the duplicate id field from the following pages:
However, as agreed the field should remain in the database. |
|
" Marcello, we also need to remove the duplicate id field from the following pages:
I would expect that the input field should still be on this page, but it should create the relationship rather than setting the duplicate_id field. |
|
ok, I agree with Paul Ericksen, at least for now. |
|
I'm going to implement the changes based on the following rule: if enable_relationship = ON then duplicate_id field is not visible if enable_relationship = OFF then behaviour is as today This is a temporary solution to leave open the door to fallback to the past. In the meanwhile find attached the upgrade script updated to take into account Victor remarks |
|
I applied the upgrade patch with minor modifications. I also fixed the swapped strings in strings_english.txt as pointed out by Juliano. I guess the only thing that we are missing now is the visibility of the duplicate_id field. Can anyone thing of something else? Also if someone has suggestions with regards to the formatting of the relationships on the view pages, they are welcome. I personally do not like the italics, and I am sure we can achieve a nicer look. BTW, in the print page the font used for relationships is not the one used for the rest of the fields. |
|
Victor,
The patch is against CVS HEAD. Marcello |
|
Marcello, I applied the patch with some changes:
|
|
Implemented your remark and attached. |
|
Patch applied. I consider the feature complete and it will be released with 0.19.0a2. Thanks masc for your effort. We will probably track any further fixes or enhancements regarding this issue as new issues against 0.19.0a2 which will probably be released later today. |
|