Received: by otc-msg01.altera.com 
	id <01C46E9E.008BB320@otc-msg01.altera.com>; Tue, 20 Jul 2004 17:10:36 -0400
Message-ID: <437639d0bd44ff1696c34c6f310fb883@bugs.mantisbt.org>
From: mantis@mantisbt.org
To: Glenn Henshaw <ghenshaw@altera.com>
Subject: [mantisbt 0003969]: Issue Relationships Support
Date: Tue, 20 Jul 2004 16:07:27 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


E' stata aggiunta una RELAZIONE alla seguente anomalia.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http://bugs.mantisbt.org/bug_view_advanced_page.php?bug_id=3D0003969
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Reported By:                masc
Assigned To:                masc
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Project:                    mantisbt
Issue ID:                   3969
Category:                   feature
Reproducibility:            sempre
Severity:                   nuova funzionalit=E0
Priority:                   normale
Status:                     chiuso
Fixed in Release:          =20
Resolution:                 risolto
Fixed in Version:           0.19.0a2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Date Submitted:             06-24-2004 01:18 EDT
Last Modified:              07-18-2004 11:31 EDT
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Summary:                    Issue Relationships Support
Description:=20
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Relazioni                ID      Stato         =20
----------------------------------------------------------------------
duplica il               0001237 chiuso        =20
relativo al              0001594 nuovo         =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Total Sponsorship =3D US$ 10

11-14-10 14:49: dcodres (US$ 5)
03-26-11 14:49: virtuetek (US$ 5)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

----------------------------------------------------------------------
 VictorBoctor - 06-24-04 02:10=20
----------------------------------------------------------------------
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.

----------------------------------------------------------------------
 VictorBoctor - 06-24-04 02:12=20
----------------------------------------------------------------------
Reminder sent to prescience

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

----------------------------------------------------------------------
 masc - 06-24-04 05:10=20
----------------------------------------------------------------------
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

----------------------------------------------------------------------
 VictorBoctor - 06-24-04 08:29=20
----------------------------------------------------------------------
- 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.=20
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 - 06-24-04 09:32=20
----------------------------------------------------------------------
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 - 06-24-04 12:50=20
----------------------------------------------------------------------
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 - 06-24-04 17:17=20
----------------------------------------------------------------------
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 - 06-26-04 15:26=20
----------------------------------------------------------------------
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 - 06-28-04 15:46=20
----------------------------------------------------------------------
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 - 06-30-04 12:55=20
----------------------------------------------------------------------
Aside from bug_copy issues, when are you expecting you will have a
possible
patch for this feature?

----------------------------------------------------------------------
 masc - 07-01-04 01:00=20
----------------------------------------------------------------------
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?

----------------------------------------------------------------------
 VictorBoctor - 07-01-04 01:34=20
----------------------------------------------------------------------
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 - 07-01-04 02:13=20
----------------------------------------------------------------------
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.

----------------------------------------------------------------------
 VictorBoctor - 07-01-04 02:27=20
----------------------------------------------------------------------
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 - 07-01-04 04:55=20
----------------------------------------------------------------------
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

----------------------------------------------------------------------
 VictorBoctor - 07-01-04 08:22=20
----------------------------------------------------------------------
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 - 07-01-04 15:16=20
----------------------------------------------------------------------
I like "Related To" too - shorter is better as long as it's clear, imho

----------------------------------------------------------------------
 masc - 07-02-04 02:01=20
----------------------------------------------------------------------
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 =3D 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

----------------------------------------------------------------------
 Juliano Ravasi Ferraz - 07-07-04 20:19=20
