View Issue Details

IDProjectCategoryView StatusLast Update
0000920Main CAcert Websiteaccount administrationpublic2015-10-20 20:15
ReporterUli60 Assigned ToEva  
PrioritynormalSeveritymajorReproducibilityalways
Status needs workResolutionopen 
Summary0000920: error "First and/or last names were blank." conflicts with International Requirements (eg Indonesian Names (Givenname only))
Descriptionhttps://lists.cacert.org/wws/arc/cacert/2011-04/msg00009.html
https://lists.cacert.org/wws/arc/cacert/2011-04/msg00010.html
https://lists.cacert.org/wws/arc/cacert/2011-04/msg00011.html
https://lists.cacert.org/wws/arc/cacert/2011-04/msg00012.html
Additional Information[BH] A friend of mine is Indonesian and she has two names with none of them
is a family name. All her siblings have two totally different names. Her
father has only one single name. If they want to open up a CAcert
account [1], they won't be able, since you need to key in a first and a
family name.
So I checked the "Practice on Names" Page [2] but could not find any
transition. On Wikipedia [3] I read some interesting information how
countries deal with this issue: Either they use a place holder (LNU [4]
(US), Onbekent (NL)) or they double the the given name and use it than
both as first and family name. In Indonesia, official documents only
contain the names given to a person.

[IG] You're probably all aware by now (from ATEs :) of the impact of Assurance Policy's Assurance Statement which creates a balance between the member *in the community* ,and the labels (names) attached *to that member* . This document envisages that western naming conventions and legal assumptions are not universal and may not even be translatable outside the European tradition.

In short there is no difficulty from a policy perspective moving to two given names rather than first & last name.

Implementation however is a different story. The BirdShack team took the view that the name (implementation) field should be a single long string rather than dividing up into first, middle, last, pre-title, post-title, and variations. Then, AP establishes the need for multiple names, so variations are simply additional long strings, and an assurance will award Assurance Points over each long string individually.

Probably what will happen in the future is that the BirdShack idea of one long name string will be incorporated into current software at the same time as the (big) multiple names patch goes through. But that's an issue for Software Team to work through... In their time. Help there is always welcome :)
TagsNo tags attached.
Reviewed byTed, NEOatNHNG
Test Instructions

Relationships

related to 0001100 needs work findings from David 
related to 0001204 new Users table requires enhancement to follow AP definitions regarding names 

Activities

INOPIAE

2011-09-26 10:59

updater   ~0002521

Last edited: 2011-09-26 18:14

View 2 revisions

Solution could be in Line 432 of ../index.php
exchange "||" to "and"
If($_SESSION['signup']['fname'] == "" and $_SESSION['signup']['lname'] == "")

May be the error message in 435 should be adjusted as well, but here I think we could leave the old one for the time being.

In this case the error only occurs if both fields (first name and last name) are empty. This should cover all problems with haveing just one name or an artists name.
The Practice on Names and may be the AP needs to be adjustetd.

Ted

2011-10-08 11:16

administrator   ~0002582

Made some modifications in PracticeOnNames to clarify procedure if no "family name" can be identified.

It already allows names consisting of a single part, see the example "Bushido".

Ted

2011-10-08 11:26

administrator   ~0002583

For simplicity of code I'd say that a single name should go into the lname field, regardless whether it is a given or family name, and the error message should be adjusted correspondingly.

New branch bug-920 created, proposed fix checked in and installed on testserver.

Ted

2011-10-08 11:35

administrator   ~0002584

Last edited: 2011-10-08 12:04

View 2 revisions

Did some quick tests, seems to work as intended:

- Used "Join" on startpage
- All names empty: Error "Last name is blank. If your name consists only of a single part please use the last name field." ==> OK
- Only first name filled out: "Last name is blank. If your name consists only of a single part please use the last name field." ==> OK
- Only last name filled out: Accepted (account bernhard.froehlich@convey.de) ==> OK

- Logged in as Assurer
- Assured account bernhard.froehlich@convey.de
- Checked "My Points", "Assurances you issueed": Target account shown as "Ted" ==> OK

alex

2011-10-12 22:53

reporter   ~0002597

I know this scenario of indonesian names and indeed the given information is correct.

Place holders like "LNU" (probably Last Name Unknown) or "Onbekent" (NL) are not helpful since the name actually consists of only one name. It is different from the identification that some part is unknown. Even worse the scenario to double the name. We will have difficulties in the future when we merge the names to just one string which is - in my opinion - the best solution in this case.

Please check what is filled in into first name field e.g. in Teds case. In my opinion only valid solution is first name must be blank. Then it may be ok, if currently not 100% correct - column is called "last name" - but future-proof.

Uli60

2011-10-19 23:45

updater   ~0002610

Last edited: 2011-10-19 23:59

View 2 revisions

please read the original report =>
Indonesian Names => Givenname only
so moving Givenname into the Surname field is not an option
a givenname is a givenname is a givenname
and not a surname or lastname (!)

To prioritize givenname or lastname from German PoV is to give the lastname higher priority, but moving to the common world PoV the givenname becomes higher priority (see sorting order in email systems)
A German IT admin writes "Cock, Thomas", an US IT admin writes "Thomas Cock"
CAcert is based on common law and is based on an international standard, so the first givenname, 2nd lastname variant is the more precise variant that should be followed.

AO

NEOatNHNG

2011-10-20 19:20

administrator   ~0002618

I have reviewed the changes an they're acceptable per se. There is at least one place where an email starts with "Hi $fname," which will then become "Hi ," but I think that's about acceptable. However there might be more critical places I have overlooked, this needs thorough testing.

Regarding giving the last name more priority than the first name: The sorting order depends highly on your personal feelings and changes heavily from company to company even within countries. AFAIK it's more common to call each colleague by their first name except your boss/higher management that's why often sorting by first name makes sense. Your mileage may vary by the formality of the context.

In western cultures I think there is no exception that when the context is more formal preference is given to the last name. For example you would always say "Mr. Doe" (e.g. for a teacher) "Prof. Dr. Knuth" and "President Obama" or "Chancellor Merkel" instead of "Mr. John", "Prof. Dr. Donald Ervin", "President Barack" or "Chancellor Angela".

Apart from that, the point that a given name is a given name and we maybe shouldn't mix those up may still hold. In that case we could just specify that at least one of them has to be given (there might be countries with only last names) and let the assurers figure out the rest for us. I haven't looked into whether this would cause major problems if the last name is missing somewhere in the system however.

Uli60

2011-10-20 20:48

updater   ~0002620

Last edited: 2011-10-20 21:34

View 4 revisions

create new user:
Givenname:
Lastname: Indonesianboy
email: bug920.user1@
ca-mgr1: set assurer challenge, batch assurance 25 times
login to user bug920.user1@
my details
 - enable my listing
 - location: setting Frankfurt
 - my points: 25 assurances done
logout, login to another user
WoT find assurer:
results in: I

create new user:
Givenname: Indonesianboy
Lastname:
email: bug920.user2@
results in error
Last name is blank. If your name consists only of a single part please use the last name field.

=> fail from my PoV

references to read:
http://en.wikipedia.org/wiki/Given_name
http://en.wikipedia.org/wiki/Mononym#Countries_where_mononyms_are_normal
http://en.wikipedia.org/wiki/Surname


login bug920.user1@
100 assurance points, 50 experience points

new client cert
does not allow to select a name => No Name
E = bug920.user1@...
CN = CAcert WoT User
=> fail

Email rcvd:
-------------------------------------------------------------------------
Hi ,

You can collect your certificate for bug920.user1@... by going to the following location: ...
-------------------------------------------------------------------------

Ted

2011-11-17 23:04

administrator   ~0002704

So, what's the proposal? Should a single name go into fname or is the user free to choose?

BTW, it's hard for me to see the relevance, since on the CAP form, as well as in the Assurance web application it's not possible for an Assurer to decide if a single name is entered in the fname or the lname field!

I'd accept Michael's point that using fname as the compulsary field will save us some (minor) problems elsewhere.

INOPIAE

2011-11-19 07:59

updater   ~0002705

I just tested the creation of a new user with a single name:
Only first name entered => Error message => OK
Only last name entered => Account created => OK

TMS Granted 50 points
Try to create a new certificate, no choice to choose name for certificate
Changed as SE to only first name => accepted => should not be allowed
Try to create a new certificate, no choice to choose name for certificate
Changed as SE to first and last name
Try to create a new certificate, choice for name is given

Try to create an account where first and last name are the same => account created
Should in this case not at least an notification that both entries are the same. I am not quite sure if there is the posibility to hav ethe same first and last name. I know under German law it is not allowed but that not international.

What should be done if we change to any proposal to allow just one name is to point out the users, where to place the single name and that he is only allowed to enter personal data and not company names.

Uli60

2012-01-30 23:37

updater   ~0002812

documentation from Software-Assessment project team meetings Dec 2011, Jan 2012

  1. [[https://bugs.cacert.org/view.php?id=920|bug 0000920]] Join - single name only (eg Indonesian)
   * details under bug number
   * presented to Policy Group
   * first results from policy group?
    * dirk has made some changes in 6.php last year
    * there are 4 possible choices:
     1. givenname
     1. lastname (as current fix)
     1. givenname or lastname
     1. brians proposal, mononym + checkbox
    * dirks proposal:
     * make name handling more AP conform (1 line names, multiple names)
    * 2 possible paths:
     1. allow multiple names (dirks proposal) is massive change (long term change)
     1. "simple" solution (short term change)
    * global re-design
     * eg users view
     * 43.php, multiple views

Uli60

2012-01-30 23:39

updater   ~0002813

# dirk has made some changes in 6.php last year
# there are 4 possible choices:

   1. givenname
   2. lastname (as current fix)
   3. givenname or lastname
   4. brians proposal, mononym + checkbox

# dirks proposal:

    * make name handling more AP conform (1 line names, multiple names)

# 2 possible paths:

   1. allow multiple names (dirks proposal) is massive change (long term change)
   2. "simple" solution (short term change)

# global re-design

    * eg users view
    * 43.php, multiple views

Issue History

Date Modified Username Field Change
2011-04-10 23:52 Uli60 New Issue
2011-09-26 10:59 INOPIAE Note Added: 0002521
2011-09-26 11:00 INOPIAE Status new => fix available
2011-09-26 18:14 INOPIAE Note Edited: 0002521 View Revisions
2011-10-08 11:16 Ted Note Added: 0002582
2011-10-08 11:25 Ted Source_changeset_attached => cacert-devel testserver fbf92ae5
2011-10-08 11:26 Ted Note Added: 0002583
2011-10-08 11:26 Ted Status fix available => needs review & testing
2011-10-08 11:35 Ted Note Added: 0002584
2011-10-08 12:04 Ted Note Edited: 0002584 View Revisions
2011-10-12 22:53 alex Note Added: 0002597
2011-10-19 23:45 Uli60 Note Added: 0002610
2011-10-19 23:59 Uli60 Note Edited: 0002610 View Revisions
2011-10-20 19:20 NEOatNHNG Note Added: 0002618
2011-10-20 19:23 NEOatNHNG Reviewed by => Ted, NEOatNHNG
2011-10-20 20:48 Uli60 Note Added: 0002620
2011-10-20 21:14 Uli60 Note Edited: 0002620 View Revisions
2011-10-20 21:31 Uli60 Note Edited: 0002620 View Revisions
2011-10-20 21:34 Uli60 Note Edited: 0002620 View Revisions
2011-11-17 23:04 Ted Note Added: 0002704
2011-11-19 07:59 INOPIAE Note Added: 0002705
2012-01-30 23:37 Uli60 Note Added: 0002812
2012-01-30 23:38 Uli60 Assigned To => egal
2012-01-30 23:39 Uli60 Note Added: 0002813
2012-01-30 23:39 Uli60 Status needs review & testing => needs work
2013-01-08 06:31 Werner Dworak Relationship added related to 0001100
2013-08-20 19:25 INOPIAE Relationship added related to 0001204
2015-10-20 20:15 BenBE Assigned To egal => Eva