Bug 168222 - Table sort doesn't consider values represented by fields
Summary: Table sort doesn't consider values represented by fields
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-01 07:37 UTC by lucmat
Modified: 2025-09-01 08:07 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
Example table (13.70 KB, application/vnd.oasis.opendocument.text)
2025-09-01 07:37 UTC, lucmat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lucmat 2025-09-01 07:37:11 UTC
Created attachment 202630 [details]
Example table

When I do a table sort, the values in the fields aren't considered for sorting.
Fields are evaluated as an abstract entity that is ordered before numeric or textual content, also independently from the field's content (apparently just by the order they've been created).

As a field context does appear in a document as the type of content it represents (text, number, date, ...), I would find it logical that reordering a table should reorder how it appears in the document.
What seems illogical, in my personal opinion, is that sorting a table doesn't produce a visually sorted result.

Take the following table as an example, with one header row and five data rows:
----------------------------
Rev.	Date    	Description
‍13	[empty] 	D
12‍	2025-08-28	C
[empty]	[empty] 	X
10	2025-05-14	A
11	2025-07-07	B
----------------------------
The first two lines have the text/numbers "13" and "12" coming from a field expansion, as they're defined in the document's custom properties.

If you try a table sort, ordering as ascending alphanumeric on column 1, there will be no change to it: the fields, whatever they're content, are ordered first. This isn't what I would expect, and I'm sure it isn't what anyone would expect if those were simply text/numeric values.

I found it first in version 25.2.2, but I think it's more by design than a bug, then present in the latest 25.8.1, and I'm quite sure it's been there for a long time.