| Anonymous | Login | Signup for a new account | 2013-05-18 16:04 EDT | ![]() |
| Main | My View | View Issues | Change Log | Roadmap | Wiki | ManTweet | Repositories |
| View Issue Details [ Jump to Notes ] [ Wiki ] [ Related Changesets ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0011687 | mantisbt | attachments | public | 2010-03-19 18:23 | 2013-04-06 09:23 | ||||
| Reporter | jchoover | ||||||||
| Assigned To | dregad | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | 1.2.0 | ||||||||
| Target Version | 1.2.12 | Fixed in Version | 1.2.12 | ||||||
| Summary | 0011687: Bugs with attachments that are moved will lose attachments | ||||||||
| Description | 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. | ||||||||
| Steps To Reproduce | Configure 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 Information | The 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' ); | ||||||||
| Tags | 2.0.x check, patch | ||||||||
| Attached Files | |||||||||
Relationships |
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
Notes |
|
|
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. |
|
atrol (developer) 2010-03-31 03:27 |
Reproduced in a clean installation |
|
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.) |
|
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 ); |
|
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. |
|
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! |
|
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? |
|
atrol (developer) 2010-04-04 12:06 |
some information about contributing patches http://docs.mantisbt.org/master/en/developers.html#DEV.CONTRIB [^] |
|
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. |
|
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. |
|
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? |
|
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? |
|
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. |
|
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! |
|
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? |
|
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. |
|
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 :) |
|
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 );
}
}
}
|
|
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(); |
|
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) |
|
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 |
|
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.х? |
|
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. |
|
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. |
|
Libra (reporter) 2011-08-05 11:32 |
atrol and jchoover, thanks for your support! For jchoover - please provide patched files, thanks in advance! |
|
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. |
|
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 |
|
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. |
|
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 |
|
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. |
|
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 |
|
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. |
|
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. |
|
dregad (developer) 2012-06-25 12:28 |
Sorry about that. To apply the patch, assuming you're on linux, the following should do the trickcd /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 [^] |
|
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. |
|
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) |
|
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. |
|
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 =?. |
|
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() . "
|
|
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. |
|
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 |
|
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! |
|
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. |
|
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 [^] |
|
dregad (developer) 2012-06-28 08:34 |
Thanks for checking Roland, I'll fix that shortly |
|
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 :) |
|
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 |