MantisBT

View Issue Details Jump to Notes ] Wiki ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011687mantisbtattachmentspublic2010-03-19 18:232013-04-06 09:23
Reporterjchoover 
Assigned Todregad 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.2.0 
Target Version1.2.12Fixed in Version1.2.12 
Summary0011687: Bugs with attachments that are moved will lose attachments
DescriptionWhen a bug is logged and assigned to a project which has a project path assigned, and later a mantis "administrator" moves the bug from the initial project to a new project, the attachments are lost.
Steps To ReproduceConfigure an instance of Mantis 1.2.0 with 2+ projects, each having a custom data folder for uploads.

Log an issue in one project, attach a file, and then move the attachment to another project.

The bug page reports the attachment as missing.
Additional InformationThe file is never moved on disk, so it is still sitting in the initial project folder.

From my crash course on Mantis debugging I came up with:

<Moves the bug, but not the attachments on disk.>
bug_actiongroup.php
        case 'MOVE':
            if ( access_has_bug_level( config_get( 'move_bug_threshold' ), $t_bug_id ) ) {
                /** @todo we need to issue a helper_call_custom_function( 'issue_update_validate', array( $t_bug_id, $t_bug_data, $f_bugnote_text ) ); */
                $f_project_id = gpc_get_int( 'project_id' );
<Line 104>: bug_set_field( $t_bug_id, 'project_id', $f_project_id );
                helper_call_custom_function( 'issue_update_notify', array( $t_bug_id ) );
            } else {
                $t_failed_ids[$t_bug_id] = lang_get( 'bug_actiongroup_access' );
            }
            break;

<returns the list of visible attachments>
fileapi.php

function file_get_visible_attachments( $p_bug_id ) {
...
<Line 280> $t_diskfile = file_normalize_attachment_path( $t_row['diskfile'], bug_get_field( $p_bug_id, 'project_id' ) );


function file_normalize_attachment_path( $p_diskfile, $p_project_id ) {
...
<Line 204> $t_path = project_get_field( $p_project_id, 'file_path' );
Tags2.0.x check, patch
Attached Filestxt file icon file_api.mod.txt [^] (3,138 bytes) 2010-04-03 22:57 [Show Content]
patch file icon 0001-Mantis-11687-Disk-based-attachments-get-lost-when-a-.patch [^] (4,851 bytes) 2010-04-04 12:47 [Show Content]
patch file icon 0001-Fix-11687-Bugs-with-attachments-(1.2.1).patch [^] (4,559 bytes) 2010-05-04 00:46 [Show Content]
? file icon bug_move.php [^] (3,067 bytes) 2011-02-04 03:43 [Show Content]
? file icon orphans.php [^] (4,075 bytes) 2011-04-12 20:29 [Show Content]
patch file icon 0001-Patch-for-11687-off-of-the-1.2.4-tag-including-the-m.patch [^] (10,503 bytes) 2011-04-12 21:05 [Show Content]
tgz file icon fixforattachements.tgz [^] (9,966 bytes) 2011-08-05 13:34
zip file icon Patch-for-11687-1.2.6.zip [^] (25,653 bytes) 2011-08-12 06:31
patch file icon fix-11687-1.2.9.patch [^] (3,793 bytes) 2012-06-26 07:21 [Show Content]

- Relationships
related to 0015721new Functionality to consider porting to master-2.0.x 
has duplicate 0012188closedatrol attachments marked as missing in "view issue" after moving issue from one project to another with different upload file path 
has duplicate 0012310closedatrol Attachements are missing when a issue is moved from a domain to anotherone. 
has duplicate 0014355closedatrol When moving an issue to another project, attachments where missing/not moved 
related to 0014796closedatrol "Attachment missing" while re-copying an issue. 

-  Notes
User avatar (0024825)
jchoover (reporter)
2010-03-19 18:26

My suggestion would be either to
A) When the bug is reassigned from one project to another, move the disk files as well.
B) I don't have the DB schema handy, but one could also do a secondary query or modify file_get_visible_attachments to utilize the "other" field in the DB which gives the absolute path to the file, in addition to the file name.

I would prefer A just so we could maintain "pure" directory tree's.
User avatar (0024943)
atrol (developer)
2010-03-31 03:27

Reproduced in a clean installation
User avatar (0024986)
jchoover (reporter)
2010-03-31 10:07

I've been looking for documentation on what the intent was, but I am not seeing much of anything.

Would you agree that it would make the most sense to move disk based attachments of a bug when the bug is moved between projects?

Also, I have yet to get my test VM fully setup, but there was an additional field in the DB storing the absolute path to the folder which contains the attachment. Since it didn't seem like this value was used, is this information only for debugging or is it leftovers from a previous version? (If we do end up moving the files, this path should also be updated.)
User avatar (0025013)
jchoover (reporter)
2010-04-03 23:01
edited on: 2010-04-03 23:02

I've attached a potential fix to the issue. Adding the 2 functions in the text file to file_api.php, and then tweaking bug_actiongroup.php to

A) require file_api.php
B) wrap the line
bug_set_field( $t_bug_id, 'project_id', $f_project_id );

with

$t_origional_bug_project = bug_get_field( $t_bug_id, 'project_id' );
bug_set_field( $t_bug_id, 'project_id', $f_project_id );
file_move_bug_attachments( $t_bug_id, $t_origional_bug_project, $f_project_id );

User avatar (0025014)
jchoover (reporter)
2010-04-03 23:03

I'm close on the proper formatting and notation, but I wouldn't doubt it if I mucked something up. If one of the existing developers would like to take a look at it and let me know how far off base I am, I'd be up for the comments and critiques.
User avatar (0025015)
dhx (developer)
2010-04-04 05:47

Thanks for your help jchoover!

Just some comments on your patch:

No need to check against true (== true)... just leave out the right hand side off those boolean comparisons.

I'm not convinced about the need for file_move_bug_attachment() - I think it may be best to just have a single file_move_bug_attachments() function that works with one, ten or more attachments at a time.

The SQL query would be better located outside the for loop so that we only need one query for multiple files instead of one query for each file.

The approach to moving files with hard links seems a little odd to me. Is there any reason this can't be simplified with a platform-independent call to the PHP rename() function? I understand that rename() will overwrite an existing destination file... is this a situation we have to consider?

With a few minor adjustments, are you able to resubmit a patch as outputted from git format-patch? In this form we can commit it directly with credit going to yourself (if you don't want credit, that is fine too).

I'm impressed with what you've been able to code here... it follows the MantisBT coding conventions and uses the inbuilt functions correctly. Well done!
User avatar (0025019)
jchoover (reporter)
2010-04-04 11:57

My only reasoning around file_move_bug_attachment() was to wrap the file system operations and be entirely certain that the moves are happening properly.

The hard links approach was just something that felt cleaner at the time. (Ensuring I could create the file and set the perms before removing the old one.) Hind sight tells me I was probably over thinking the situation, but I did see reports where Windows machines that rename didn't always work as expected (which was the reason for the inner copy).

As far as destination file check, I do ensure the destination file exists before trying the rename and I trigger an error if one all ready exists. This is partially why I wanted the SQL update inside the loop, though the initialization of the SQL statement could happen outside the loop and just leave the execution call in the loop.

I was trying to cover for a fringe case where a bug with 10 attachments is moved, and the first 5 succeed but the 6th fails due to a duplicate destination name. At first, I had thought we could generate a new hashed file name and update the database accordingly but looking at how the current file names were generated made me wonder if you were embedding some sort of logic inside the name.

I did download/build/install git, but I have never used the tool before so it may take a bit of futzing to get to a state where I can use it effectively. As well, if I am submitting a git patch, which branch should the patch be targeted for?
User avatar (0025020)
atrol (developer)
2010-04-04 12:06

some information about contributing patches
http://docs.mantisbt.org/master/en/developers.html#DEV.CONTRIB [^]
User avatar (0025021)
jchoover (reporter)
2010-04-04 12:12

One other thing that was of concern is the fact that my solution doesn't make a single atomic transaction, so the existing bug's project is updated first and then I was moving any disk based attachments. If any part of the moves fail, the bug is left in a partially moved state.
  I can't think of a way to wrap the code to ensure that every possible fault can be safely handled. I also ponder writing a cleanup script which could be run against an existing DB to move all attachments that are orphaned back to their proper location. (I could see a query joining the attachment table with the bug and project table, filtering on the attachments where the folder field != project upload folder.
  This logic could also be extended to allow for mass updating if someone were to change the upload folder on a project with existing attachments.
User avatar (0025022)
jchoover (reporter)
2010-04-04 12:50

Let's see if that patch file is even remotely correct. Note, I created this based off of the previous suggestions but didn't fire up my Linux VM to test. As such, I am using TortiseGit instead of the command line tools. I'm now going to fire up the linux box and attempt to apply the patch I created in windows land to the 1.2.0 base and see what happens.
User avatar (0025330)
jchoover (reporter)
2010-04-28 10:17

I have tested my patch locally and everything appears to function. Has any other developer looked at this, and what are the odds of getting this merged into the current development branch?

Has anyone else who is experiencing this issue tried my patch?
User avatar (0025383)
nickw (reporter)
2010-05-03 17:28

Our recently installed version (1.2.1) has this problem, but it appears this patch has been written against the changes made in January, so that it uses versions of bug_actiongroup.php that refers to require_api rather than require_once?

As a relative neophyte, how might I use this logic to patch the existing 1.2.1?

Or am I missing something more basic?
User avatar (0025384)
jchoover (reporter)
2010-05-04 00:54

I did a quick scan and saw that they had cleaned up the require_api calls. Noting the require call they changed it to will include the file_api I was patching in, so that part can be ignored.

I did a fast hack and regenerated a 1.2.1 patch by simply replaying my changes (after checking out the 1.2.1 tag). *Note* I didn't have time to test it, but odds are it should function as expected.

As far as how to apply the patch, these are generated by git and are easily applied by git. If you don't want to get git, checkout, and then patch you could manually apply the changes in a test environment.

Note, I didn't change any existing lines, but rather added 2 lines in bug_actiongroup and 79 in file_api.
User avatar (0025397)
nickw (reporter)
2010-05-04 16:44

I was pretty sure that was the case (file_api being already included) but still was having some troubles with it. I've got it going good, but had to make a more explicit reference to the table. Line 42 of your latest patch file has:

$t_bug_file_table = db_get_table( 'bug_file' );

I had to make that:

$t_bug_file_table = db_get_table( 'mantis_bug_file_table' );

Not sure if that is significant to others, but I saw other places in file_api where it was referred to that way, so have (at least in the short term) made the change with no apparent bad results for me anyway.

Thank you so very much for your work on this - I had told our developers that moving the attachments out of the database should not impact badly on them - so to get this fixed has been a real priority for me these last few days!
User avatar (0027530)
jchoover (reporter)
2010-12-01 12:24

I talked to DHX some and it was stated that this fix was in queue, but I see the target has been changed from 1.2.3 to 1.2.x. Do we have an expected target?
User avatar (0028156)
cas (reporter)
2011-02-04 03:45

Found my solution on this issue wheer i just added a function to bug_api called bug_move. This function could be simply called directly with 2 parameters.
Approach on files was to copy first and delete once done.
User avatar (0028301)
dhx (developer)
2011-02-26 05:07

Apologies for the delay in committing this fix. Thank you Jacob for the patch.

I have updated the patch to work with the latest version of MantisBT 1.3.x and have also simplified and cleaned up the new function. Note the use of "guard conditions" on the function instead of massively nested if clauses.

I have not properly tested this updated commit and would appreciate it if some people are able to test this and confirm whether things are working as expected.

Thanks again for your help :)
User avatar (0028607)
jchoover (reporter)
2011-04-12 13:19

Not sure if this is the proper procedure or not, but I had a comment on the commit.

Specifically, if there are "disconnected" attachements in an existing instance would we not want to make this code safe to be able to fix them by moving the bug to it's origional project and back again?

If so, I think it would be a simple change to the file_api fix. I simply added if ( file_exists($t_disk_file_name_from) ) inside the loop that moves the files. Comments?


function file_move_bug_attachments( $p_bug_id, $p_project_id_to ) {
...
        for ( $i = 0; $i < $t_attachments_count; $i++ ) {
                $t_row = $t_attachment_rows[$i];
                $t_basename = basename( $t_row['diskfile'] );

                $t_disk_file_name_from = file_path_combine( $t_path_from, $t_basename );
                $t_disk_file_name_to = file_path_combine( $t_path_to, $t_basename );

                if ( file_exists($t_disk_file_name_from) )
                {
                        if ( !file_exists( $t_disk_file_name_to ) ) {
                                chmod( $t_disk_file_name_from, 0775 );
                                if ( !rename( $t_disk_file_name_from, $t_disk_file_name_to ) ) {
                                        if ( !copy( $t_disk_file_name_from, $t_disk_file_name_to ) ) 
{
                                                trigger_error( FILE_MOVE_FAILED, ERROR );
                                        }
                                        file_delete_local( $t_disk_file_name_from );
                                }
                                chmod( $t_disk_file_name_to, config_get( 'attachments_file_permissions' 
) );
                                db_query_bound( $query_disk_attachment_update, Array( db_prepare_string( 
$t_path_to ), $c_bug_id, db_prepare_int( $t_row['id'] ) ) );
                        } else {
                                trigger_error( ERROR_FILE_DUPLICATE, ERROR );
                        }
                }
        }

User avatar (0028608)
jchoover (reporter)
2011-04-12 20:31

Also, for those wondering how to find borked attachments I have attached my hackish orphans.php. I wrote it against 1.2.4, and I hacked it by adding it to the end of my_view_page.php, via adding require_once( 'orphans.php'); right before html_page_bottom();
User avatar (0029367)
Libra (reporter)
2011-08-05 05:39

This bug will be "officially" resolved in the 1.2.х branch? I have not found any information in the changelog of 1.2.5 and 1.2.6 (now we use 1.2.4)
User avatar (0029368)
atrol (developer)
2011-08-05 06:34

Libra, atm the issue has set "Target Version" to 1.3.x and also "Fixed in Version" to 1.3.x
So you can't find information in changelog of any 1.2.x version
User avatar (0029369)
Libra (reporter)
2011-08-05 08:38
edited on: 2011-08-05 08:39

I understand as for version 1.3.x, but there is a bug in 1.2.4 and this bug is very serious hindrance to the work (we have about 20 projects) and we do not want to install 1.3.х version on a production server. Is it possible to fix this problem in 1.2.х?

User avatar (0029370)
atrol (developer)
2011-08-05 10:55

You can apply the patch for 1.2.4 that jchoover attached to this issue.
Read also what David Hicks wrote as a comment to the changeset.
User avatar (0029371)
jchoover (reporter)
2011-08-05 11:12

If you would prefer the raw files over a patch, let me know and I can provide the patched file_api.php and bug_actiongroup.php that we use on our production instance.

My comment (http://www.mantisbt.org/bugs/view.php?id=11687#c28607 [^]) was in regards to trying to make this safe to fix broken attachments. If you aren't in a broken state it would make more sense to use dhx's commit rather than my tweaks. My files were changed to allow for our project managers to be able to "fix" borked attachments by pushing them back to the original project(s) and then back to where they should be. The process of moving them around should find the missing files, assuming you haven't changed the storage location of the projects.
User avatar (0029372)
Libra (reporter)
2011-08-05 11:32

atrol and jchoover, thanks for your support! For jchoover - please provide patched files, thanks in advance!
User avatar (0029373)
jchoover (reporter)
2011-08-05 13:37

The fixforattachements.tgz is based off of the 1.2.4 code base with the fix implemented in it. As always, make sure you have a backup of the files and data before applying the fix. I would also store a backup copy of the 2 files in case you needed to revert the changes.
User avatar (0029468)
Libra (reporter)
2011-08-12 06:25

jchoover, thanks for patсh - everything works as expected! I upgraded to 1.2.6 and created a patch for it (a bit different from 1.2.4), see Patch-for-11687-1.2.6.zip
User avatar (0029791)
jthomas (reporter)
2011-09-18 12:02

I recently upgraded from 1.1.x to 1.2.8 and I see that 'Patch-for-11687-1.2.6.zip' is meant to work for 1.2.6. Can you tell me if it also work for 1.2.8? Thanks in advance.
User avatar (0029797)
Libra (reporter)
2011-09-18 15:22

Unfortunately, can not say anything about version 1.2.8, has not been updated since version 1.2.6
User avatar (0029799)
jthomas (reporter)
2011-09-18 15:37

Thanks for the update. I'll keep checking here to see if someone patches 1.2.8, otherwise will update to 1.3.x when available/stable.
User avatar (0031390)
jthomas (reporter)
2012-03-06 15:42

Can anybody confirm that this issues has been fixed in 1.2.9? I'd rather just go from 1.2.8 to 1.2.9 instead of waiting for 1.3.X since this issue still exists for us.

Thanks,
Jay
User avatar (0032099)
dregad (developer)
2012-06-14 05:39

It is not fixed in 1.2.9. However, I just checked and dhx's commit for 1.3.x applies cleanly on 1.2.x branch, so it would be easy to back-port it.

I uploaded a patch file (fix-11687.patch), which should apply fine on release 1.2.9 and above. If you can spare the time to test and confirm that everything works as it should, I can push the changes to the 1.2.x.
User avatar (0032175)
jthomas (reporter)
2012-06-25 11:52

Thanks dregad, you're giving me more credit than I've earned. I have no idea how to apply that patch so I googled some possibilities but ended up just messing up a couple of my files on my test box. The original is working again, but I'll have to spend some more time figuring this out. If there's something you can point me to, to read up on, I'd be happy to learn what I need to otherwise, I'll keep plugging away as time permits.

Thanks for the attempt at helping out.
User avatar (0032176)
dregad (developer)
2012-06-25 12:28

Sorry about that. To apply the patch, assuming you're on linux, the following should do the trick

cd /path/to/mantisbt
patch -p1 -i /path/to/fix-11687.patch


On windows, if you have cygwin the commands above should work too. Otherwise you need to use some utility, e.g. see http://stackoverflow.com/questions/517257/how-do-i-apply-a-diff-patch-on-windows [^]
User avatar (0032177)
jthomas (reporter)
2012-06-25 13:05

Thanks for that, I am on linux (Ubuntu). I hadn't yet upgraded to 1.2.9 so I'm still on 1.2.8 and tried the patch and got an error...

-----------------
patching file core/bug_api.php
Hunk 0000001 succeeded at 1044 (offset -31 lines).
patching file core/file_api.php
Hunk 0000001 FAILED at 908.
1 out of 1 hunk FAILED -- saving rejects to file core/file_api.php.rej
-----------------

I have no problem upgrading to 1.2.9 to test the patch if you think that's the issue. I thought it'd also work on 1.2.8 by my interpretation of you previous note.
User avatar (0032178)
dregad (developer)
2012-06-25 13:22

> I thought it'd also work on 1.2.8 by my interpretation of you previous note.

Wrong interpretation ;-) - read again:
> patch file [...] should apply fine on release 1.2.9 and above

So you should either upgrade your test env, or try and figure out what the conflict is with 1.2.8 (no time to check myself, sorry)
User avatar (0032179)
jthomas (reporter)
2012-06-25 13:41

Gotcha, no worries, I appreciate the help. I don't think I can get to this today, but I'll try the upgrade route and try the patch with that version.
User avatar (0032180)
jthomas (reporter)
2012-06-25 15:49

I upgraded to 1.2.9 and installed the patch. I think that part went well, here's what it spit out...

-------------------------------
patching file core/bug_api.php
Hunk 0000001 succeeded at 1058 (offset -17 lines).
patching file core/file_api.php
-------------------------------

But when I went to move a ticket with an attached file, it gave me this...
-------------------------------
APPLICATION ERROR 0000401

Database query failed. Error received from database was 0001064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SET folder='/var/www/mantis/files/facilities/'
' at line 2 for the query: UPDATE
SET folder=?
WHERE bug_id=?
AND id =?.
User avatar (0032185)
dregad (developer)
2012-06-26 07:19

I overlooked the fact that in 1.3 branch, the referencing of DB tables in the code is not the same as for 1.2 - this is probably what is causing the error you get (although I was not able to reproduce it).

I'm uploading a new patch (which should be applied on top of unmodified 1.2.9) - alternatively you can manually edit core/file_api.php as follows (your line numbers could be different)
diff --git a/core/file_api.php b/core/file_api.php
index 5963507..10fd088 100644
--- a/core/file_api.php
+++ b/core/file_api.php
@@ -947,7 +947,7 @@ function file_move_bug_attachments( $p_bug_id, $p_project_id_to ) {
    }
 
    # Initialize the update query to update a single row
-   $t_bug_file_table = db_get_table( 'bug_file' );
+   $t_bug_file_table = db_get_table( 'mantis_bug_file_table' );
    $c_bug_id = db_prepare_int( $p_bug_id );
    $query_disk_attachment_update = "UPDATE $t_bug_file_table
                                     SET folder=" . db_param() . "
User avatar (0032188)
jthomas (reporter)
2012-06-26 18:46

Thanks, give me a day or two and I'll try this again with a unmodified install of 1.2.9 since I'll be using the patch to update my live site.
User avatar (0032190)
dregad (developer)
2012-06-27 04:12

OK. Looking forward to your feedback.

As a side note, if you're going to upgrade your production site, I would advise you to go for 1.2.11 instead of 1.2.9 (the provided patch applies cleanly on top of that too) to benefit from several security and bug fixes
User avatar (0032203)
jthomas (reporter)
2012-06-27 16:14

I didn't realize 1.2.11 was out, so thanks for the info.

I upgraded from 1.2.8 to 1.2.11, applied the patch and I'm able to transfer attachments along with the tickets now. It works like a champ, thanks!
User avatar (0032204)
dregad (developer)
2012-06-27 19:35

Thanks to jthomas' testing efforts, the patch has now been ported to 1.2.x branch so I'm marking this as resolved.
User avatar (0032211)
atrol (developer)
2012-06-28 05:48

FILE_MOVE_FAILED is not defined, should be ERROR_FILE_MOVE_FAILED
https://github.com/mantisbt/mantisbt/commit/cdf383bd6cc58534d897a3783dbb345e3cf5ed00#L1R970 [^]
User avatar (0032213)
dregad (developer)
2012-06-28 08:34

Thanks for checking Roland, I'll fix that shortly
User avatar (0032814)
AdamR (reporter)
2012-09-08 20:04

Thanks for the patch, worked perfectly on a long-time running 1.2.10.

I'm going to write a script shortly that will find all missing attachments, look within the Mantis installation folder for them, and if found move them to the correct folder for the project. Once it's done I'll share :)
User avatar (0036214)
grangeway (developer)
2013-04-05 17:56

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

- Related Changesets
MantisBT: master 08c027af
Timestamp: 2011-02-26 10:03:12
Author: Jacob Hoover
Committer: dhx
Details ] Diff ]
Fix 0011687: Bugs with attachments that are moved will lose attachments

When a bug is logged and assigned to a project which has a project path
assigned, and later a mantis "administrator" moves the bug from the
initial project to a new project, the attachments are lost.

Jacob's initial patch from mid 2010 has been updated to work with the
latest version of MantisBT 1.3.x. Furthermore the patch has been cleaned
up and simplified. Needs testing however!

Signed-off-by: David Hicks <hickseydr@optusnet.com.au>
mod - core/bug_api.php Diff ] File ]
mod - core/file_api.php Diff ] File ]
MantisBT: master-1.2.x cdf383bd
Timestamp: 2012-06-27 16:22:15
Author: jchoover
Details ] Diff ]
Fix 0011687: Bugs with attachments that are moved will lose attachments

Backporting 08c027af59b88a6934377d71d19a86edfd7d12dd to 1.2.x branch.

When a bug is logged and assigned to a project which has a project path
assigned, and later a mantis "administrator" moves the bug from the
initial project to a new project, the attachments are lost.

Signed-off-by: Damien Regad <damien.regad@merckgroup.com>
mod - core/bug_api.php Diff ] File ]
mod - core/file_api.php Diff ] File ]
MantisBT: master-1.2.x 4a6c8456
Timestamp: 2012-06-28 05:35:01
Author: dregad
Details ] Diff ]
Fix 0011687: use of incorrect error constant
mod - core/file_api.php Diff ] File ]
MantisBT: master 21e1a24b
Timestamp: 2012-06-28 05:35:01
Author: dregad
Details ] Diff ]
Fix 0011687: use of incorrect error constant
mod - core/file_api.php Diff ] File ]

