Created attachment 77792 [details] Example of Release 4 not returning External Data on a Web Page Spreadsheet does not return external data that is linked to a web page. Specific information is contained in the attached spreadsheet.
Effect is [Reproducible] with reporter's sample and server installation of "LibO 4.0.2.2 rc - German UI / German Locale [Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3)]" {tinderbox: @6, pull time 2013-03-26 12:00(?)} on German WIN7 Home Premium (64bit) with newly created own user profile. LibO 3.6.6.2 updates the contents with out problems, so it seems to be a regression. Some more research required, I will do that later
Some first quick tests seem to show that this is not a general problem, some of my documents collecting data from Bugzilla Tables work fine with WIN LibO 4.0.2.2
@ Rainer - should we mark this as NEW since you reproduced with Chad's file?
Additional new test results: With LibO 4.0.2.2 rc - German UI / German Locale [Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3)]" {tinderbox: @6, pull time 2013-03-26 12:00(?)} on German WIN7 Home Premium (64bit) with newly created own user profile II get the "The link could not be updated." Message when I try to insert the contents into a brand new empty document. Already reproducible with reporter's sample and 4.0.0.3 @Joel (In reply to comment #3): I intendedly did not move from new, because we are far away from having all info QA can contribute in the bug. At least we should find out a) when did that start? b) also Linux effected? If yes, a bibisect might be useful c) Is that also an effect with reporter's document or does the problem for the same linked contents (due to my test: independent)? d) is the problem related to particular settings (language detection, number detection, whatever else, update frequency? Current status due to my tests: independent)? Although it might be much more easy for a developer: A) Why is that particular contents affected, but not all from all sources? Se my attached sample I think we need some general thinking about our proceeding between first confirmation that the bug exists and the forwarding to developers, what might be a part of your thoughts concerning "more structured QA-work". May be we should have some tags showing the QA status, "Failed to reproduce ... reproduced ... still some research to be done ... only confirmation with a second OS required ... ready for bugfixing". But we should not discuss that here in the bug, but in a thread on QA list. @Chad Do you have any idea what on <http://portfolios.morningstar.com/fund/summary?t=VTI> might cause the problem for LibO 4?
indeed, reproducible on Bodhi Linux 4.1 master pulled today. Bibisecting now
Created attachment 77836 [details] This document is not affected The question is: why?
5dddcff8ae35692d89751ae98ab8acbbf802b5b4 is the first bad commit commit 5dddcff8ae35692d89751ae98ab8acbbf802b5b4 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 05:22:26 2012 +0000 source-hash-d85fd8a85501547d5bb87822d2589a07aed7f2d6 commit d85fd8a85501547d5bb87822d2589a07aed7f2d6 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Wed Nov 21 12:41:41 2012 +0100 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Wed Nov 21 12:41:41 2012 +0100 Fix install-gdb-printers for Mac OS X Change-Id: I685d277806e757fc6247f34d4db7386955dab7b7 :100644 100644 99e65e2d132b0f467d52718cb5574bbd276b84c5 03a040999f63a580a1509f0d908fa9a9f149fad1 M autogen.log :100644 100644 d1dffcac5e20f137981a1ee53d82819296660d8f 760e368a7df5a07687a83c81a51e73bb80c62ceb M ccache.log :100644 100644 e90409ec8ead05c8fe982311c4fad9412f935b8b 88657431c9c9c0aa14b8c93c720e3c6b5222d64a M commitmsg :100644 100644 76efee933474fa0d7569b3e6f0943d3bd9dc876a 793e45124d193a35b8925402bda4e8f14e9dba8c M dev-install.log :100644 100644 3891157aa7844c43f80ea5b431309453836479b8 54ed0708af49cfca9bbbe4c60484adbb1f3628f1 M make.log :040000 040000 5522d7515450a2abddaca0ef2d8c2d6e5d03572a 8e2ebefc6e5ba8a91bf16e7cdef72824536b4fb0 M opt # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262 # good: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 git bisect good 47498a36f7af8f54e6e3dda89cd4708802a409e6 # bad: [66083171ba534818399937597388d325091fffab] source-hash-9d83ad0e99ab182506be99f7d6a2bec7f6fbe8c6 git bisect bad 66083171ba534818399937597388d325091fffab # bad: [5dddcff8ae35692d89751ae98ab8acbbf802b5b4] source-hash-d85fd8a85501547d5bb87822d2589a07aed7f2d6 git bisect bad 5dddcff8ae35692d89751ae98ab8acbbf802b5b4 # good: [915b1e16f20d5ce2a32f911ef051103455600845] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74 git bisect good 915b1e16f20d5ce2a32f911ef051103455600845 # good: [b17eb9ea515cf4b5bf60dd2b6860febf0806a9bd] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73 git bisect good b17eb9ea515cf4b5bf60dd2b6860febf0806a9bd
Due to Joels bibisect this seems to be a 4.0 Master bug I think remaining questions can be clarified by a developer much more effective than by users, so NEW. @Spreadsheet Team Please change Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC).
Created attachment 77887 [details] Additional tests of the External Data problem I ran some additional tests and could get to the data using a different selection on the External Data page. The "Additional Testing" steps I used are at the bottom of "The Problem" tab. Hope this helps.
*** Bug 60672 has been marked as a duplicate of this bug. ***
*** Bug 61587 has been marked as a duplicate of this bug. ***
*** Bug 59762 has been marked as a duplicate of this bug. ***
*** Bug 62714 has been marked as a duplicate of this bug. ***
Hi, French users found that the link is case sensitive with version 4. Range names containing lower cases are not recognised, this confirms what has been described in duplicate although earlier bug 61587 (eg in attachment 75824 [details], replace Months with MONTHS and the link is again active)
(In reply to comment #14) > Hi, > French users found that the link is case sensitive with version 4. Range > names containing lower cases are not recognised, this confirms what has been > described in duplicate although earlier bug 61587 (eg in attachment 75824 [details] > [details], replace Months with MONTHS and the link is again active) So this is just a duplicate of the other two bugs?
Hi How is possible to know if this bug has been taken up for development i.e. change and testing? It's been more than 3 months since being reported (bug 61587) and so far there's been only some back and forth. Bug 61587 was closed as RESOLVED since it was made a duplicate of this one. So, where are we in terms of resolution of the real problem i.e. non-updation of external links? The example file given with 61587 shows clearly that the problem can be replicated by changing range names from lower case to Upper case. But that's not going to help people who have many existing worksheets which will suddenly stop working. This is going to hurt Libre Office adoption and it's image. Thanks for providing a quick fix guys. KSN
(In reply to comment #16) > Hi > > How is possible to know if this bug has been taken up for development i.e. > change and testing? It's been more than 3 months since being reported (bug > 61587) and so far there's been only some back and forth. Bug 61587 was > closed as RESOLVED since it was made a duplicate of this one. The bug was fixed already as Bug 64031. > > So, where are we in terms of resolution of the real problem i.e. > non-updation of external links? The example file given with 61587 shows > clearly that the problem can be replicated by changing range names from > lower case to Upper case. But that's not going to help people who have many > existing worksheets which will suddenly stop working. > > This is going to hurt Libre Office adoption and it's image. These comments don't help motivating developers to work on these bugs.
Sorry, Markhus No intention to hurt anyone's feelings. I really appreciate the work being done by the Libre Office team. I actively promote the usage of Libre Office within my organisation and wasn't aware that the problem had been solved via Bug 63401, since there was no update to Bug 63407 or Bug 61587 showing the problem had been solved. Thanks for the update, Markhus. Since I am relatively new to the patch release process and it's deployment to a full version, how can one get this patch to work in the release that I am using? Once again no intention to hurt feelings and apologies from my side if you'll felt bad. Regards KSN
(In reply to comment #15) > (In reply to comment #14) > > Hi, > > French users found that the link is case sensitive with version 4. Range > > names containing lower cases are not recognised, this confirms what has been > > described in duplicate although earlier bug 61587 (eg in attachment 75824 [details] > > [details], replace Months with MONTHS and the link is again active) > > So this is just a duplicate of the other two bugs? Not sure. The other was for link for another local file, this one is related to web page. I will test when a build with the fix will be available. (tomorow or later)
Tested with Version: 4.2.0.0.alpha0+ Build ID: 526fbddf6935b0a3983563af71c4ccea4561ceb TinderBox: Win-x86@6, Branch:master, Time: 2013-05-30_00:05:37 I've made a test with 2 of my files and with attachment of this report. Also with attachment bug 61587. Links are updated.
Hi Is the build also available for Linux? If so, which is the build number? Thanks KSN (In reply to comment #20) > Tested with Version: 4.2.0.0.alpha0+ > Build ID: 526fbddf6935b0a3983563af71c4ccea4561ceb > TinderBox: Win-x86@6, Branch:master, Time: 2013-05-30_00:05:37 > > I've made a test with 2 of my files and with attachment of this report. > Also with attachment bug 61587. > > Links are updated.
(In reply to comment #21) > Hi > > Is the build also available for Linux? If so, which is the build number? > You can pick any of the recent daily builds from http://dev-builds.libreoffice.org/daily/ for master, 4-1 or 4-0 branch. All builds after later than May, 28th should contain the fix. If it is fixed please mark this bug report as duplicate of Bug 64031.
So, is this fixed for updates of web pages in a recent 4.0.x or 4.1.x build?
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
I'll mark this resolved per Comment 20 (and also the fact that there has been no reply to Comment 23 for the past 4 months).
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/59fa93d128a5363f3e7d6f75e71457261ea6f1d7%5E%21 crashtesting: assert on export of fdo63407-3.ods to xls It will be available in 6.4.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/778359cceebb5aa60db05a44106868e855b6fcfc%5E%21 crashtesting: assert on export of fdo63407-3.ods to xls It will be available in 6.3.0.2. 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.