Bug 149153 - Allow / Include labels in sections with linked files in master document
Summary: Allow / Include labels in sections with linked files in master document
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Section Writer-Master-Doc
  Show dependency treegraph
 
Reported: 2022-05-18 13:16 UTC by sdc.blanco
Modified: 2022-06-27 10:21 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
empty sections in a master document (7.52 KB, image/png)
2022-06-07 10:33 UTC, sdc.blanco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2022-05-18 13:16:39 UTC
Open a master document (with several linked files), without updating links.

Actual: a bunch of empty sections boundaries
Expected (and requested): A meaningful identifier in each linked section

Additional Information:

1. A master document can have many sections.

2. Fortunately(?) it is not possible to turn off section boundaries (bug 129905), so a beginning user of master document would at least see the sections. But if that bug is fixed, then no indication (except for Navigator) that files are linked in master document (if Section boundaries are not enabled in Options).

3. Suggestion:  add (for example) full path name as a "label" for each linked section in master document.
   
4. Note that, at present, any text written in a section is "lost" when the section is updated with a linked file (bug 128843). 
     => open a master document, if links are not updated, then write link paths into the (protected) sections.  If/when a section is updated, this "label" will be automatically lost (as desired/expected).

Test to illustrate this point:  
    a. In master document, edit section (unprotect, add some text in section, 
       but keep link). 
    b. Write protect section again and Save master document.
    c. Update link (to section)

  Result:  saved text is gone, contents of linked file appear.

   => Could use this behavior as a way to label sections in master document,
      without having the label added to updated link.

5. Continuing the previous point:
   a. In master document, edit section (unprotect, add some text in section, 
      but keep link). 
   b. Write protect section again.
   c. Save master document.
   d. Reload document, without updating links.

Actual result:  Text written into section is lost, even though link was not updated.

==> does this behavior undercut the proposal in point 4?

6. Presumably some users will not want link labels (e.g., because they
selectively print the master document with only some links updated),
so possibly have a checkbox option (Tools > Options > Writer > View)
to control whether to show section labels or not in master document.

Motivation for request

A master document (with 22 links, for example) has a lot of empty grey rectangles. (when I first started with master documents, I did not understand what they were).

If the sections were labeled in a meaningful way, then possible to:
   a. see the master structure, without having to use Navigator.
   b. edit the links of these sections directly (right-click Edit Section)
   c. Add documents to master structure directly w/o Navigator.  
      (Alt+Enter, Insert Section, etc.) 

In short: 
   - for new users, labelling helps to understand "contents" (or lack thereof) in the master document. 
   - for experienced users, allow working directly in master document, instead of using Navigator. 
   - for all users, can see document structure (and any text written in master document) -- which is not possible in Navigator.
Comment 1 Dieter 2022-06-05 09:37:45 UTC
(In reply to sdc.blanco from comment #0)
> Test to illustrate this point:  
>     a. In master document, edit section (unprotect, add some text in
> section, 
>        but keep link). 
>     b. Write protect section again and Save master document.
>     c. Update link (to section)
> 
>   Result:  saved text is gone, contents of linked file appear.
> 

I confirm tis behaviour with

Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 5423dfb8549743bd5045b6e3b1ebad7980e62965
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Additional informations
If you change number of columns in a section, new number of columns apears after reopening, but it isn't part of the linked document (maybe expected)

So I agree with the problem, but I'm not sure, if a we can solve this problem only with labelling sections.

At least related to bug 118122.

cc: Design-Team
Comment 2 Heiko Tietze 2022-06-07 10:08:43 UTC
Isn't this the option "Update links when loading" set to off for security reasons?
https://help.libreoffice.org/7.3/en-GB/text/shared/optionen/01040900.html?&DbPAR=SHARED&System=MAC
Comment 3 sdc.blanco 2022-06-07 10:33:35 UTC
Created attachment 180615 [details]
empty sections in a master document

(In reply to Heiko Tietze from comment #2)
> Isn't this the option "Update links when loading" set to off for security
> reasons?
No.  Not sure what you are thinking about here, but have tested these options with a master document.

Setting to "Always", there is still always a confirmation dialog about whether to update links.  Setting to "Never", there is no confirmation dialog.

But the OP is about better labeling of the empty sections in a master document.
Have attached an actual example here to illustrate -- where I have used "text" fields to at least give some overview.  (as already noted, can use Navigator, but enhancement request in OP is to have something in the empty section containers.)

(the details in the OP were only to show attempts to "address" this request with existing features. As noted in confirming comment, another approach might be needed.)
Comment 4 QA Administrators 2022-06-08 03:32:31 UTC Comment hidden (obsolete)
Comment 5 Heiko Tietze 2022-06-08 06:23:44 UTC
If you reject to update the links when opening a master document it won't show any content. The option "Tools > Options > Writer > Update links when loading" has an effect when set to "Never" and does not ask for an update. But "Always" does not suppress the confirmation box defaulting to Yes.

Ordinary documents with a linked file in a section show the same confirmation box with the same issue but have some cached content saved so the previous state of the linked file is shown.


First of all, the option seems to be broken (dup of bug 128498). "Always" should never ask and default to Yes, Never should never ask and default to No. 
I cannot confirm bug 43786 claiming the option is document specific (did switch without saving the document). 
Bug 135508 requests to always update was rejected with to the security argument (but reopened).


Regarding the feedback: whether we show some cached content or not- if the data is not updated we should give a clue. Bug 43784 suggest an infobar, not a bad idea. Adding some dummy text into the section is easy to overlook. The better solution is to show an overlay like known from media that wont play unless clicked.
Comment 6 sdc.blanco 2022-06-08 08:43:44 UTC
(In reply to Heiko Tietze from comment #5)
> Regarding the feedback: 
> Adding some dummy text into the section is easy to overlook.
In the "Edit section" dialog, it is possible to give a "label" or "title" (the control is not labeled, so I do not know what it should be called), where this label is what is shown in Navigator. Perhaps that "label" could also be included on/in the section in the document -- when the link has not been updated -- instead of the current "blank".  (That would be an adequate resolution to OP).

Not sure how it would be easy to overlook, given that -- as attachment shows -- nothing is shown in a section that is not updated. While in this case, the labels would be what the user has chosen in the "Edit section" dialog.
Comment 7 Heiko Tietze 2022-06-27 10:21:01 UTC
Recommendation for solution in comment 5 and 6, removing UX.