Attaching a file throws away unsaved edits



Mozilla Developer Network
File attachments
2 years ago
a year ago


(Reporter: wbamberg, Unassigned)


({in-triage, regression})




2 years ago

1) start editing a document
2) edit, edit, edit. Don't save yet.
3) attach a file: select the file, name it, upload it

Now the edits you made in (2) are gone. You will see the little

"You have a draft from: ..."

...banner at the top, and if you choose "Restore" it will bring them back. But it breaks your flow, is confusing, and if you don't see the banner and make more edits, you're then forced to choose whether to keep the old edits or the new ones.

This is made worse by the fact that "You have a draft..." doesn't tell you which edits would be restored, if you chose to restore. It turns out that there is already a bug for this: bug 961188, but it seems to be dormant :(.
Severity: normal → major
Keywords: in-triage, regression
Good catch, this is an intended change done as part of the attachments refactoring to achieve a few things:

1) get rid of hideous (read: unstable and untested) JavaScript client code for the upload form that was reimplementing form validation code available on the backend in a way that potentially hid errors (Backend form validation is a must since we do mimetype checking with libmagic to make sure we only allow files we care about)

2) finishing the originally intended attachments app design meaning that some housekeeping is needed to be done once an attachment is stored, e.g. creating a relation between the document and the attachment so we know which attachment is used in which document (which wasn't done before the refactor)

Both reasons meant basically being more elaborate in how the attachment form data is handled on the server side to accurately represent the files we have on the filesystem with the data we have in the database, and then redirecting to the document editing URL on success to load the newest state from the database or show a form error page in case of a validation failure and consecutively allowing to fix the form data.

I'm sure this feature could be added by bridging the gap between the Django form validation code and the JavaScript client (e.g. using parsley.js: but that was out of scope of the attachments refactor given its brokenness.
You need to log in before you can comment on or make changes to this bug.