- Issue History
Date Modified Username Field Change
2010-03-19 18:23 jchoover New Issue
2010-03-19 18:26 jchoover Note Added: 0024825
2010-03-31 03:27 atrol Note Added: 0024943
2010-03-31 03:27 atrol Status new => confirmed
2010-03-31 10:07 jchoover Note Added: 0024986
2010-04-03 22:57 jchoover File Added: file_api.mod.txt
2010-04-03 23:01 jchoover Note Added: 0025013
2010-04-03 23:02 jchoover Note Edited: 0025013 View Revisions
2010-04-03 23:03 jchoover Note Added: 0025014
2010-04-04 05:47 dhx Note Added: 0025015
2010-04-04 05:47 dhx Tag Attached: patch
2010-04-04 05:48 dhx Severity minor => major
2010-04-04 05:48 dhx Target Version => 1.2.2
2010-04-04 05:48 dhx Summary Bugs with attachments that are moved will loose attachments => Bugs with attachments that are moved will lose attachments
2010-04-04 11:57 jchoover Note Added: 0025019
2010-04-04 12:06 atrol Note Added: 0025020
2010-04-04 12:12 jchoover Note Added: 0025021
2010-04-04 12:47 jchoover File Added: 0001-Mantis-11687-Disk-based-attachments-get-lost-when-a-.patch
2010-04-04 12:50 jchoover Note Added: 0025022
2010-04-05 01:49 dhx Assigned To => dhx
2010-04-05 01:49 dhx Status confirmed => assigned
2010-04-21 09:14 jreese Target Version 1.2.1 => 1.2.2
2010-04-28 10:17 jchoover Note Added: 0025330
2010-05-03 17:28 nickw Note Added: 0025383
2010-05-04 00:46 jchoover File Added: 0001-Fix-11687-Bugs-with-attachments-(1.2.1).patch
2010-05-04 00:54 jchoover Note Added: 0025384
2010-05-04 16:44 nickw Note Added: 0025397
2010-07-22 08:48 atrol Relationship added has duplicate 0012188
2010-07-29 10:41 jreese Target Version 1.2.2 => 1.2.3
2010-08-30 06:32 atrol Relationship added has duplicate 0012310
2010-09-14 10:55 jreese Target Version 1.2.3 => 1.2.4
2010-12-01 12:24 jchoover Note Added: 0027530
2010-12-14 21:05 jreese Target Version 1.2.4 => 1.2.5
2011-02-04 03:43 cas File Added: bug_move.php
2011-02-04 03:45 cas Note Added: 0028156
2011-02-26 05:05 dhx Changeset attached => MantisBT master 08c027af
2011-02-26 05:05 dhx Resolution open => fixed
2011-02-26 05:05 dhx Fixed in Version => 1.3.x
2011-02-26 05:07 dhx Note Added: 0028301
2011-02-26 05:07 dhx Status assigned => resolved
2011-02-26 05:07 dhx Target Version 1.2.5 => 1.3.x
2011-04-12 13:19 jchoover Note Added: 0028607
2011-04-12 13:19 jchoover Status resolved => feedback
2011-04-12 13:19 jchoover Resolution fixed => reopened
2011-04-12 20:29 jchoover File Added: orphans.php
2011-04-12 20:31 jchoover Note Added: 0028608
2011-04-12 20:31 jchoover Status feedback => assigned
2011-04-12 21:05 jchoover File Added: 0001-Patch-for-11687-off-of-the-1.2.4-tag-including-the-m.patch
2011-08-05 05:39 Libra Note Added: 0029367
2011-08-05 06:34 atrol Note Added: 0029368
2011-08-05 08:38 Libra Note Added: 0029369
2011-08-05 08:39 Libra Note Edited: 0029369 View Revisions
2011-08-05 10:55 atrol Note Added: 0029370
2011-08-05 11:12 jchoover Note Added: 0029371
2011-08-05 11:32 Libra Note Added: 0029372
2011-08-05 13:34 jchoover File Added: fixforattachements.tgz
2011-08-05 13:37 jchoover Note Added: 0029373
2011-08-12 06:25 Libra Note Added: 0029468
2011-08-12 06:31 Libra File Added: Patch-for-11687-1.2.6.zip
2011-09-18 12:02 jthomas Note Added: 0029791
2011-09-18 15:22 Libra Note Added: 0029797
2011-09-18 15:37 jthomas Note Added: 0029799
2012-03-06 15:42 jthomas Note Added: 0031390
2012-06-14 05:39 dregad Note Added: 0032099
2012-06-14 05:40 dregad File Added: fix-11687.patch
2012-06-25 11:52 jthomas Note Added: 0032175
2012-06-25 12:28 dregad Note Added: 0032176
2012-06-25 13:05 jthomas Note Added: 0032177
2012-06-25 13:22 dregad Note Added: 0032178
2012-06-25 13:41 jthomas Note Added: 0032179
2012-06-25 15:49 jthomas Note Added: 0032180
2012-06-26 07:19 dregad Note Added: 0032185
2012-06-26 07:20 dregad File Added: fix-11687-2.patch
2012-06-26 07:20 dregad File Deleted: fix-11687.patch
2012-06-26 07:21 dregad File Added: fix-11687-1.2.9.patch
2012-06-26 07:21 dregad File Deleted: fix-11687-2.patch
2012-06-26 18:46 jthomas Note Added: 0032188
2012-06-27 04:12 dregad Note Added: 0032190
2012-06-27 16:14 jthomas Note Added: 0032203
2012-06-27 19:31 jchoover Changeset attached => MantisBT master-1.2.x cdf383bd
2012-06-27 19:31 jchoover Assigned To dhx => jchoover
2012-06-27 19:31 jchoover Status assigned => resolved
2012-06-27 19:35 dregad Note Added: 0032204
2012-06-27 19:35 dregad Assigned To jchoover => dregad
2012-06-27 19:35 dregad Resolution reopened => fixed
2012-06-27 19:35 dregad Fixed in Version 1.3.x => 1.2.12
2012-06-27 19:35 dregad Target Version 1.3.x => 1.2.12
2012-06-28 05:48 atrol Note Added: 0032211
2012-06-28 08:34 dregad Note Added: 0032213
2012-06-28 08:34 dregad Status resolved => feedback
2012-06-28 08:34 dregad Resolution fixed => reopened
2012-06-28 08:42 dregad Changeset attached => MantisBT master-1.2.x 4a6c8456
2012-06-28 08:42 dregad Status feedback => resolved
2012-06-28 08:43 dregad Changeset attached => MantisBT master 21e1a24b
2012-06-28 08:43 dregad Resolution reopened => fixed
2012-07-10 15:55 atrol Relationship added has duplicate 0014355
2012-09-08 20:04 AdamR Note Added: 0032814
2012-10-09 08:19 atrol Relationship added related to 0014796
2012-11-10 18:54 dregad Status resolved => closed
2013-04-05 17:56 grangeway Status closed => acknowledged
2013-04-05 17:56 grangeway Note Added: 0036214
2013-04-05 19:00 grangeway Relationship added related to 0015721
2013-04-06 03:40 dregad Status acknowledged => closed
2013-04-06 07:23 grangeway Status closed => acknowledged
2013-04-06 09:22 dregad Tag Attached: 2.0.x check
2013-04-06 09:23 dregad Status acknowledged => closed


MantisBT 1.2.16dev master-1.2.x-8c2bd07 [^]
Copyright © 2000 - 2013 MantisBT Team
Time: 0.2867 seconds.
memory usage: 3,276 KB
Powered by Mantis Bugtracker