Bug 83196 - TABLE: reference from one table to another is broken, when renaming the table
Summary: TABLE: reference from one table to another is broken, when renaming the table
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Jakub Trzebiatowski
URL:
Whiteboard: BSA target:26.8.0
Keywords:
: 105312 (view as bug list)
Depends on:
Blocks: Fields-Cross-Reference
  Show dependency treegraph
 
Reported: 2014-08-28 14:10 UTC by Oliver
Modified: 2026-06-05 17:58 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
example with 2 table with reference from table2 to cell in table1 (9.92 KB, application/vnd.oasis.opendocument.text)
2014-08-28 14:10 UTC, Oliver
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver 2014-08-28 14:10:58 UTC
Created attachment 105385 [details]
example with 2 table with reference from table2 to cell in table1

Problem description: 
renaming table1 breaks references to other table which refers to table1

Steps to reproduce:
1. create a table and fill in a cell a number
2. create a second table and fill in a cell a reference to the cell with number in table1
3. rename table1

Current behavior:
the reference in table 2 to the cell in table 1 get lost

Expected behavior:
reference to cell in table1 shall refer to cell in renamed table1

Oliver
Operating System: Ubuntu
Version: 4.3.0.4 release
Comment 1 Robert Großkopf 2014-08-28 14:55:52 UTC
I could confirm the bug.

Set the value from the first table to '25'.
Set the cursor in the second table. Changes to '25'.
Connection works.

Put the cursor in the first table.
Chose properties of the table and rename it.
Set the cursor to the second table, where '25' is shown now.
'25' changes to '0', connection to <table1.c3> is shown, which doesn't exist any more.
This doesn't work in any LO-version. 
The first versions up to the first release 3.3.0.1 gives an error:
** Expression is faulty **
This is a little bit better than only writing '0' in a field, where no content could appear.
All other versions will return '0'.
Comment 2 GwenDragon 2014-08-28 15:32:33 UTC
Confirmed for LO 4.2.5.2 Build-ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5 on Windows 7
Comment 3 Alex Thurgood 2014-08-29 08:28:11 UTC
As far as I can remember, this was always so, even in the days of StarOffice, so it might well be that the code path for dealing with this has never existed.
Comment 4 QA Administrators 2015-09-04 02:47:50 UTC Comment hidden (noise)
Comment 5 Buovjaga 2015-11-18 11:02:17 UTC
Still repro.

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)
Comment 6 QA Administrators 2017-01-03 19:35:22 UTC Comment hidden (noise)
Comment 7 Robert Großkopf 2017-01-04 06:50:58 UTC
Bug still exist in 
Version: 5.2.4.2
Build-ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU-Threads: 4; BS-Version: Linux 4.1; UI-Render: Standard; VCL: kde4; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Comment 8 QA Administrators 2018-06-09 02:40:32 UTC Comment hidden (noise)
Comment 9 Robert Großkopf 2018-06-15 06:37:06 UTC
Could reproduce this bug with LO 6.0.5.1 on OpenSUSE 42.3, 64bit rpm Linux.
The second table gives
** Expression is faulty **
when renaming the first table of the Writer-document.
Comment 10 QA Administrators 2019-06-16 02:58:23 UTC Comment hidden (noise)
Comment 11 Robert Großkopf 2019-06-16 06:24:50 UTC
Same buggy behaviour in LO 6.2.4.2 on OpenSUSE 15, 64bit rpm Linux
Comment 12 QA Administrators 2021-06-16 03:56:04 UTC Comment hidden (noise)
Comment 13 QA Administrators 2023-06-17 03:15:25 UTC Comment hidden (noise)
Comment 14 Robert Großkopf 2023-06-17 05:45:29 UTC
Bug still exist in LO 7.5.4.2 on OpenSUSE 15.4 64bit rpm Linux
Comment 15 QA Administrators 2025-06-17 03:10:47 UTC Comment hidden (noise)
Comment 16 Jakub Trzebiatowski 2026-03-28 21:17:49 UTC
I reproduced the issue


1. 
Version: 25.8.3.2 (AARCH64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 10; OS: macOS 15.7.4; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Result: The cell in second table shows "0"

2.
Version: 26.8.0.0.alpha0+ (AARCH64)
Build ID: 8a5f3cc219fb5c2a0c3231e465b9d589b13dc576
CPU threads: 10; OS: macOS 15.7.4; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Result: The cell in second table shows "** Expression is faulty **"

Changing the table name back to its original name doesn't fix the reference, the second table keeps displaying "** Expression is faulty **"
Comment 17 Commit Notification 2026-04-25 09:31:17 UTC
Jakub Trzebiatowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/704fddfae269261cad5eb535c53766ffa0c39a99

tdf#83196 sw: update table formulas on table rename

It will be available in 26.8.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.
Comment 18 Roman Kuznetsov 2026-04-25 14:50:02 UTC
*** Bug 105312 has been marked as a duplicate of this bug. ***
Comment 19 Julien Nabet 2026-05-10 13:21:23 UTC
Jakub: I suppose you won't contribute anymore on LO since you work for Collabora  and there's a conflict between TDF and Collabora but can we put this one to FIXED or is there still remaining work to do here?
Comment 20 Jakub Trzebiatowski 2026-05-11 11:09:47 UTC
(In reply to Julien Nabet from comment #19)
> [...] can we put
> this one to FIXED or is there still remaining work to do here?

This is not done yet. My change addressed the issue only when renaming the table using the table properties dialog. The issue still persists when renaming the table via the UNO API or the Navigator.

The proposed fix is here: https://gerrit.libreoffice.org/c/core/+/204210
Comment 21 Commit Notification 2026-05-11 15:07:13 UTC
Jakub Trzebiatowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1a14d691326f5ae85abf27b4c5148bfa39e5f0e7

tdf#83196 tdf#171784 sw: Single code path for renaming table

It will be available in 26.8.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.
Comment 22 Julien Nabet 2026-05-11 17:09:28 UTC
(In reply to Jakub Trzebiatowski from comment #20)
> (In reply to Julien Nabet from comment #19)
> > [...] can we put
> > this one to FIXED or is there still remaining work to do here?
> 
> This is not done yet. My change addressed the issue only when renaming the
> table using the table properties dialog. The issue still persists when
> renaming the table via the UNO API or the Navigator.
> 
> The proposed fix is here: https://gerrit.libreoffice.org/c/core/+/204210

Thank you for the patch! Since you indicated "for UNO API and Navigator" in the commit, I suppose it's ok now?