Bug 51554 - Data loss risk referencing slides from external impress presentation (Menu Insert -> File, selecting link)
Summary: Data loss risk referencing slides from external impress presentation (Menu In...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, needsDevEval, skillCpp, topicUI
Depends on:
Blocks: Insert-File-Content
  Show dependency treegraph
 
Reported: 2012-06-29 04:33 UTC by Sean Carlos
Modified: 2018-12-13 09:00 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Carlos 2012-06-29 04:33:47 UTC
Impress offers a way to include a slide from a separate odp
presentation, using the menu option "Insert -> File".  Choosing the
"Link" option during the slide importation allows you to update the
included slide should the original slide undergo changes.  Very
nice.

There appears to be a problem with the implementation, however.  There
doesn't seem to be any way to visually know that a slide depends on
(is linked to) an external "master" slide.  So a user could / will
unknowing make changes to a slide and then proceed to overwrite these
changes the next time they open the Impress slide set by accepting the
"update linked slides" prompt.

This likely scenario leads to data loss.

I'd suggest that a visual clue be added to show a slide that is linked to
an external slide (I suspect that implementation cannot be too
difficult).

Ideally, the clue would indicate the file containing the linked slide and updates to a linked slide would propagate back to the external master slide or, probably safer, the linked slide would be read-only.
Comment 1 Michael Meeks 2012-07-13 13:16:06 UTC
AFAIK this is no regression from 3.5 - and is present there too; as such I'll move it to the 3.5 MAB list instead [ eventually they will all be moved to 3.6 as 3.5 closes out it's development history but we like to keep this bug clean as we approach release ].

Thanks !
Comment 2 Michael Meeks 2012-07-13 13:20:17 UTC
At least for me - in the slide-sorter these slides also have a visually distinct blue background - which makes it easier to see them vs.the others. Not sure what happens if you use a blue background but ... ;-)
Comment 3 Sean Carlos 2012-07-13 16:38:12 UTC
(In reply to comment #2)
> At least for me - in the slide-sorter these slides also have a visually
> distinct blue background - which makes it easier to see them vs.the others. Not
> sure what happens if you use a blue background but ... ;-)

That sounds like a really good start... but my linked slides have the same white background color of the originals (using 3.6.0.0.beta3 (Build ID: 3e2b862) on Fedora).  There is a blue border which appears in slide sorter around the currently highlighted slide, but this is independent of the linked status.  If you have any insight as to what might make this highlighting appear, that would be wonderful.

The data loss issue still applies as in Edit mode a normal user is unlikely to remember which slide displayed in the sorter was linked.
Comment 4 Sean Carlos 2012-07-13 16:38:52 UTC
(In reply to comment #1)
> AFAIK this is no regression from 3.5 - and is present there too; as such I'll
> move it to the 3.5 MAB list instead [ eventually they will all be moved to 3.6
> as 3.5 closes out it's development history but we like to keep this bug clean
> as we approach release ].
> 
> Thanks !

Excellent. Thank you for looking at this.
Comment 5 Jorendc 2013-02-07 19:54:00 UTC
Mmh, when I try to reproduce this behavior I get an error when reopening the document.

A message pops up: 
"This document contains one or more links to external data.

Would you like to change the document, and update all links
to get the most recent data?"
-> Yes

result in: 'The file could not be loaded!'

How to reproduce:

* Open Impress
* Insert > File
* Select a presentation
* Check 'Link'
* OK
* Do some changes (delete something that is very obvious)
* Save as ODP
* Reopen

Behavior: message pops up (see above) -> 'The file could not be loaded!'

Tested using Linux Mint 14 x64 with LibreOffice 4.0.0.3 (= release)

@Bug reporter: can you reproduce this using LibreOffice 4.0?

(In reply to comment #1)
 [ eventually they will all be moved
> to 3.6 as 3.5 closes out it's development history but we like to keep this
> bug clean as we approach release ].
We are trying to do that NOW :-)
Comment 6 sepp.mue 2013-04-01 11:42:20 UTC
The import file one seems to behave strange....

When I imported 2 files the second one was highlighted as well blue in the sorter, but I assume thas was due to a another master, but I'm not sure.

And I would like to remove the whole import again! So there shoudl be a kind of unlink option!

Are there any plans to implement this?
Comment 7 Sean Carlos 2013-04-02 13:47:51 UTC
Just to clarify Michael Meeks comment about the blue slide background seen in the sorter for imported slides (not just currently highlighted slide(s): sepp.mue@gmx.de is right, the blue background is due to the use of a different slide master in the imported slides.  It has nothing to do with if a slide is linked or not.
Comment 8 Michael Meeks 2013-08-26 15:16:18 UTC
Currently no plans to implement it no - but if you want to hack on it no doubt we can find some code-pointers to help out. Given the age of this issue, it seems like the request might be covered by being able to undo the update of linked masters [ is that an undo-able operation? ], I'm really not sure it should be on the MAB list.

So removing for now. Ultimately it seems to me no different from various other operations which cannot be undone, which you could think of as loosing data.
Comment 9 QA Administrators 2015-04-01 14:41:42 UTC Comment hidden (obsolete)
Comment 10 tommy27 2016-04-16 07:28:00 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2017-05-22 13:25:30 UTC Comment hidden (obsolete)
Comment 12 eisa01 2018-12-08 10:32:34 UTC
This is still present as described in the original issue. You have no way of seeing a slide is linked to another slide in another file, and any edits you do will be discarded if you update links on the next reopoen.

I don't think this is a bug though, but rather a feature request? So revising the priority

Adding the UX group to make a decision, so revising

Version: 6.3.0.0.alpha0+
Build ID: beae6c7a7f163daad0d4dea63a3d403af2745fd1
CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-12-06_23:52:29
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 13 Heiko Tietze 2018-12-10 16:00:47 UTC
The function is now located at Slide > Insert Slide from File... and the user has to confirm the update on loading. Any change to the linked slide are stored with the current presentation. For example, <1> <Hello World> <2> (with Hello World linked from Untitled2) changed to "Hello New World" will be saved and loaded unless the link is being updated.

So we have two issues, first to know what slide(s) are linked (there is no information at the Navigator) and to support the user on update or not.

Simplest solution is to just not permit changes of linked files. Something like a lock icon at the Navigator and at the status bar along with a message box "You cannot edit this slide directly. Do you want to open the linked file [Yes/No]" would be handy. Alternatively, we need to show some kind of diff as changes could have been made on both presentations. Sounds like a lot of effort.
Comment 14 Cor Nouws 2018-12-12 18:53:07 UTC
(In reply to Heiko Tietze from comment #13)

> So we have two issues
One issue per report pls :p

> first to know what slide(s) are linked (there is no information at the Navigator) and to support the user on update or not.
Looking for similarity with Calc and Writer:
In Calc linked data can be recognized by the cell content.
In Writer linked content is placed in a section.

So yes, a visible recognition is missing.
Would that exist, then the problem is ~solved?

Mind that Edit > Link to External Files is inactive in a presentation where a slide from another one is linked. Looks as (another) bug.
Comment 15 Heiko Tietze 2018-12-13 08:42:06 UTC
(In reply to Heiko Tietze from comment #13)
> Simplest solution is to just not permit changes of linked files. 

We talked about this topic in the design meeting and agreed on this solution. But there should be a chance for the user to override and this could be done per infobar as known from Writer when a document is readonly.

Sounds like an easyhack, though not too simple.