From my test it seems that when sending an document (I tested in writer) as an email attachment, and when this document has unsaved changes (small red dot in the save icon), then the actual version is sent anyway, and not the saved version. I think it would be more clear if, in the case of unsaved changes and upon sending the document, the user would get a warning, and be given the choice of saving the file, or sending the file with the unsaved changes (or aborting). thanks for considering this improvement (if you consider it an improvement ;-)
Cannot confirm. Sent saved "Untitles 1.odt" to myself, added text to this document, and sent it again without saving, and finally received two different documents. How exactly is your setup?
I did perhaps not explain well, but I observe the exact same thing as you do. I have suggested a warning, as a user might think that when he has unsaved changes, and he sends the file by email, that then the older version is sent, the one which had last been saved and which does not include the latest changes. But what will be sent is the version shown in the screen, and which is including the latest changes. So if a warning would be displayed, then at least the user would know that the version he is sending is not the version which is on the disk, in the folder where the file is classed.
If I send an unsaved document me expects to get a warning. The other way around would be even more strange. So as an alternative we could request to save first.
yes, I agree, a warning when an unsaved document is sent. And a proposition in the warning window to save first.
I support the request with a prompt for saving the file first before it will be sent. Best way would be a message where the user can choose between save + send on the one side and cancel on the other side). I find it disruptive if the user is only warned that the file can't be saved until the user has saved the file in an extra step, then the user has to click ok in the warning message, then must save the file manually and then must start the sending process again. This is bad.
We discussed the topic at the design meeting and recommend to do what Thomas suggested in comment 5.
I agree with thomas comment 5 Has there been any way forward with this problem ? It seemed to me from Heiko's comment 6 that there was already an official way forward, however the bug is still classed as "NEW"