New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attachment lost while modifying ticket #2888

Closed
OcEtEc opened this Issue Jan 28, 2016 · 15 comments

Comments

Projects
None yet
@OcEtEc

OcEtEc commented Jan 28, 2016

Attachment deleted when a ticket response is edited.
The attachment is no longer visible in the ticket detail view after editing,
but the paperclip icon in the ticket overview windows is still available (that means that there is a file attached).
It is also not possible to re-add the attachment in the ticket edit window, there is no attachment field.
When a response is edited there is a new line in the MySQL database for this entry, but the attachment is still assigned to the old response.
I think this information has to be transferred from the old entry to the new line when a thread with an attachment is changed.

Before editing:
ticket-error1

Editing the thread:
ticket-error2

After editing:
ticket-error3

@balojs

This comment has been minimized.

Show comment
Hide comment
@balojs

balojs commented May 19, 2016

+1

@greezybacon

This comment has been minimized.

Show comment
Hide comment
@greezybacon

greezybacon Jun 25, 2016

Member

This is fixed in 907ec36

Member

greezybacon commented Jun 25, 2016

This is fixed in 907ec36

@nobe-vsv

This comment has been minimized.

Show comment
Hide comment
@nobe-vsv

nobe-vsv Apr 5, 2017

Hi,
i´ve faced exactly the same issue at osticket v1.10 stable. The edited tickets lost the attachments and also the edited faq article lost the attachments. I´ve checked the code modification the fix is already included. My System are:
osTicket-Version v1.10 (901e5ea) — Aktuell
Server-Software Apache
MySQL-Version 5.5.52
PHP-Version 5.6.30

could you give me a hint what i have to do? Thanks!

Regards, Norman

nobe-vsv commented Apr 5, 2017

Hi,
i´ve faced exactly the same issue at osticket v1.10 stable. The edited tickets lost the attachments and also the edited faq article lost the attachments. I´ve checked the code modification the fix is already included. My System are:
osTicket-Version v1.10 (901e5ea) — Aktuell
Server-Software Apache
MySQL-Version 5.5.52
PHP-Version 5.6.30

could you give me a hint what i have to do? Thanks!

Regards, Norman

@devi1903

This comment has been minimized.

Show comment
Hide comment
@devi1903

devi1903 May 23, 2017

Hi,
Just to confirm, fault still exists. Same as Norman. Code as per below already includes the modifications. I have noticed as well that the SLA is also removed from the ticket when it is edited.

`// Replace previous edit --------------------------
$original = $old->getParent();
// Link the new entry to the old id
$entry->pid = $old->pid;
// Drop the previous edit, and base this edit off the original
$old->delete();
$old = $original;
}

// Move the attachments to the new entry
$old->attachments->update(array(
'object_id' => $entry->id
));

// Mark the new entry as edited (but not hidden nor guarded)
$entry->flags = ($old->flags & ~(ThreadEntry::FLAG_HIDDEN | ThreadEntry::FLAG_GUARDED))
| ThreadEntry::FLAG_EDITED;

// Guard against deletes on future edit if requested. This is done
// if an email was triggered by the last edit. In such a case, it
// should not be replaced by a subsequent edit.
if ($guard)
$entry->flags |= ThreadEntry::FLAG_GUARDED;
`

devi1903 commented May 23, 2017

Hi,
Just to confirm, fault still exists. Same as Norman. Code as per below already includes the modifications. I have noticed as well that the SLA is also removed from the ticket when it is edited.

`// Replace previous edit --------------------------
$original = $old->getParent();
// Link the new entry to the old id
$entry->pid = $old->pid;
// Drop the previous edit, and base this edit off the original
$old->delete();
$old = $original;
}

// Move the attachments to the new entry
$old->attachments->update(array(
'object_id' => $entry->id
));

// Mark the new entry as edited (but not hidden nor guarded)
$entry->flags = ($old->flags & ~(ThreadEntry::FLAG_HIDDEN | ThreadEntry::FLAG_GUARDED))
| ThreadEntry::FLAG_EDITED;

// Guard against deletes on future edit if requested. This is done
// if an email was triggered by the last edit. In such a case, it
// should not be replaced by a subsequent edit.
if ($guard)
$entry->flags |= ThreadEntry::FLAG_GUARDED;
`

@furetto

This comment has been minimized.

Show comment
Hide comment
@furetto

furetto Jul 13, 2017

any news on this bug?

furetto commented Jul 13, 2017

any news on this bug?

@devi1903

This comment has been minimized.

Show comment
Hide comment
@devi1903

devi1903 Jul 17, 2017

Unfortunately no news, issue still not resolved

devi1903 commented Jul 17, 2017

Unfortunately no news, issue still not resolved

@mtitter

This comment has been minimized.

