View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000920 | Main CAcert Website | account administration | public | 2011-04-10 23:52 | 2015-10-20 20:15 |
| Reporter | Uli60 | Assigned To | Eva | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | needs work | Resolution | open | ||
| Summary | 0000920: error "First and/or last names were blank." conflicts with International Requirements (eg Indonesian Names (Givenname only)) | ||||
| Description | https://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 :) | ||||
| Tags | No tags attached. | ||||
| Reviewed by | Ted, NEOatNHNG | ||||
| Test Instructions | |||||
|
|
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. |
|
|
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". |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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: ... ------------------------------------------------------------------------- |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
# 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 |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 2011-10-20 21:31 | Uli60 | Note Edited: 0002620 | |
| 2011-10-20 21:34 | Uli60 | Note Edited: 0002620 | |
| 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 |
