Created attachment 95625 [details] zip archive containing various files demonstrating bug .ods and .sxc files retain external data links but the "update every [n seconds]" setting either gets reset or corrupted. .xls and .xlsx files do not retain external data links. To reproduce: 1. Create a new document 2. Insert external data of your choice with some low value for the "update every [n seconds]" setting, to verify that the data is in fact updating every n seconds. 3. Save as one of the specified file types and close the document. Then: Case 1 (.ods, .sxc) Open the file again and it will retain the link to external data, but will have corrupted or reset the "update every [n seconds]" setting. Open up the Edit->Links window, hit modify, and the setting will have changed from n seconds to some other value. In my tests the results were that with n=10 it would change to 9,999, and with n=60 it would change to 60,000. So it seems this value is becoming corrupted somehow. Case 2 (.xls, .xlsx) Open the file again and it will not retain the link to external data, at all. These are the only file types I've tested, and I'm not sure if external data is only supposed to work with certain formats and not others. Some test files are included in the attached zip archive. I also have a .xls file that I have been working with for a while (since 4.1 I think) that DOES work as expected. I have included a stripped down, but still working, version of this file in the attached archive. As another test, I tried converting the working .xls file to a .ods file and it resets just like a new .ods file does. This is also included in the archive. I found a related bug (https://www.libreoffice.org/bugzilla/show_bug.cgi?id=57330) that I will comment on as well.
Created attachment 95626 [details] zip archive containing various files demonstrating bug
Created attachment 95628 [details] zip archive containing various files demonstrating bug
Created attachment 105136 [details] ZIP containing ODS, XLS, XLSX created under LOv4162, LOv4262, and LOv4400 TL;DR Summary ------------- Case 1: - Provided files do (mostly) have very high update frequency values. - Change-in-update-frequency behaviour reported (10 sec to 9999 sec and 60 sec to 60,000 sec) may have been related to v4.2.1.1 under which the provided files were created. I cannot confirm this behaviour using the versions indicated below. Case 2: - Saving to XLS is OK however there is strange Import Options dialog behaviour when attempting to edit links. Refer note [1] below. - Saving to XLSX seems to completely break external links. Testing overview ---------------- There appear to be a number of issues highlighted by this bug. Attachment 95628 [details] contains these files: a) coinmarketcap-new-broken.xls b) coinmarketcap-new-broken.xlsx c) coinmarketcap-new-resets-10-9999.ods d) coinmarketcap-new-resets-10-9999.sxc e) coinmarketcap-new-resets-60-60000.ods f) coinmarketcap-new-resets-60-60000.sxc g) coinmarketcap-ods2xls-broken.xls h) coinmarketcap-old-working.xls i) coinmarketcap-old_xls2ods-resets.ods I have initially tested the links in the above files by opening each under these versions: 1) v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a 2) v4.2.6.2 Build ID: 185f2ce4dcc34af9bd97dec29e6d42c39557298f 3) v4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0 4) v4.4.0.0.alpha0+ Build ID: e379401618268ed7f7f5885a36b90e1f4f6cd4af TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-08-18_05:51:03 Intial test ----------- Ask to update? Are links updated? Update every N sec? a) 1) N - - 2) N - - 3) N - - 4) N - - b) 1) N - - 2) N - - 3) N - - 4) N - - c) 1) Y Y 99,999 2) Y Y 99,999 3) Y Y 99,999 4) Y Y 99,999 d) 1) Y Y 99,999 2) Y Y 99,999 3) Y Y 99,999 4) Y Y 99,999 e) 1) Y Y 60,000 2) Y Y 60,000 3) Y Y 60,000 4) Y Y 60,000 f) 1) Y Y 60,000 2) Y Y 60,000 3) Y Y 60,000 4) Y Y 60,000 g) 1) N - - 2) N - - 3) N - - 4) N - - h) 1) Y Y 60[1] 2) Y Y 60[1] 3) Y Y 60[1] 4) Y Y 60[1] i) 1) Y Y 99,999[1] 2) Y Y 99,999[1] 3) Y Y 99,999[1] 4) Y Y 99,999[1] [1] Edit > Links... > Modify... displays the Text Import dialog. Clicking Cancel then displays the update time. Summary: - Behaviour for each file appears consistent across versions. - Only new XLS/XLSX lose the ability to prompt for update. - Update frequency for nearly all files that update is set to a very high value. This may be the result of v4.2.1.1 under which the files appear to have been created (refer New File Test below). Fix/Break Test -------------- Using v4.4.0.0 (4) in a simple attempt to try and repair / break some of the provided files: - Open (a). Save as XLS (new name). Close. Reopen. LINKS (STILL) BROKEN. - Open (b). Save as XLSX (new name). Close. Reopen. LINKS (STILL) BROKEN. - Open (c). Save as XLS (new name). Close. Reopen. LINKS BROKEN. - Open (c). Save as XLSX (new name). Close. Reopen. LINKS BROKEN. - Open (e). Save as XLS (new name). Close. Reopen. LINKS BROKEN. - Open (e). Save as XLSX (new name). Close. Reopen. LINKS BROKEN. - Open (g). Save as XLS (new name). Close. Reopen. LINKS (STILL) BROKEN. - Open (g). Save as XLSX (new name). Close. Reopen. LINKS (STILL) BROKEN. - Open (h). Save as XLS (new name). Close. Reopen. OK. - Open (h). Save as XLSX (new name). Close. Reopen. LINKS BROKEN. It appears in simple terms that once the links are broken they cannot be repaired by re-saving in an up-to-date version. Furthermore links in the "old-working" XLS stop working after being saved as XLSX. New File Test ------------- Create a new file using the indicated file formats / versions with: - http://coinmarketcap.com/currencies/views/all/ - Select table HTML__currencies-all - Update frequency of 60 sec ODS: (1) Save. Close. Reopen. LINKS UPDATE. FREQ PRESERVED. (2) Save. Close. Reopen. LINKS UPDATE. FREQ PRESERVED. (3) LINK FAIL ON ENTRY. This appears to be bug 49043 again. (4) Save. Close. Reopen. LINKS UPDATE. FREQ PRESERVED. XLS: (1) Save. Close. Reopen. LINKS UPDATE. FREQ PRESERVED[1]. (2) Save. Close. Reopen. LINKS UPDATE. FREQ PRESERVED[1]. (3) N/A see above. (4) Save. Close. Reopen. LINKS UPDATE. FREQ PRESERVED[1]. XLSX: (1) Save. Close. Reopen. LINKS BROKEN. (2) Save. Close. Reopen. LINKS BROKEN. (3) N/A see above. (4) Save. Close. Reopen. LINKS BROKEN. Refer attached for files created from this last series of tests.
As a result of comment 3 I am confirming this bug, as there are problems, but not as many as originally indicated. The main issue is with the XLSX file format not preserving links to external data (HTML tables). Summary amended for clarity. Status set to NEW. Version set to v4.1.6.2 (but may be older). Operating System set to All. Bug 57330 removed from See Also list as it relates to XLS. If the update frequency issue (or a problem specific to the XLS format that is not covered by bug 57330) can be demonstrated in a clear and simple manner, please open a new bug for this as the policy is: one bug, one issue. Thanks.
I can confirm that I am no longer experiencing the update frequency issue in version 4.3.0.4. XLS files also now retain the external data link, and the only problem remaining is with XLSX, as explained in comments 3 and 4.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.0.5 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
XLSX still losing links. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: b216cc1b8096eb60c27f67e8c27b7cd756c75e38 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-12_00:06:20 Locale: fi-FI (fi_FI)
*** Bug 100999 has been marked as a duplicate of this bug. ***
It is working for me with LibreOffice 5.2.2 (Ubuntu 16.04
The problem I identified in Bug 100999, which was redirected to be a duplicate of this bug (whether it is or not I don't know), still exists. That is: 1. save links in .ods file, works fine 2. save links in .xls file, works fine 3. save links in .xlsx file, fails LibreOffice 5.1.5.2 Windows 10
(In reply to Andrew from comment #10) > The problem I identified in Bug 100999, which was redirected to be a > duplicate of this bug (whether it is or not I don't know), still exists. > > That is: > > 1. save links in .ods file, works fine > 2. save links in .xls file, works fine > 3. save links in .xlsx file, fails > > LibreOffice 5.1.5.2 > Windows 10 ..and is there a reason you did not test with 5.2.2 like Bartosz?
When I clicked on "Help / Check for Updates" it told me I was up to date. Is that another bug? Is there a reason to expect it has been fixed in between? When I do update, I will check again.
(In reply to Andrew from comment #12) > When I clicked on "Help / Check for Updates" it told me I was up to date. > Is that another bug? > > Is there a reason to expect it has been fixed in between? When I do update, > I will check again. You can just download it: http://www.libreoffice.org/download/libreoffice-fresh/ The reason we suspect that is that Bartosz reported it fixed in 5.2.2.
Test scenario: 1. I have opened coinmarketcap-new-update_60s_LOv4162.xlsx, coinmarketcap-new-update_60s_LOv4262.xlsx and coinmarketcap-new-update_60s_LOv4400_2014-08-18.xlsx filew with LO 5.2.2 2. All links are working. After clicking it with CTRL + Right Mouse Buttton it is moving to corrsponding site. So in my opinion the original bug report was resolved. There are still missing message after .xlsx run: "This file contatins links to other files. Should they be updated?"
I have now tried running it with 5.2.2.2 I still get the same problem.
It may be relevant that Bartosz is running on Ubuntu, and I on Windows 10. I do get the "This file contains links to other files. Should they be updated?" message.
Bartosz: please test with coinmarketcap-old-working.xls, saving it to .xlsx. I can repro the losing of links with that. The file is in attachment 95628 [details] Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ Build ID: e2f6c7f0d0cc14f851d7028ff846c5dc658a81c6 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-10-10_23:08:02 Locale: fi-FI (fi_FI); Calc: group
I have tried this again with Version 5.3.7.2 (x64) With .xlsx I am still having many problems. Saving all the files as .xls and they seem to be working OK.
It is on Version: 6.1.0.0.alpha0+ Build ID: c8c74a0b4ca6f3a3619f423b6548c80c52392ae0 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-04-14_22:59:27 Locale: es-ES (es_ES); Calc: group Links that are broken they are arrays, not single cells references. Attached a target.ods and a source01.ods Saving the "target.ods" as "target.xlsx" and reopen/reload shows the issue, file name is changed for the array links, substituted by a number. This issue causes a data lost, set up as critical.
Created attachment 141477 [details] Sample file with the links
Created attachment 141478 [details] Source file for links
*** Bug 120845 has been marked as a duplicate of this bug. ***
*** Bug 116331 has been marked as a duplicate of this bug. ***
*** Bug 121472 has been marked as a duplicate of this bug. ***
*** Bug 126821 has been marked as a duplicate of this bug. ***
This is a critical data loss issue reported over 5 years ago – when can a fix be prioritized?
Issue still Version: 6.4.0.0.alpha1 (x86) Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc:
*** Bug 122015 has been marked as a duplicate of this bug. ***
(In reply to m.a.riosv from comment #21) > Created attachment 141478 [details] > Source file for links I gave a try on pc Debian x86-64 with master sources updated today. When saving ods target file into xlsx, I noticed these logs: warn:svl.numbers:42845:42845:svl/source/numbers/zforlist.cxx:895: SvNumberFormatter::GetFormatStringForExcel - format not found: 4294967295 warn:legacy.osl:42845:42845:sc/source/core/tool/address.cxx:1601: ScRange::ExtendTo - cannot extend to invalid range warn:legacy.osl:42845:42845:sc/source/core/tool/address.cxx:1601: ScRange::ExtendTo - cannot extend to invalid range ... About Coinmarketcap, I noticed that tdf#117905 has been closed since public API is gone (see https://bugs.documentfoundation.org/show_bug.cgi?id=117905#c11)
The 30 "warn:legacy.osl:42845:42845:sc/source/core/tool/address.cxx:1601: ScRange::ExtendTo - cannot extend to invalid range" I got correspond to the 30 REF pbs. In xlsx, instead of having: ='file:///tmp/Source01.ods'#$SheetA.A1:E3 There's: ='file:///tmp/1'#$SheetA.A1:E3 Eike: thought you might be interested in this one.
We now also have Macs in our company and i noticed the same behaviour on latest MacOSX versions. Will someone have a look at this (how many years old?) bug finally???
(In reply to egc from comment #31) > Will someone have a look at this (how many years old?) bug finally??? No matter how many ?????? you put, it can only be fixed if you do it yourself, find someone to do it or wait for a volunteer to do it. Do not annoy people who have the same problem and follow this and who maybe contribute to the project somehow -even if spending time to fix your wrong report marking as a duplicate, because you hadn't search before submitting.
(In reply to Timur from comment #32) i mean ... are you nuts?
(In reply to egc from comment #33) > (In reply to Timur from comment #32) > > i mean ... are you nuts? No Timur is completely right. Why do you think people just obey to what you command? Now, nobody forces you to use LO, if this bug is blocking for you and your company, you can also switch to another Office suite.
(In reply to Julien Nabet from comment #34) > (In reply to egc from comment #33) > > (In reply to Timur from comment #32) > > > > i mean ... are you nuts? > > No Timur is completely right. > Why do you think people just obey to what you command? > Now, nobody forces you to use LO, if this bug is blocking for you and your > company, you can also switch to another Office suite. don't worry, we will, if that's the purpose of Libreoffice ...
(In reply to egc from comment #35) > (In reply to Julien Nabet from comment #34) > > (In reply to egc from comment #33) > > > (In reply to Timur from comment #32) > > > > > > i mean ... are you nuts? > > > > No Timur is completely right. > > Why do you think people just obey to what you command? > > Now, nobody forces you to use LO, if this bug is blocking for you and your > > company, you can also switch to another Office suite. > > don't worry, we will, if that's the purpose of Libreoffice ... One of the purposes is to be sustainable. Timur explained some of the ways this is achieved (completely standard free & open source development model). Of course the result would be "nuts", if everyone would just leech without contributing. If you don't have time/money to contribute, then you just have to wait.
(In reply to egc from comment #35) > ... > don't worry, we will, if that's the purpose of Libreoffice ... To stay in the ironical tone, "yes it is indeed!". Considering https://en.wikipedia.org/wiki/Comparison_of_office_suites#Main_components, there's some choice!
(In reply to Buovjaga from comment #36) > (In reply to egc from comment #35) > > (In reply to Julien Nabet from comment #34) > > > (In reply to egc from comment #33) > > > > (In reply to Timur from comment #32) > > > > > > > > i mean ... are you nuts? > > > > > > No Timur is completely right. > > > Why do you think people just obey to what you command? > > > Now, nobody forces you to use LO, if this bug is blocking for you and your > > > company, you can also switch to another Office suite. > > > > don't worry, we will, if that's the purpose of Libreoffice ... > [...] > If you don't have time/money to contribute, then you just have > to wait. We were waiting enough now. This bug is 6 years old, since the first version of 6.x ... I tried to keep Libreoffice in the company, but i can not do it for ever ...
(In reply to Julien Nabet from comment #37) > (In reply to egc from comment #35) > > ... > > don't worry, we will, if that's the purpose of Libreoffice ... > > To stay in the ironical tone, "yes it is indeed!". > > Considering > https://en.wikipedia.org/wiki/Comparison_of_office_suites#Main_components, > there's some choice! Glad you're having fun ... As i'm not a programmer my only choice is it now to convert all the calc documents to the other office package already in use in the company. But thanks anyway for the enlightening link, it helped us a lot!
(In reply to egc from comment #39) > .... > > Glad you're having fun ... As i'm not a programmer my only choice is it now > to convert all the calc documents to the other office package already in use > in the company. Please read what several people indicated, you can: - wait - fix it yourself OR - pay someone to do it. For the rest, you can't convince your company to stick on LO just because you like it. You/your company must consider ads/cons. ads: - it's free - you can fix the bugs or pay someone to fix the bugs since it's open source - multi envs (but I suppose most companies don't care since they use Windows and when they use Linux, it's rather for servers where Office suites are not so used, except for batch treatments for some cases) - some relevant features for you/your company may be present in LO exclusively cons: - less mature than other Office suites (like Ms) (at least from my opinion) - more difficult to have support - depending what module you use, you may undergo lots of bugs (eg: use of Firebird in Base is a real pb for the moment) - some relevant features for you/your company may be lacking in LO So if you and your company: - don't want/can't pay for bug fixes - can't fix bug yourselves - can't wait anymore (I agree 6 years is too long) => you should consider migrating. Now, I suppose you and your company already know that migrating has also a cost: - license (except if you choose a free Office suite)/support - time consuming for IT people who'll do the migration and have to deal with potential incompatibilities - user training (even if the interfaces are quite similar, there are always differences) So perhaps it may be relevant to compare cost migration and cost to pay someone to fix this bug and other bugs which are blocking for you.
(In reply to Julien Nabet from comment #40) As i already wrote, an other office package (MS) is already in use by some people in the company and at home, so the company for sure is not willing to pay for bug fixes in LO. I was hoping i could keep both office packages, but with such blocking bugs like this one, and for so long time, my arguments for keeping LO in the company are go to 0. As i said i'm not a software developer so i can not really tell, but i could imagine, that this bug is not such a big deal to be fixed by one of the programmers of LO. LO just duplicates the external links, so someone would just need to have a look at it why this happens, fix that, and that's it. I guess it could be done in 15 minutes for someone who knows the code. But i don't see any will of the LO developers to fix this bug ... People continue reporting the same thing since 6 years and nobody in LO seems to find it worth to deal with it. This is not just a minor bug, it is a deal breaker for a mixed environment with two office packages and more operating systems in use. That's why i don't understand why none of the programmers is trying to fix this bug. I repeat: It is a deal breaker. Not just a little formatting (or whatever) bug. So you're right, at the end it will be time consuming for me to convert all the calc sheets to Excel and make them work there. This way my effort goes actually into MS Office instead of LO ... which is absurd in my eyes ...
(In reply to egc from comment #41) > (In reply to Julien Nabet from comment #40) > > As i already wrote, an other office package (MS) is already in use by some > people in the company and at home, so the company for sure is not willing to > pay for bug fixes in LO. I had missed this part so no need to stick on LO indeed except if you're a big supporter of OpenSource. > I was hoping i could keep both office packages, but with such blocking bugs > like this one, and for so long time, my arguments for keeping LO in the > company are go to 0. The goal of a company is to make money so no surprise here. > > As i said i'm not a software developer so i can not really tell, but i could > imagine, that this bug is not such a big deal to be fixed by one of the > programmers of LO. LO just duplicates the external links, so someone would > just need to have a look at it why this happens, fix that, and that's it. I > guess it could be done in 15 minutes for someone who knows the code. So you're not a software dev but "you could imagine it's not a big deal". What about taking some hours to learn some C++ (after all there are Youtube videos to learn C++ in 1 or some hours) then give it a try, here's a link to start with: https://wiki.documentfoundation.org/Development/GetInvolved To install needed software and build the code hours, let's suppose some 3/4 hours. I'm pretty sure that just with a good will, you may submit a fix on gerrit in some days. There are also some people of your IT who may contribute. If they already know how to program (and perhaps how to program in C++) perhaps they may submit a bugfix in just 2 days? > > But i don't see any will of the LO developers to fix this bug ... People > continue reporting the same thing since 6 years and nobody in LO seems to > find it worth to deal with it. This is not just a minor bug, it is a deal > breaker for a mixed environment with two office packages and more operating > systems in use. > That's why i don't understand why none of the programmers is trying to fix > this bug. I repeat: It is a deal breaker. Not just a little formatting (or > whatever) bug. Consider this: - take a look at the number of bugs declared in Bugzilla - there are only about a dozen of expert devs which regularly contribute and in those, there are some who are quite driven by the company they belong (I mean they fix the bugs their company indicate wrt what clients paid) => it may give you some hints. > > So you're right, at the end it will be time consuming for me to convert all > the calc sheets to Excel and make them work there. This way my effort goes > actually into MS Office instead of LO ... which is absurd in my eyes ... It's just your/company choice to not pay LO because they wrongly consider since it's freely downloadable, you shouldn't pay to fix the bugs. So stop telling it's just devs fault and see there's also you/your company fault not willing to contribute in a way (money or programming).
(In reply to Julien Nabet from comment #42) Yeah right, learning C++ in one or more hours ... for someone who has no idea about programming languages ... Anyway, i realise that i'm in the wrong place here. i always thought a bugtracking system (as far as i know them) is a place where normal users can find and report bugs to the developers so they fix them (of course, if someone of the users is also able to contribute for the fix they can do that too, but that's not the case with me), but that doesn't seem to be so here. Here i only get advices to fix it myself or to let it fix by the company or to get a software developer and fix it ... or to change to another office suite ... Great! Sorry for wasting your time. Have a good one!
(In reply to egc from comment #43) > (In reply to Julien Nabet from comment #42) > > Yeah right, learning C++ in one or more hours ... for someone who has no > idea about programming languages ... I supposed so. Still, you considered the bug is fixable in 15 min with no programming knowledge or LO code source knowledge... Hope you don't speak the same way with mechanics, plumber, etc. when you got car or house problems :-) > > Anyway, i realise that i'm in the wrong place here. i always thought a > bugtracking system (as far as i know them) is a place where normal users can > find and report bugs to the developers so they fix them (of course, if > someone of the users is also able to contribute for the fix they can do that > too, but that's not the case with me) > but that doesn't seem to be so here. Take a look here https://cgit.freedesktop.org/libreoffice/core/log/ and you'll see that most commits which include "tdf#" is a fix (some may be just related like automatic test to avoid some regression on this part). So yes the bugtracking system works well for quite some bugs. > Here i only get advices to fix it myself or to let it fix by the company or > to get a software developer and fix it ... or to change to another office > suite ... Great! In this case yes, nothing wrong here. The pb here is you expect the same support for LO which is released freely by TDF than you'd expect from Microsoft for MsOffice which you must pay for. > > Sorry for wasting your time. Have a good one! No pb here to discuss here. Have a good day too!
(In reply to Julien Nabet from comment #44) > The pb here is you expect the same support for LO which is released freely > by TDF than you'd expect from Microsoft for MsOffice which you must pay for. I was talking about other open source bug tracking systems, not Microsoft or so, i don't even know those bug tracking systems. But it's ok ...
There's a very appealing solution to this, especially if you're using LibreOffice in a company environment, helping both you and the eco system around LibreOffice: buy support from one of the commercial entities and they'll happily fix the bug for you. See https://www.libreoffice.org/get-help/professional-support/
(In reply to Eike Rathke from comment #46) > There's a very appealing solution to this, especially if you're using > LibreOffice in a company environment, helping both you and the eco system > around LibreOffice: buy support from one of the commercial entities and > they'll happily fix the bug for you. See > https://www.libreoffice.org/get-help/professional-support/ I know i know by now ... Everybody here repeats the same thing. I just wonder if you need all the fuzz of a bug tracking system for this ... You could have simply said already 6 years ago: "We will not fix this bug, buy yourself a support to fix it." Instead of letting people wait for t years ...
By the way, after 6 years the status of this bug, which is classified as "major" important, is still on "new" and not assigned to anybody. You could at least add a new handy status, something like "will be ignored" or "the very appealing solution for this bug is to buy yourself a support and/or fix it yourself" ... and close the bug. This way people at least know what they can expect from this bug tracking system ...
Attila Szűcs committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0d193c12a673fade8ece9d84cc4024fafdf52c9b tdf#76047 XLSX import: fix links to external data It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Attila, and thanks for taking care of this problem! I don't know if i did the right thing ... I downloaded the daily package Linux-rpm_deb-x86_64@86-TDF-dbg 2020-10-16 06:42:15 df74aef from https://dev-builds.libreoffice.org/daily/master/current.html but in this the problem still shows up. After putting the right link to the external sheet, then saving the xlsx file and closing and reopening the document the external link is doubled again and looks like this: file:///home/user/Software/Libreoffice7xx/home/user/Software/Libreoffice7xx/source.ods Thanks! Best, egc
Created attachment 166840 [details] Much simpler example files from LO 7.1alpha This contains a very simple reproducer file: Externaldata.ods - with two data connections to a CSV and an XLSX file, as seen in Edit - Links to External Files. Externaldata-LO7.xlsx - the same example file saved to XLSX. Edit - Links to External Files is disabled when this is opened in Calc and Excels Data - Connections (ribbon) - Connections (button) also opens an empty dialog. Calc exports absolutely nothing of the connection information to XLSX format. EDATAE13.csv - Data source file EDATAE13.xlsx- Data source file
Created attachment 166841 [details] The reproducer ods in Calc with Edit Links dialog Version: 7.1.0.0.alpha1+ (x64) Build ID: f27c4ec5c864395f4cdaec32d7e95ff24e4f43c8 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL
Bug is still there in version LibreOfficeDev_7.1.0.0.alpha1_Linux_x86-64_rpm.tar.gz
In the following version the bug is still there: Version: 7.1.0.0.beta1 Build ID: 828a45a14a0b954e0e539f5a9a10ca31c81d8f53 OS: Linux 5.7; UI render: default; VCL: kf5 Calc: CL
It works in 7.1.1 :-) Thanks a lot!!