Show comment
Hide comment
@mtitter

mtitter Nov 16, 2017

Any movement on this issue? Still having this happen to us on v1.10.1

mtitter commented Nov 16, 2017

Any movement on this issue? Still having this happen to us on v1.10.1

@luiizfenix

This comment has been minimized.

Show comment
Hide comment
@luiizfenix

luiizfenix Dec 4, 2017

issue still exist on v1.10.1 currently trying to fix it without success.

Also radio button gets reset even if set to "not editable by agent"

any news from the more experienced here? @ntozier @JediKev @greezybacon

luiizfenix commented Dec 4, 2017

issue still exist on v1.10.1 currently trying to fix it without success.

Also radio button gets reset even if set to "not editable by agent"

any news from the more experienced here? @ntozier @JediKev @greezybacon

@devi1903

This comment has been minimized.

Show comment
Hide comment
@devi1903

devi1903 Dec 4, 2017

I have also noted that date fields add one day each time you edit and save the ticket without you changing the date, its clear that these bugs on edit are quite broad

devi1903 commented Dec 4, 2017

I have also noted that date fields add one day each time you edit and save the ticket without you changing the date, its clear that these bugs on edit are quite broad

@cbiere

This comment has been minimized.

Show comment
Hide comment
@cbiere

cbiere Mar 29, 2018

This bug is NOT fixed. I'm using the Knowledge Base as central point for all documentation. If the attached documents are not safe there, this feature is complete and utter useless. This should be disabled until it is fixed.

cbiere commented Mar 29, 2018

This bug is NOT fixed. I'm using the Knowledge Base as central point for all documentation. If the attached documents are not safe there, this feature is complete and utter useless. This should be disabled until it is fixed.

@alexdjachenko

This comment has been minimized.

Show comment
Hide comment
@alexdjachenko

alexdjachenko Apr 3, 2018

I have the same problem.
Version 10.10.1 + Plugin "Attachments on the filesystem"

alexdjachenko commented Apr 3, 2018

I have the same problem.
Version 10.10.1 + Plugin "Attachments on the filesystem"

@F3000

This comment has been minimized.

Show comment
Hide comment
@F3000

F3000 Apr 3, 2018

I have tested it with 1.10.1

MySQL Version | 5.5.56
PHP Version | 5.4.16
Np plugins

I have edited and dont lost the attachment

F3000 commented Apr 3, 2018

I have tested it with 1.10.1

MySQL Version | 5.5.56
PHP Version | 5.4.16
Np plugins

I have edited and dont lost the attachment

@devi1903

This comment has been minimized.

Show comment
Hide comment
@devi1903

devi1903 Apr 12, 2018

@F3000 i can confirm this bug is not fixed. Unfortunately at this stage this bug is making OSTicket unusable for setups that require file attachments as data is not secure. When reproducing this fault it must be noted that if you edit tickets as the same user this fault does not exist. This only exists when a user creates a ticket and then a different user edits the ticket. When the different user edits the ticket the attachment gets removed. Also note that the SLA gets unset and all date fields go back by a number of days. Only if the user selects these fields themselves or deletes and re-uploads an attachment does it remain in place after the ticket is saved. I would not be surprised if the knowledge base issue is linked to exactly the same bug.

devi1903 commented Apr 12, 2018

@F3000 i can confirm this bug is not fixed. Unfortunately at this stage this bug is making OSTicket unusable for setups that require file attachments as data is not secure. When reproducing this fault it must be noted that if you edit tickets as the same user this fault does not exist. This only exists when a user creates a ticket and then a different user edits the ticket. When the different user edits the ticket the attachment gets removed. Also note that the SLA gets unset and all date fields go back by a number of days. Only if the user selects these fields themselves or deletes and re-uploads an attachment does it remain in place after the ticket is saved. I would not be surprised if the knowledge base issue is linked to exactly the same bug.

@ntozier

This comment has been minimized.

Show comment
Hide comment
@ntozier

ntozier Apr 13, 2018

Contributor

@protich @greezybacon @JediKev
This has been confirmed as still an issue.
Please reopen

Contributor

ntozier commented Apr 13, 2018

@protich @greezybacon @JediKev
This has been confirmed as still an issue.
Please reopen

@rockmanchile

This comment has been minimized.

Show comment
Hide comment
@rockmanchile

rockmanchile Jun 7, 2018

not a good sign from osticket developers...this issue has over a year now with no easy or quick workaround...i think i going back to 1.9 until the next stable version...1.10 is still very buggy...

(over two years actually)

rockmanchile commented Jun 7, 2018

not a good sign from osticket developers...this issue has over a year now with no easy or quick workaround...i think i going back to 1.9 until the next stable version...1.10 is still very buggy...

(over two years actually)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment