UX Specs: Editing Attachments
Overview
The ability to remove, update or add an attached file while editing a post is a feature that has long been requested. To work around this, users often have to delete the original post and send a new message with the updated attachment or send a follow-up message with the corrected attachment.
In addition, some customers have a short time window where posts can be edited, so the workaround to delete their message with the incorrect attachment is not even possible. When the wrong file is attached, nothing can be done about it.
This can be important when sensitive information needs to be recalled.
Editing a message and its attachments
To edit attachments, users can edit a message as they normally would through the message actions menu.
The edit time limit will still respect the time limit set in the system console:
Advanced permissions - Mattermost documentation
On the edit state, we will show the same controls as are available when creating a post, apart from the send message, which is replaced by a save and cancel button on both Desktop and Mobile. (Except message priority)
If the scope of adding the same options as the initial post box is a lot, then we can potentially consider just adding the attachment options.
Desktop
Mobile
Adding an attachment to a message
While editing a message, new attachments can be added by clicking the paperclip icon button.
This will open the OS dialog to choose a file to upload.
Additionally, users can drag a file in to editable area of the message they’re editing to attach a file.
Drag & Drop
If a post or a thread is being edited, then the black uploader overlay while dragging files will only be applied to the input, rather than the full window.
This allows users to drag it to the specific post they want.
Deleting an attachment from a message
While editing a message, attached files show in the editable area of the message with an x
icon in the top-right corner.
Clicking this will remove the attachment, but it will only be removed if the user clicks on save.
Save and Cancel behaviour on the Editing state
If a user clicks on Cancel or the X mark while on the editing state, the attachments removed or added will return back.
The removed or added attachments will only be preserved when the user clicks on Save.
Editable in Channel, RHS and Threads view contexts
Just as all messages are editable in the channel, RHS and Threads view contexts, attachments will also be editable in these contexts.
Edit history
Attachment changes should be reflected in the message’s edit history RHS view.
For the edited option on the post, we will show what we show today, nothing more.
“Edited June 28 at 12:00PM”, nothing else.
Downloading deleted files is disabled
A deleted file cannot be downloaded from the edit history. When you hover over a file/image on the edited history, the download option is only enabled for files that were not deleted.
Restoring an older version
You can normally restore older versions, but if data retention is turned ON we can show them an alert on the file that will not be brought back if they restore the older version.
This popup is triggered once they click on the restore icon for a message history.
Drag & Drop behaviour
We need to update the drop area visually with a more up to date illustration.
Drag and drop functionality should also exist for adding attachments in the edit state.
If the user drags his mouse anywhere on the center channel (or RHS) if the edit state is open, then dragging on the input, or anywhere on the center channel will drop the file on the edit post box.
Example shown below.
If the edit box is dragged outside the view area (somewhere above), when the user drops the file, the user will be scrolled up to the edit box and see where the file is dropped.
If the user drags a file to the post box explicitly, then the overlay will show on the bottom input box.
If the edit post box is in the center channel, that would not disrupt how the RHS drag/drop experience works right now.
Mobile Edit History
On mobile, we do not have edit history available, so that may be a separate effort to undertake.
Questions
How do we differentiate files that are on a post at the start vs ones that were edited on shortly after? FileInfos are created before a post is made, so they’ll have a different CreateAt than posts
We do not, they are just added after the previous files differently.
How does this work with public file links? Does it need any special handling for those?
Public file links stop working when a file is removed, similar to when a post is deleted with a file.
Can users download older files by going into the file history?
Yes, only download option will be present.