Bug Hunting Session
Bug 86785 - Relative links UX in Writer master documents
Summary: Relative links UX in Writer master documents
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.4.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Master-Doc
  Show dependency treegraph
 
Reported: 2014-11-27 13:26 UTC by Moritz Ulmer
Modified: 2019-05-14 02:53 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
zip with master document and 3 subdocuments (27.83 KB, application/x-zip-compressed)
2016-09-21 13:23 UTC, Ákos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Ulmer 2014-11-27 13:26:01 UTC
I have not been able to set the path of included documents in a master document as relative. The following settings were set:

Options - Load/Save - General: Save URLs relative to filesystem
Options - Load/Save - General: Save URLs relative to internet

The following methods of setting the file path:

Navigator - Insert - File - Cover.odt - Save

Then checking the link:

Navigator - Right click Cover.odt - Edit link - Link - File name: "file:///home/... .../Writer/chapters/Cover.odt"

The master document is saved in "/home/... .../Writer/Thesis.odm"

When changing the File name field to: "chapters/Cover.odt" it results in the following: "http://chapters/Cover.odt" with a message that the file is not found and not included in the master document.

What is the proper way to define the relative path?

Kind Regards,
Moritz

P.S. a similar bug was reported here: https://bugs.freedesktop.org/show_bug.cgi?id=79305
Comment 1 raal 2015-03-20 16:29:11 UTC
(In reply to Moritz Ulmer from comment #0)
Hello Moritz,

> 
> P.S. a similar bug was reported here:
> https://bugs.freedesktop.org/show_bug.cgi?id=79305

Bug 79305 is fixed, please could you retest your issue? Thank you.
Comment 2 Moritz Ulmer 2015-03-20 17:24:26 UTC
Hi,

I just tested it, and I might have to clarify my use case:

I create a master document with each chapter in an individual file in a subfolder (as often done in Latex). I then send the .zip of all files and folders, preserving their relative paths. Another user then opens the master folder on their PC (Windows/Mac/Linux) and since the path to each folder is saved in the relative path, can open it without complications.

Is this behaviour already possible? An example path would be "file:chapter/Cover.odt". I currently use this behaviour in a TiddlyWiki to link images and PDFs. This allows the wiki to remain portable, i.e. used from a USB stick or by a different user.

Kind Regards,
Moritz Ulmer
Comment 3 Ákos 2016-09-21 13:23:06 UTC
Created attachment 127512 [details]
zip with master document and 3 subdocuments

I try what you want, and works for me.
The path is relative.
Comment 4 Buovjaga 2016-10-09 11:14:26 UTC
Mortiz: any comment on Ákos's testing result?

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away in a new version.
Comment 5 Moritz Ulmer 2016-10-10 12:18:29 UTC
Writer handles and has always handled relative paths correctly. In that case that case, this bug can be closed.

What I have a problem with, is that it is not possible to define a relative path in the "Edit Sections" GUI (Navigator (F5) - right-click a linked document - Edit link) and then go to the "File name" text edit field. It does not show the relative file path and it is not possible to enter relative paths.

If the above mentioned behavior will not be changed, the bug report can be closed, otherwise I would request that this behavior be fixed.
Comment 6 Buovjaga 2016-10-11 16:43:42 UTC
(In reply to Moritz Ulmer from comment #5)
> What I have a problem with, is that it is not possible to define a relative
> path in the "Edit Sections" GUI (Navigator (F5) - right-click a linked
> document - Edit link) and then go to the "File name" text edit field. It
> does not show the relative file path and it is not possible to enter
> relative paths.

It appears you are right. If I add a relative path, it gets prepended with http://

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: 65f2d6b1cc40b4b90f8987e8ea14d24b5f38f950
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on October 10th 2016
Comment 7 QA Administrators 2018-05-13 02:30:56 UTC Comment hidden (obsolete)
Comment 8 Moritz Ulmer 2018-05-13 10:27:41 UTC
Tested on the 13th of March, 2018 with:

Version: 6.0.3.2
Build ID: 1:6.0.3-0ubuntu1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group

The absolute path to the file to be included is `file:///home/user/path/to/file.odt`

Tested three times, once resulting in a freeze, the other time `http://` was appended when defining the relative path `path/to/file.odt`, and finally when defined as `file://path/to/file.odt` it results in being renamed as `smb://path/to/file.odt`

The behavior has not changed since initially reporting the bug.
Comment 9 QA Administrators 2019-05-14 02:53:22 UTC
Dear Moritz Ulmer,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug