Bug 123918 - Allow user-defined ordering of user-defined document properties
Summary: Allow user-defined ordering of user-defined document properties
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: File-Properties
  Show dependency treegraph
 
Reported: 2019-03-07 07:56 UTC by Ulrich Windl
Modified: 2019-06-13 14:32 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2019-03-07 07:56:16 UTC
User-defined document properties are displayed in the order being entered while the dialog is open. However when being reopened, the entries are sorted (incorrectly) by field name: The sorting seems to use US-ASCII ordering, so that 'Ä' (as in "Änderer") follows 'Z' (as in "Zeitpunkt"), for example.
Therefore a user-defined ordering of user-defined properties is asked for.
That could be a two-step process:
1) Keep the properties in the order they are entered.
2) Provide means to rearrange the property order (e.g. by dragging the lines to the required position
3) Allow usual sorting button (ascending, descending) with a _correct_ sorting function.
Comment 1 Dieter Praas 2019-03-07 13:33:15 UTC
Sounds reasonable to me.
Comment 2 Heiko Tietze 2019-03-11 12:58:06 UTC
Sorting sounds like an overkill to me. You could use 00_Änderung, 01_Zeitpunkt etc. to deal with the current behavior. And perhaps we could also keep the input order.
Comment 3 Ulrich Windl 2019-03-12 10:11:51 UTC
(In reply to Heiko Tietze from comment #2)
> Sorting sounds like an overkill to me. You could use 00_Änderung,
> 01_Zeitpunkt etc. to deal with the current behavior. And perhaps we could
> also keep the input order.

First, the user-defined fields are sorted in the dialog when you want to insert field values, so it makes sense to have a consistent ordering.

Second, adding numeric prefixes to field names just to fix the broken sorting is "ease of implementation", but not "ease of use".
Of course software should be easy to use, not easy to implement.

Finally the fields are sorted already, but with the wrong algorithm, so "Sorting sounds like an overkill to me" is not a valid argument.
Comment 4 Heiko Tietze 2019-03-12 10:26:30 UTC
(In reply to Ulrich Windl from comment #3)
> Second, adding numeric prefixes to field names just to fix the broken
> sorting is "ease of implementation", but not "ease of use".
> Of course software should be easy to use, not easy to implement.

It's a common way to sort files/folders in a certain order. But let's discuss the request in the design meeting.
Comment 5 Thomas Lendo 2019-03-12 19:29:14 UTC
I would support the addition of the sorting button that looks like a burger menu button (2 or 3 horizontal lines). In some dialogs that indicates the possibility to move content between a list of items with this button.

But the manual sorting contradict the automatic sorting. What's with new automatically sorted items after manual changes? How are manuzsorted items "Stuck" at it's position that the user wanted before new automatic sorting?

I'm against any sorting feature with additional buttons like A-Z, Z-A, etc.
Comment 6 Heiko Tietze 2019-03-14 13:24:45 UTC
So let's go with the request. Keep the order as inserted and provide means to sort via up/down buttons right of the dialog. Take care of accessibility.
Comment 7 Heiko Tietze 2019-03-14 13:45:56 UTC
This might be a not so easy but still easy hack.