(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.

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

Created attachment 127512 [details]
zip with master document and 3 subdocuments

I try what you want, and works for me.
The path is relative.

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.

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.

(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

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.

I just ran into this bug myself, so I can confirm it is still present in:

Version: 6.2.8.2
Build ID: 6.2.8.2-2.fc30
CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (C.UTF-8); UI-Language: en-US
Calc: threaded

I also observed the 
file://document.odt->smb://document.odt, and document.odt->http://document.odt behaviors.

I didn't try 6.4, but since this was reported in 4.3 I doubt it was accidentally fixed in the meantime. 

I was really hoping to find a solution, because this would be the perfect functionality for what I need. Without being able to link sections to relative paths, every time I make a copy of the directory, I have to manually change all of the absolute links because they still point to the old directory. I'm looking into Master Documents as an alternative, but linked sections would have been a lot simpler.

*** Bug 143007 has been marked as a duplicate of this bug. ***

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 https://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://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug