Description: Deletion of an object (a heading etc.) referenced at some point of the document leads to the replacement of the reference fields by the advice "Error: Reference source not found". These messages are of little help to the user: He may overlook them before printing the document; and if he detects them in time, it is hard to find out what the intended target (Writer calls it "source") of the reference was. The user should better be supported in his preference to avoid these errors. Therefore: User is applying a deletion operation to some string. Before LibreOffice executes the deletion, it checks whether the string to be deleted contains one or more objects to which references are found (elsewhere) in the document. If so, these references are marked, and the user is given a warning something like: "You are deleting [referenced object]. There are references to it in the document!" The user can then modify the marked references. This is just a basic service. A further commodity would be: "Do you want to redirect these references?" If 'yes', the user gets engaged in the same procedure that is invoked by right-clicking on a reference and choosing "Edit fields". He can then select a new target. Once he gives "Okay", the existent references to the object about to be deleted are redirected. Then the user can proceed with his deletion operation. Steps to Reproduce: 1. Mark a string in the document that contains a referenced object. 2. Delete it. Actual Results: It is deleted, and references to it are replaced by "Error: Reference source not found". Expected Results: It should not be deleted without a warning. Reproducible: Always User Profile Reset: No Additional Info: I realize that his presupposes a function which identifies all the references to a given target, so they can either be marked in the document or be replaced by something else. Such a facility would be useful, anyway: The user may want to find all the references to a given target in order to do something about them. If such a function were available, it could also be offered in the "Find and Replace" dialog.
Christian, thanks for your idea. We should avoid the word "object" here, because objects are, shapes, charts, .... but not heading. So let's better talk about target of a cross reference => I updated bug summary and hope you agree cc: Design-Team for further input and decision.
Good idea. But I wonder what happens when you cut the target to paste it somewhere else (guess this is the leading cause of trouble). Still show a warning, perhaps non-interrupting as bubble/infobar?
Okay for the reframed bug summary, except that, as I had suggested, support to the user might be more than a mere warning. However, a warning would certainly be a useful first step. As for the operation of cutting a string out that contains a reference target, presently this triggers the replacement of the references by the "Error: Reference source not found". Normally, as soon as the string is pasted elsewhere in the document, the references are updated. However, it is possible that this does not always work; I have not checked for this. For clarity's sake, it might be added that instead of cutting a numbered paragraph out and pasting it elsewhere, you may wish to recommend the use of the Navigator arrows "Promote/Demote chapter". However, this is practical only under certain conditions which it would lead to far to explain here.
Coming back to this, sorry for the delay. My test scenario is a references to a figure showing the page number. Now I cut the figure and paste it somewhere else. The reference's link remains intact but the page number is not shown anymore. But besides of this bug, how would you know whether the target is to be pasted or deleted? I mean the suggested warning would show up anyway. The actual problem of saving/printing a document with lost references is clear to me. And if dealing with cut/delete while editing is not possible we could show the infobar on opening.
(In reply to Heiko Tietze from comment #4) > Coming back to this, sorry for the delay. My test scenario is a references > to a figure showing the page number. Now I cut the figure and paste it > somewhere else. The reference's link remains intact but the page number is > not shown anymore. > > But besides of this bug, how would you know whether the target is to be > pasted or deleted? I mean the suggested warning would show up anyway. > > The actual problem of saving/printing a document with lost references is > clear to me. And if dealing with cut/delete while editing is not possible we > could show the infobar on opening. Heiko, I am not sure that the distinction between cut out and delete is actually a problem. I have a test file with a numbered object and a reference to it. If I cut out the numbered object, the reference is changed to 'Error: Reference source not found'. As soon as I paste the object somewhere, the reference is updated. There are two points at which the software could note the difference: a) Cutting out is a different operation from deletion. Put out a warning only if a numbered object to which there are references is deleted. b) If the user launches a Save operation, check if there are instances of 'Error: Reference source not found', and if so, warn the user and offer 'Cancel' (of the Save operation).
(In reply to Christian Lehmann from comment #5) > (In reply to Heiko Tietze from comment #4) > > Coming back to this, sorry for the delay. My test scenario is a references > > to a figure showing the page number. Now I cut the figure and paste it > > somewhere else. The reference's link remains intact but the page number is > > not shown anymore. > > > > But besides of this bug, how would you know whether the target is to be > > pasted or deleted? I mean the suggested warning would show up anyway. > > > > The actual problem of saving/printing a document with lost references is > > clear to me. And if dealing with cut/delete while editing is not possible we > > could show the infobar on opening. > > Heiko, I am not sure that the distinction between cut out and delete is > actually a problem. I have a test file with a numbered object and a > reference to it. If I cut out the numbered object, the reference is changed > to 'Error: Reference source not found'. As soon as I paste the object > somewhere, the reference is updated. > > There are two points at which the software could note the difference: > a) Cutting out is a different operation from deletion. Put out a warning > only if a numbered object to which there are references is deleted. > b) If the user launches a Save operation, check if there are instances of > 'Error: Reference source not found', and if so, warn the user and offer > 'Cancel' (of the Save operation). However, both of these warnings make sense only if the user can do a Find on instances of 'Error: Reference source not found', which is a pending desideratum, anyway.
The topic was on the agenda of the design meeting. + the "Internet" recommends to search for "Reference source not found" + update is not reliable though + the only acceptable workflow is to immediately show an infobar or any other non-interrupting message and to hide it once the reference is back (eg. after cut/paste) + continuously checking the status might be a performance issue + if reference and source are far away from each other, the information might not be helpful; you probably have to clean up the broken reference somewhere else- and jumping around in the document is unwanted + heavy editing potentially produces a large number of warnings + problem when user not hides the info, or when it comes up too often + double-check whether competitors do show such a warning The decision was to check how competitors deal with the problem.
(In reply to Heiko Tietze from comment #7) > The topic was on the agenda of the design meeting. Thanks for the info. > > + the "Internet" recommends to search for "Reference source not found" What does this mean? Such a search is _not_ possible in an ODT file! > + if reference and source are far away from each other, the information > might not be helpful; you probably have to clean up the broken reference > somewhere else- and jumping around in the document is unwanted Reference and source are typically far away from each other; this is the whole purpose of a reference. If a reference is broken because the user deleted the target, only the user himself is in a position to fix the resulting error; and he _will_ want to fix it, no matter how far away the reference is.
[Automated Action] NeedInfo-To-Unconfirmed
STR: * File > New to have a fresh start * Insert three page breaks * Go to page 2 and insert an image; add a caption so we have a numbered figure * On p1 add a cross ref to this figure showing the page number 1. cut the image (should be the same as delete) -> LO Writer empties the cross-reference; the field remains but one wouldn't know unless field shading is enabled -> MS Word keeps the number 2. paste on p3 -> LO Writer: the empty field remains empty -> MS Word: the reference still shows the previous page number + undo to get to the step after cut 3. Update fields -> LO Writer: nothing happens, meaning the empty field stays empty -> MS Word: the field text changes to a bold "Error! Bookmark not defined." If we could be smarter than MSO and update the field immediately after the target changes keeping some temporary link so the reference is updated properly after paste, it would be an advantage over competitors. Showing an "empty" field seems to be a bug. But I could imagine that this has been done intentionally for some reason. Maybe to avoid too many "Error: Bookmark missing" annotations in the document ;-). In fact, we should show such a text if the reference is dead-end.
What to do with master documents? A master may include a reference to something inside a sub-document. When you edit the sub-document individually, Writer has no idea that the document *may* also be used inside some master(s). Anyway, I'd propose instead to have some kind of "orphan links" list, populated in the background (i.e., not being an immediate action for a key press, potentially making work with document impossible - but something like word count / spell check); when the orphaned items are found, there could be some information shown to user (it could be an infobar; or an icon on status bar; or whatever (not too intrusive) UX invents...), to allow them open and inspect the orphaned list.
(In reply to Mike Kaganski from comment #11) > Anyway, I'd propose instead to have some kind of "orphan links" list, > ... when the orphaned items are found The tricky part is to find it. That's why I suggested to have some warning instead of nothing on orphaned fields.
(In reply to Heiko Tietze from comment #12) > (In reply to Mike Kaganski from comment #11) > > Anyway, I'd propose instead to have some kind of "orphan links" list, > > ... when the orphaned items are found > > The tricky part is to find it. Sorry - I don't get it. If Writer provided a list of orphaned items, it could indeed allow you to navigate to each such element. Or are you talking about finding *where* should it point to? That's absolutely unrelated to the "when the orphaned items are found" quoted from my proposal.
Why not giving feedback at the field with the issue? Users might not be aware where the list is located and how to interact. But even more relevant: if you change something that have an effect somewhere else, eg. delete an image and the reference becomes an orphan, you want to know immediately. Also not perfectly solved with the inline warning but better than having a hidden list which is typically checked when you finalize the work.
(In reply to Heiko Tietze from comment #14) > Why not giving feedback at the field with the issue? Who doesn't want to give feedback? Why not describe your ideas in positive terms, instead of asking why there is something that there isn't? And also: why mixing two unrelated problems? The problem raised here is: when you remove something in position A, something may break far away in position B, which is not communicated to user in such a way that they don't overlook it. Your idea: the field in position B should show something. That is a reasonable idea, but is completely unrelated to the discussed problem, because displaying any text at B does not let user see it when they are looking at A.
(In reply to Heiko Tietze from comment #14) > if you change something that have an effect somewhere else, eg. delete an > image and the reference becomes an orphan, you want to know immediately. > Also not perfectly solved with the inline warning but better than having a > hidden list which is typically checked when you finalize the work. Just because you didn't try to read comment 11, where I gave you even two whys: because that could be impossible physically (the link that is broken is not even in the current document); and that immediate updates checked at each small edit could halt your work with document (checking everything in a large document might be time-comsuming).
1) As to the master-document issue: ODT files which are part of a master document are probably in a minute minority [any usage statistics available?]. It does not seem profitable to block a solution to a problem just because there does not appear to be a way to solve it for master documents, too. As long as it is not solved for master documents, a hint might be added to the Help text on master documents saying that the integrity of references in parts of master documents is currently not guaranteed. 2) Heiko is right that if the user is deleting the target of a reference, thus orphaning the reference without being conscious of it, he must be told _immediately_. Consider the following scenario: While working on your 100 pages document, you delete the target of a reference. Another day, when revising the document, you come across a passage "Error: reference source not found" and want to put this right. It is _very_ cumbersome to find out what the target of this reference had been. (Essentially, you have to resort to a backup of an earlier version of the file.) It is not clear how your "orphaned list" would address this problem. 3) In order to warn the user immediately, Writer would indeed have to check whether the file contains references to the thing being deleted. If this leads to performance problems, as you say, then a preliminary solution to the problem at hand might be: Allow user to do a Find on references to a certain target. He may then choose to do this, for safety's sake, before deleting a thing that he is not sure whether it is referenced somewhere. While this would be a preliminary solution, it would be work presupposed by a definitive solution.
Let me describe a bit more what I already wrote: (In reply to Mike Kaganski from comment #11) > ... something like > word count / spell check); when the orphaned items are found, there could be > some information shown to user (it could be an infobar; or an icon on status > bar; or whatever (not too intrusive) UX invents...), to allow them open and > inspect the orphaned list. So the timing is like this: 1. User types. 2. At the same time, asynchronously, a check is on-going, if there are any orphaned elements. 3. User presses Del, and removes something that is referenced elsewhere. 4. User keeps typing, and types a couple (maybe 10) more words. 5. A few seconds later, the background check from #2 finds a newly orphaned item. 6. *Some* indication appears: a balloon tip, an infobar, anything - that orphaned item is found, with a way to see a list of all orphaned items, navigate to them in the document, and maybe undo a few keypresses if needed. Since it is close to the point when the problem was created, the user can see where the problem was. Since it's asynchronous, it doesn't block every keypress. And there's no need to force user to find anything. And the solution is not limited to any special case: e.g., it would also find already orphaned items crated in older versions without such a check, or in master documents after the fact.
This would be a solution to the problem.
There is still the lateral problem of what to do when user does not delete a referenced item, but just cuts it out (probably in order to place it somewhere else). If the warning that a reference is currently broken would pop up while he is transferring the item, it would be disturbing rather than useful. Minimal solution: If the warning pops up, it (of course) suffices for the user to click it off if it is of no interest to him. If the algorithm has found and announced a missing reference target, and this is then reinserted into the file, then not only are its references deleted from the orphaned list, but also the popup balloon is automatically closed.