----------------------------------------------------------------------
0.19.0 is almost there, and this patch doesn't seem to be part of it...
will it wait for 0.20.0? :-(

----------------------------------------------------------------------
 VictorBoctor - 07-07-04 20:50=20
----------------------------------------------------------------------
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 - 07-08-04 13:54=20
----------------------------------------------------------------------
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.

----------------------------------------------------------------------
 VictorBoctor - 07-08-04 16:42=20
----------------------------------------------------------------------
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 - 07-09-04 02:44=20
----------------------------------------------------------------------
Reminder sent to vboctor

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

APPLICATION ERROR
http://bugs.mantisbt.org/bug_view_advanced_page.php?bug_id=3D0000503=20
ERROR: Invalid upload path. Directory either does not exist or not
writable to webserver
=20
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.

----------------------------------------------------------------------
 VictorBoctor - 07-09-04 10:33=20
----------------------------------------------------------------------
Marcello, please try again to attach the update patch.  As usuall =
please
include the diff as well as the added/modified files.

----------------------------------------------------------------------
 masc - 07-09-04 13:58=20
----------------------------------------------------------------------
Victor the problem is still present... I'm not able to upload any file.

----------------------------------------------------------------------
 VictorBoctor - 07-11-04 03:11=20
----------------------------------------------------------------------
Marcello, can you please post the latest patch to
mantisbt-dev@lists.sourceforge.net.

----------------------------------------------------------------------
 VictorBoctor - 07-11-04 08:29=20
----------------------------------------------------------------------
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.

----------------------------------------------------------------------
 Juliano Ravasi Ferraz - 07-11-04 15:46=20
----------------------------------------------------------------------
While updating strings_portuguese_brazil.txt, I've found this:

<pre>$MANTIS_ERROR[ERROR_RELATIONSHIP_ALREADY_EXISTS] =3D "ERROR: There =
is
already a relationship between these two issues.";
$MANTIS_ERROR[ERROR_RELATIONSHIP_NOT_FOUND] =3D "ERROR: Relationship =
not
found.";
$MANTIS_ERROR[ERROR_RELATIONSHIP_SAME_BUG] =3D "ERROR: an issue can't =
be
related to it self.";</pre>

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

<pre>$s_duplicate_of =3D "has duplicates";
$s_has_duplicate =3D "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 - 07-12-04 02:07=20
----------------------------------------------------------------------
The two remarks of Juliano are correct.

----------------------------------------------------------------------
 masc - 07-15-04 03:57=20
----------------------------------------------------------------------
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

----------------------------------------------------------------------
 VictorBoctor - 07-15-04 05:48=20
----------------------------------------------------------------------
Marcello, I had a look at your admin patch and following are my
comments:

- Use 0_18_* prefix rather than 0_19_ 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.=20
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.

----------------------------------------------------------------------
 VictorBoctor - 07-15-04 05:52=20
----------------------------------------------------------------------
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.

----------------------------------------------------------------------
 Paul Ericksen - 07-15-04 08:47=20
----------------------------------------------------------------------
" 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.

----------------------------------------------------------------------
 VictorBoctor - 07-15-04 08:52=20
----------------------------------------------------------------------
ok, I agree with Paul Ericksen, at least for now.

----------------------------------------------------------------------
 masc - 07-15-04 09:49=20
----------------------------------------------------------------------
I'm going to implement the changes based on the following rule:

if enable_relationship =3D ON then duplicate_id field is not visible

if enable_relationship =3D 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

----------------------------------------------------------------------
 VictorBoctor - 07-15-04 17:11=20
----------------------------------------------------------------------
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 - 07-16-04 14:37=20
----------------------------------------------------------------------
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
http://bugs.mantisbt.org/bug_view_advanced_page.php?bug_id=3D0003993

The patch is against CVS HEAD.

Marcello

----------------------------------------------------------------------
 VictorBoctor - 07-16-04 18:11=20
----------------------------------------------------------------------
Marcello, I applied the patch with some changes:

- When checking the flag use OFF =3D=3D config_get( '...' ) or ON =
=3D=3D
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 - 07-17-04 16:01=20
----------------------------------------------------------------------
Implemented your remark and attached.

----------------------------------------------------------------------
 VictorBoctor - 07-17-04 23:18=20
----------------------------------------------------------------------
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.

Issue History
Date Modified  Username       Field                    Change

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
06-24-04 01:18 masc           Nuova anomalia

06-24-04 02:10 vboctor        Nota aggiunta: 0005787

06-24-04 02:12 vboctor        Anomalia monitorata: prescience


06-24-04 02:12 vboctor        Nota aggiunta: 0005788

06-24-04 05:10 masc           Nota aggiunta: 0005789

06-24-04 08:29 vboctor        Nota aggiunta: 0005790

06-24-04 09:16 jferraz        Anomalia monitorata: jferraz

06-24-04 09:32 masc           Nota aggiunta: 0005791

06-24-04 12:50 thraxisp       Nota aggiunta: 0005793

06-24-04 17:17 MitchC         Nota aggiunta: 0005798

06-26-04 15:26 masc           Nota aggiunta: 0005802

06-27-04 07:42 grangeway      Relazione aggiunta: anomalia 0001237

    =20
06-28-04 15:45 masc           Anomalia monitorata: vboctor

06-28-04 15:45 masc           Nota aggiunta: 0005807

06-28-04 15:46 masc           Nota modificata: 0005807

06-30-04 12:55 grangeway      Nota aggiunta: 0005843

07-01-04 01:00 masc           Nota aggiunta: 0005857

07-01-04 01:34 vboctor        Nota aggiunta: 0005858

07-01-04 02:13 masc           Nota aggiunta: 0005859

07-01-04 02:14 masc           File allegato : relationship_example.gif

        =20
07-01-04 02:27 vboctor        Nota aggiunta: 0005860

07-01-04 04:52 masc           File allegato : relationship_api.zip

    =20
07-01-04 04:55 masc           Nota aggiunta: 0005861

07-01-04 08:22 vboctor        Nota aggiunta: 0005862

07-01-04 15:16 MitchC         Nota aggiunta: 0005863

07-02-04 02:01 masc           Nota aggiunta: 0005865

07-02-04 02:02 masc           File allegato :
relationship_patch_v.1.0.zip     =20
            =20
07-02-04 09:11 sgrund         Anomalia monitorata: sgrund

07-05-04 14:21 masc           Nota aggiunta: 0005881

07-05-04 14:22 masc           Nota eliminata : 0005881

07-06-04 07:20 kir29          Anomalia monitorata: kir29

07-07-04 20:19 jferraz        Nota aggiunta: 0005898

07-07-04 20:50 vboctor        Nota aggiunta: 0005900

07-08-04 13:54 thraxisp       Nota aggiunta: 0005935

07-08-04 16:42 vboctor        Nota aggiunta: 0005937

07-08-04 18:13 Undergrid      Anomalia monitorata: Undergrid

07-09-04 02:44 masc           Nota aggiunta: 0005950

07-09-04 10:33 vboctor        Nota aggiunta: 0005960

07-09-04 13:58 masc           Nota aggiunta: 0005964

07-11-04 03:11 vboctor        Nota aggiunta: 0005986

07-11-04 08:29 vboctor        Nota aggiunta: 0005989

07-11-04 15:45 jferraz        Nota aggiunta: 0005994

07-11-04 15:46 jferraz        Nota modificata: 0005994

07-12-04 02:07 masc           Nota aggiunta: 0006003

07-12-04 03:53 dcodres        Aggiunta sponsorship     dcodres: US$ 5

07-12-04 03:53 dcodres        Anomalia monitorata: dcodres

07-12-04 03:53 dcodres        sponsorship_total        0 =3D> 5

07-12-04 17:15 virtuetek      Aggiunta sponsorship     virtuetek: US$ 5

07-12-04 17:15 virtuetek      sponsorship_total        5 =3D> 10

07-12-04 17:15 virtuetek      Anomalia monitorata: virtuetek

07-13-04 17:15 vboctor        Assegnato a               =3D> =
VictorBoctor

07-13-04 17:15 vboctor        Stato                    nuovo =3D>
assegnato =20
07-15-04 03:55 masc           File allegato : 0_19_relationship_inc.zip

         =20
07-15-04 03:57 masc           Nota aggiunta: 0006054

07-15-04 05:48 vboctor        Nota aggiunta: 0006056

07-15-04 05:52 vboctor        Nota aggiunta: 0006058

07-15-04 08:47 nuclearspike   Nota aggiunta: 0006061

07-15-04 08:50 nuclearspike   Anomalia monitorata: nuclearspike

 =20
07-15-04 08:52 vboctor        Nota aggiunta: 0006062

07-15-04 09:49 masc           Nota aggiunta: 0006063

07-15-04 09:51 masc           File allegato : 0_18_inc.zip

07-15-04 15:35 goemon1        Anomalia monitorata: goemon1

07-15-04 17:11 vboctor        Nota aggiunta: 0006073

07-16-04 14:37 masc           Nota aggiunta: 0006094

07-16-04 14:39 masc           File allegato : relationship_dupl_id.zip

        =20
07-16-04 18:11 vboctor        Nota aggiunta: 0006097

07-17-04 16:01 masc           Nota aggiunta: 0006103

07-17-04 16:03 masc           File allegato : =
relationship_dupl_id_2.zip

          =20
07-17-04 23:18 vboctor        Nota aggiunta: 0006104

07-17-04 23:18 vboctor        Risolto in versione       =3D> 0.19.0a2

07-17-04 23:18 vboctor        Motivazione              aperto =3D> =
risolto

07-17-04 23:18 vboctor        Stato                    assegnato =3D>
risolto
07-17-04 23:19 vboctor        Riassunto                Relationship -
Patch
available =3D> Issue Relationships Support
07-17-04 23:19 vboctor        version                   =3D> 0.19.0a1

07-18-04 06:57 vboctor        Assegnato a              VictorBoctor =
=3D>
masc
07-18-04 11:31 vboctor        Stato                    risolto =3D> =
chiuso

07-20-04 16:07 masc           Relazione aggiunta: anomalia 0001594

    =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D