Bug 105841 - "First name" in user data is missing
Summary: "First name" in user data is missing
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.3.4
Keywords: needsUXEval
Depends on:
Blocks:
 
Reported: 2017-02-07 19:03 UTC by news.distman
Modified: 2017-05-03 23:34 UTC (History)
7 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 news.distman 2017-02-07 19:03:42 UTC
With libreoffice older than 5.3 I created some templates. This templates use "first name" and also "last name" from the user data. With libreoffice 5.3 these templates are broken. Only last name is used. In Tools > Options > "user data" there is also not anymore two fields for "first name" and "last name". There is only one field "name".

In the documentation it describe the old behavior. Is the single field "name" a new "feature" or a bug?

I upgraded from 5.2.x to 5.3 on Windows with the 64bit version.

https://help.libreoffice.org/5.3/Common/User_Data
Comment 1 Julien Nabet 2017-02-07 20:17:37 UTC
It seems it's been done on purpose considering this commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=db231633af4667e24281e0be69ab63ad3081fdc3
Comment 2 Regina Henschel 2017-04-27 20:31:44 UTC
I reopen it, because I thing removing the "first name" field is an error.

There is a further complain on the German Ask site, read https://ask.libreoffice.org/de/question/93363/5303-benutzerdaten-wieder-umstellen-auf-vor-und-nachname/. The version 5.3 is still "fresh" and likely not often used enterprises. I fear, that there will be more complains, when the 5.3 versions comes to enterprises. 

There are further problems in addition:

Removing the field from UI does not erases it from file format. The  associated element <text:sender-first> exists in ODF (see http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_sender-firstname). It is against interoperability to leave it empty and merge this information into another field.

The service com::sun::star::text::textfield::ExtendedUser has a constant group com::sun::star::text::UserDataPart with value FIRSTNAME. It is published API and should not be changed. Existing macros might not work as intended, if the content of this field is empty.

The variable user_firstname can be used in conditions to hide parts of the text. Such documents no longer work.


I cannot find a request to remove the field or a discussion about the topic. I personally see no considerable reason to remove the "first name" field. I therefore set keyword needsUXEval.
Comment 3 V Stuart Foote 2017-04-27 21:39:08 UTC
@Tor, this is for you to quash or revert... personally I see no reason to revert status quo to return a split First Last, but guess compliance with an ODF 1.2 field as Regina points out would be justification.
Comment 4 Thomas Krumbein 2017-04-28 07:08:00 UTC
It is nessesary to revert the "old" split field - maybe additional to the new one name-Field.

It doesn´t make sense only to change the UX-dialog in Options-Tools but do not change anything else inside the programm code. 

So still both fields (Firstname, Name) are availiable in Dialog "insert text fields", but Firstname is olways empty (no ionput in options possible).

Textfields can be used as condition for conditional text sections and was used in business cases often. Filter is normaly the name field - not the first name.

Fristname and Name is also still used in Dialog adress-data - so the change in Options is completly isolated and produce a lot of problems.

Proposal:
create in option dialog two lines for the name: 
first line : prename , name  - two fields (as done in Versins before 5.3)
second line: one field for name - assign this to the "authors" field with used everytime a concat version of prename + " " + Name.

implement an function to extract either prename /name out of longname-Input or concat prename / name input to generate automatic name/author field in option dialog - equal to the behavior of initials field.
Comment 5 Tor Lillqvist 2017-04-28 07:15:18 UTC
See https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

I am not going to revert anything (unless told to by a client), but anybody else is free to, of course.
Comment 6 Heiko Tietze 2017-04-28 08:42:03 UTC
(In reply to Tor Lillqvist from comment #5)
> See
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-
> names/
> 
> I am not going to revert anything (unless told to by a client), but anybody
> else is free to, of course.

Nice reading and an impressive list of fails. I can follow your reasoning of the patch.
But on the other hand ODF is paramount. So how would you fix the broken Insert > Field > Sender > First Name feature? Thomas' proposal in comment 4 is not a commonly used variant and will likely end up in the mess you tried to solve since concatenation depends on locale.
Comment 7 Tor Lillqvist 2017-04-28 09:46:16 UTC
I would remove that feature, and have only "Insert Name".

But I am joking; most likely I will revert the change despite what I said two comments earlier... It's not as if I cared that much about the thing anyway. I know LO is crap in so many regards, let it be crap also in pretending to know how names of people work.
Comment 8 Commit Notification 2017-04-28 09:58:47 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9416611763a6c6e5bc04a938e909727579716db0

tdf#105841: Avoid REGRESSION!!!

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2017-05-02 13:40:56 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc19bd9224850e8dd8ca873bc86a7e7945f95b08&h=libreoffice-5-3

tdf#105841: Avoid REGRESSION!!!

It will be available in 5.3.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.