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
It seems it's been done on purpose considering this commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=db231633af4667e24281e0be69ab63ad3081fdc3
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.
@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.
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.
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.
(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.
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.
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.
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.
Is there a need for a change of naming fields? What's with people with 3 names e.g. in Asian countries? Maybe the name fields should be flexible for the need per localization.