SiT! Bugs

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001351SiT!incidentspublic2010-06-24 15:472010-06-25 07:27
Reporternicdev 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version3.60 LTS 
Target VersionFixed in Version 
Summary0001351: Moving an update from the holding queue, to an existing incident (without an attachment folder) fails
DescriptionWhen "assigning" an update in the holding queue, to an exisiting incident (where the exisiting incident does not have a /AttachmenFolder/Incidentnumber/ folder), the move of the attachment fails. The reason is that move_update.php does not create the folder as it assumes it is already there.
At this point we do:
if (!file_exists($old_path))
            {
                $umask=umask(0000);
                @mkdir($CONFIG['attachment_fspath'] .$incidentid, 0770);
                umask($umask);
            }

What we saying is that if the $old_path (the updates folder) does NOT exist create an incident folder ...

What you should really be saying is "If an incident folder does not exist", create it:


We need to add something like:
if (!file_exists($new_path))
            {
                $umask=umask(0000);
                @mkdir($CONFIG['attachment_fspath'] .$incidentid, 0770);
                umask($umask);
            }
Steps To ReproduceCreat an incident from an update in the holding queue (ensure this update does not have any attachments)
Now take a second update with attachment(s) and "Assign" that to the incidentis of the incident created in the first step.
The assign fails and you are left with a blank screen.

2010-06-24T11:22:13+02:00 /sit/move_update.php Application Warning [512] Couldn't move file: 13128-Xups.mib (in line 196 of file D:\wamp\www\sit\move_update.php)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0003268)
ivan (administrator)
2010-06-24 15:59

ICBW but I thought the original plan was to keep these attachments in the updates/{number} which would mean this doesn't need to happen. I'd need to look into it though my memory is hazy.
User avatar (0003269)
nicdev (developer)
2010-06-25 07:27

Yes this is confusing, as sometimes we move them .. and other times we leave and rename them depending where you are in SiT.

In the case of move_update.php:
$old_path = $CONFIG['attachment_fspath']. 'updates' . $fsdelim;
$new_path = $CONFIG['attachment_fspath'] . $incidentid . $fsdelim;

This means we are moving it to /attachments/{incidentid}/ from /updates/ folder ... I think we should review all the scripts that move attachments and make sure we are doing the same thing all the time...

Personally i thought that we store the updates in /attachments/updates/ just until the update is made into an incident, or until the update is assigned to an existing incident, when it is moved to the /attachments/{incidentid}/ folder .. but frankly IHBW before ;)

- Issue History
Date Modified Username Field Change
2010-06-24 15:47 nicdev New Issue
2010-06-24 15:48 nicdev Summary Moving an update from the holding queue to an existing incident without an attachment folder fails => Moving an update from the holding queue, to an existing incident (without an attachment folder) fails
2010-06-24 15:59 ivan Note Added: 0003268
2010-06-25 07:27 nicdev Note Added: 0003269


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker