View Issue Details

IDProjectCategoryView StatusLast Update
0003969mantisbtfeaturepublic2004-07-18 11:31
Reportermasc Assigned Tomasc  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
Product Version0.19.0a1 
Fixed in Version0.19.0a2 
Summary0003969: 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

TagsNo tags attached.
Attached Files
relationship_example.gif (21,573 bytes)   
relationship_example.gif (21,573 bytes)   
relationship_api.zip (4,556 bytes)
0_18_inc.zip (2,900 bytes)
relationship_dupl_id.zip (58,700 bytes)

Relationships

has duplicate 0001237 closedgrangeway Relationship graphs 
has duplicate 0000107 closedprescience We have a duplicate of, what about a related to bug 
has duplicate 0001594 closedmasc Provide the ability to make one bug dependant on another bug 

Activities

vboctor

vboctor

2004-06-24 02:10

manager   ~0005787

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.

vboctor

vboctor

2004-06-24 02:12

manager   ~0005788

Reminder sent to prescience

Ken, we will need your input on this one. Given that you have implemented this feature in the past.

masc

masc

2004-06-24 05:10

reporter   ~0005789

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.
We can have three types of relationship:

  • an issue is a duplicate of other already present in the DB
  • two issues are in relation at the same level (this means the relationship is just for clarification, from reader point of view)
  • one issue generates one or more child issues.

The last case is the most interesting. Tn case of mother-child relationship, the approach is:

  • to block the resolving/closing action of an issue until all the related childs are resolved/closed.
  • to inform the assigner of the mother issue when a child issue is "changed"
  • to store in the history of both the issues involved in a relationship when it is added or deleted
  • to give the permission of add/del a relationship based on the update permission of the related issue

I guess the files to be modified are:
Costant_inc.php (few lines)
Lang_xxx.php (few lines)
Relationship_api.php
History_api.php
Bug_view_page.php (few lines)
Bug_view_advance_page.php (few lines)

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.
Marcello

You can contact me directly via email, if you prefer

vboctor

vboctor

2004-06-24 08:29

manager   ~0005790

  • With regards to the history I think the history for both issues should be updated independent of the relation type. Also the history will be updated on add/update/delete. Updating the destination bug id, will result in a delete relationship in the old id, and add relationship on the new id.

  • Currently there is support for duplicate relationship, but it is implemented as a field rather than a relationship. Are we going to keep it this way, or change it? I think we should change the code to use the relationship since a relationship will appear on both issues involved, but currently "duplicate" only appears on the duplicate issue. We will also need to add a step in the upgrade script that will detected all the duplicate issues and add relationships for them.

  • I think we need to have two more indices on the relationship table. Once on the source bug id, and the other is on the destination bug id.

  • You are suggestion that when a "child" issues is changed, the parent owner should be notified. Shouldn't the same happen when a "related" issue is changed?

  • I assume a person who can update an issue, can update relationships relating to these issues.

  • In the view pages, I assume you will have something like this:
    Parent of: 12334, 3434, 3434 (all hyperlinked)
    Child of: 3433, 3434, 34343 (I assume an issue should be a child of several other issues)
    Related to: 1232, 23232, 2323
    Duplicate of: 1232, 2323, 2323

  • We should eventually consider adding a relationship graph, which starts from the current issue, and draws a tree (like the directory tree) which shows all issues related to the current issue. Then recursively do the same for these issues. However, this can be a second stage.

masc

masc

2004-06-24 09:32

reporter   ~0005791

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

thraxisp

thraxisp

2004-06-24 12:50

reporter   ~0005793

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?

MitchC

MitchC

2004-06-24 17:17

reporter   ~0005798

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.

masc

masc

2004-06-26 15:26

reporter   ~0005802

I'm proceeding with the development...
Regarding the proposal of thraxisp on the "child generation process", do you think it could be usefull to add a "create child button" on the bug menu?
I mean a facility to clone a child bug (all the information from the father), to automatically set the relationship with the father and to give to user the possibility to change/update some information before the final submit.

masc

masc

2004-06-28 15:45

reporter   ~0005807

Last edited: 2004-06-28 15:46

Inviato memorandum a vboctor

Victor,
developing the relationship feature, I discovered the bug_copy function is buggy. There are some open point. I think it's need a redesign of the function, to increase the redeability as well.
If you agree, I can try to do the job.

The development of the relationship feature is in good shape. Find attached some notes on it.
let me know you opinion.

--------------------------------------------------------

RELATIONSHIP DEFINITIONS

* Child/parent relationship:

the child bug is generated by the parent bug or is directly linked with the parent with the following meaning

the 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 dependance

bugs A and B are related

* Duplicates:

it's used to mark a bug as duplicate of an other bug already stored in the database

bug 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 OPEN

Just a warning is print out on the form when an user attempts to resolve or close a bug with

related 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/CLOSED

Every time a child bug is resolved or closed, an email notification is sent directly to all the handlers

of the parent bugs. The notification is sent to bugs not already marked as resolved or closed.

--------------------------------------------------------

STILL TO DO

delete all relationship of a bug (delete bug)

add copy relationships with function copy_bug

add clone bug functionality to auto-generate e child bug from a parent bug

--------------------------------------------------------

modificata il: 06-28-04 15:46

grangeway

grangeway

2004-06-30 12:55

reporter   ~0005843

Aside from bug_copy issues, when are you expecting you will have a possible patch for this feature?

masc

masc

2004-07-01 01:00

reporter   ~0005857

Tomorrow I will release the patch (without the copy bug function reviewed). And next week the copy bug function.
What do we do with the duplicate id field? Is it still necessary?

vboctor

vboctor

2004-07-01 01:34

manager   ~0005858

Masc,

  • Please go ahead and fix the issues with bug_copy() when you get a chance.

  • 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.

  • 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.

  • 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.

  • Are these relationships now displayed in simple/advanced/print view pages?

masc

masc

2004-07-01 02:13

reporter   ~0005859

My answer directly in your text:

<i>- Please go ahead and fix the issues with bug_copy() when you get a chance.</i>
OK, I will start the job after releasing the relationship patch

<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 take in charge to design the upgrade script for the DB

<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>
Done.

<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>
The idea (that is already implemented relaying on the old bug_copy function) is:

  • copy the bug (attachment included)
  • add the relationship between child and parent
  • add some lines in the history to record the copy action
    Regarding the possibility to copy or not attachment/history/bugnotes we can design a "dynamic" function, customizable using options.

<i>- Are these relationships now displayed in simple/advanced/print view pages</i>
Yes, look at the attached image.

vboctor

vboctor

2004-07-01 02:27

manager   ~0005860

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]
Related To | 00000222 | status | summary [delete]
Parent of | 00000444 | 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?

masc

masc

2004-07-01 04:55

reporter   ~0005861

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.
The suggestion for the English translation are welcome, as you probabibly have already understood my English is not so good...
In this versione it's implemented your suggestion on the relationship table.
I tried to concentrate all the functions regarding the relationships in this file to minimise the impact on the other source files.

Bye
Marcello

vboctor

vboctor

2004-07-01 08:22

manager   ~0005862

Following are the review comments:

  • Rename relationship_fetch() to relationship_get().
  • In relationship_get_linked_bug_id(), rename $p_rel_id to $p_relationship_id. In general do not use the "rel" abbreviation.
  • In email_relationship_child_resolved_closed(): Replace $t_rel with $t_relationship.
  • I think change "config_get( 'bug_resolved_status_threshold' ) > $t_status" to "$t_status < config_get( 'bug_resolved_status_threshold' )" makes it more readable.
  • In relationship_get_description(), split this into two methods one for each type. These methods should trigger an error if the received value is not one of the three known values.
  • Consider renaming "relationship_are_blocking_bugs_resolved" to "relationship_can_resolve_bug".
  • Why does the bug_relationship_delete.php need the bug id?
  • There should be no space between function names and the following (.
  • In relationship_view_box, you have open of php script blocks with capital PHP, use small php.
  • I assume when you post the final implementation, email methods will go to email_api.php, ...etc.

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.

MitchC

MitchC

2004-07-01 15:16

reporter   ~0005863

I like "Related To" too - shorter is better as long as it's clear, imho

masc

masc

2004-07-02 02:01

reporter   ~0005865

Here attached the "relationship package". In this version I took into account all your comments.

There are some completely new files:

  • bug_relationship_add.php
  • bug_relationship_delete.php
  • bug_create_child.php

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:
$g_enable_relationship = ON;

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

jferraz

jferraz

2004-07-07 20:19

reporter   ~0005898

0.19.0 is almost there, and this patch doesn't seem to be part of it... will it wait for 0.20.0? :-(

vboctor

vboctor

2004-07-07 20:50

manager   ~0005900

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 didn't want to add such big feature just before releasing.
  • I am waiting for Masc's test results so that we get the updated implementation and put it in CVS.
thraxisp

thraxisp

2004-07-08 13:54

reporter   ~0005935

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.

vboctor

vboctor

2004-07-08 16:42

manager   ~0005937

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.

masc

masc

2004-07-09 02:44

reporter   ~0005950

Reminder sent to vboctor

I tried to upload a new version of the patch but I got the following error:

APPLICATION ERROR #503
ERROR: Invalid upload path. Directory either does not exist or not writable to webserver

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.

vboctor

vboctor

2004-07-09 10:33

manager   ~0005960

Marcello, please try again to attach the update patch. As usuall please include the diff as well as the added/modified files.

masc

masc

2004-07-09 13:58

reporter   ~0005964

Victor the problem is still present... I'm not able to upload any file.

vboctor

vboctor

2004-07-11 03:11

manager   ~0005986

Marcello, can you please post the latest patch to mantisbt-dev@lists.sourceforge.net.

vboctor

vboctor

2004-07-11 08:29

manager   ~0005989

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.

jferraz

jferraz

2004-07-11 15:45

reporter   ~0005994

Last edited: 2004-07-11 15:46

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.";
$MANTIS_ERROR[ERROR_RELATIONSHIP_NOT_FOUND] = "ERROR: Relationship not found.";
$MANTIS_ERROR[ERROR_RELATIONSHIP_SAME_BUG] = "ERROR: an issue can't be related to it self.";</pre>

Obs: wasn't the "ERROR" prefix been deprecated?

<pre>$s_duplicate_of = "has duplicates";
$s_has_duplicate = "duplicates";</pre>

Obs: aren't they swapped?

BTW, it is working really nice in the CVS. Good work, masc!

edited on: 07-11-04 15:46

masc

masc

2004-07-12 02:07

reporter   ~0006003

The two remarks of Juliano are correct.

masc

masc

2004-07-15 03:57

reporter   ~0006054

Victor,
I prepared and attached here the upgrade script. It does the following:

  • Add index on source_bug_id field in mantis_bug_relationship_table
  • Add index on destination_bug_id field in mantis_bug_relationship_table
  • For each bug with the duplicate_id field filled out:
    Check if there is already a relationship set between bug and duplicate bug
    if yes then do nothing and continue with the next bug
    if no then
    add the relationship between bug and duplicate bug
    search in history of bug the line in which is recorded the duplicate id information
    and replace it with the appropriate history record for relationship (same user id, same time-stamp)
    add an history record in the duplicate bug with same user id, same time-stamp with bug
  • THE CONTENT OF THE DUPLICATE_ID FIELD IS NOT MODIFIED
vboctor

vboctor

2004-07-15 05:48

manager   ~0006056

Marcello, I had a look at your admin patch and following are my comments:

  • Use 018* prefix rather than 019 prefix. These upgrades are to be applied to 0.18.x versions since 0.19.0 is not yet released.

  • Bug history feature was added in 0.18.0, hence, in some databases (like this one), you will find all/some of the issues without history. Acoording to your current implementation the relation will not be added for there. I guess one you find a relation that is not added, you should first add it, then worry about work relating to updating history.

  • Integrate your script into the upgrade page. We should also consider making it part of the 0_18_inc.php file. This way the user will not have to do this as an explicit step, just do the normal upgrade.

vboctor

vboctor

2004-07-15 05:52

manager   ~0006058

Marcello, we also need to remove the duplicate id field from the following pages:

  • Issue view page (standard / advanced / print)
  • Issue upgrade page (standard / advanced)
  • Resolve page
  • csv_api.php remove from csv_get_columns().

However, as agreed the field should remain in the database.

nuclearspike

nuclearspike

2004-07-15 08:47

reporter   ~0006061

" Marcello, we also need to remove the duplicate id field from the following pages:

  • Resolve page"

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.

vboctor

vboctor

2004-07-15 08:52

manager   ~0006062

ok, I agree with Paul Ericksen, at least for now.

masc

masc

2004-07-15 09:49

reporter   ~0006063

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

vboctor

vboctor

2004-07-15 17:11

manager   ~0006073

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.

masc

masc

2004-07-16 14:37

reporter   ~0006094

Victor,
I attached the patch to hidden the duplicate_id from the view/update/print/cvs page.
Moreover I updated the bug_resolve in bug_api.php to implement the "auto-relationship" when a bug is closed filling the duplicate_id (as requested by Paul Ericksen). I mean: if the user resolves a bug filling the duplicate_id, mantis add a relationship between the bugs and then closes the bug.
I took the opportunity to:

  • apply your remarks on view box (font, italic, ...)
  • update the italian and english lang files
  • solved the bug 0003993

The patch is against CVS HEAD.

Marcello

vboctor

vboctor

2004-07-16 18:11

manager   ~0006097

Marcello, I applied the patch with some changes:

  • When checking the flag use OFF == config_get( '...' ) or ON == config_get( '...' ), do not use it as a boolean if ( config_get( '...' ).
  • I re-wrote the code that hides the duplicate id in the view/update pages. This is because your implementation left the field locations but kept them empty which isn't consistent with the way it is done for other hidden fields between simple/advanced page.
  • I was thinking that if the user enters a duplicate id, and he already added a relationship with the same duplicate id, then we should not trigger an error. I did not apply this change. If you are ok with it, post the change here.
masc

masc

2004-07-17 16:01

reporter   ~0006103

Implemented your remark and attached.

vboctor

vboctor

2004-07-17 23:18

manager   ~0006104

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.