Validation of the client form (node/add/client) is checking the internal name, but flagging the client name.

To replicate, create a client named 'qwerty'. Verify that the auto-generated internal name is also 'qwerty'. Create a second client named 'ytrewq', but manually add the internal name 'qwerty' (intentionally duplicating the first client). The client name is highlighted by the form_set_error, rather than the internal name.

Also, I assume that we want to prioritize uniqueness of internal names, but non-unique human-readable names are problematic as well. For example, the "Associate a client to this user:" auto-complete widget in the user form.

Comments

ergonlogic’s picture

Ok, having looked at this a bit further, I realize I was wrong about the nature of this bug. I think the real issue is that currently, you can create a client with a duplicate human-readable name (title), by manually inputting a unique internal name.

To replicate, create a client named "Ziggy". Verify that the auto-generated internal name is "ziggy". Attempt to create a second client also named "Ziggy". Assuming you've apllied the patch in #1237178: hosting_client_validate_suggest() appears broken You should get: "Client name already in use, try Ziggy0." Now, keeping the client name (title) "Ziggy", add an internal name of "ziggy1". The form will validate and you now have two clients with the same human-readable name.

ergonlogic’s picture

Title: Client form validation broken » Client form validation allows duplicate client names
Assigned: Unassigned » ergonlogic
Status: Active » Needs review

Here's what I've done:
* disabled the internal name field on client creation
* check against duplicate sanitized titles in hosting_client_validate()
* added a check of hosting_get_client_by_uname() in hosting_client_update()

I've committed this to my dev repo: http://drupalcode.org/sandbox/ergonlogic/1226310.git/commit/f6f9a7532778...

steven jones’s picture

Status: Needs review » Needs work

Hmm...I think I like the approach, but just disabling the field and not letting the user know that we're doing this on purpose seems a bit odd to me. Could we change the description to let the user know that we're going to autogenerate the internal name the first time, and they can change it later.

ergonlogic’s picture

Status: Needs work » Needs review
ergonlogic’s picture

Status: Needs review » Needs work

I think we'll need to explicitly check for duplication of $node->title... Changing the client prefix allows for the creation of duplicate human-readable client names (titles).

steven jones’s picture

#4 is looking better.

Yeah, it'll be a bit weird if we have mulitple clients with the same name anywhere. There are modules that do this already, but I suspect they are mostly UI code, so we could steal the useful parts of one of those, or just roll our own?

anarcat’s picture

Maybe we could make the autocomplete forms look at the internal name instead of the client name? Or look at both but enter the internal name in the field?

ergonlogic’s picture

Version: 6.x-1.2 » 6.x-2.x-dev
Status: Needs work » Fixed

Fixed in f699566.

anarcat’s picture

Status: Fixed » Needs work

i am not sure I like this infinite loop:

-function hosting_client_validate_suggest($node) {
+function hosting_client_validate_suggest($name, $internal = FALSE) {
   $suggestion = FALSE;
-  for ($i = 0; $i < 10; $i++) {
-    $nid = db_result(db_query("SELECT nid FROM {hosting_client} WHERE uname LIKE '%s%%'", addcslashes(hosting_client_sanitize($node->title) . $i, '\%_')));
+  $table = $internal ? 'hosting_client' : 'node';
+  $field = $internal ? 'uname' : 'title';
+  $name = $internal ? hosting_client_sanitize($name) : $name;
+
+  $counter = 0;
+  while (TRUE) {
+    $nid = db_result(db_query("SELECT nid FROM {%s} WHERE %s = '%s'", $table, $field, $name . $counter));
     if (!$nid) {
-      $suggestion = $node->title . $i;
-      break;
+      return $name . $counter;
     }
+    $counter++;
   }
-  return $suggestion;
 }

the reason this was breaking after 10 attempts was that we had a ceiling of 10 requests to check suggestions. we could raise that by a few order of magnitudes if you want, but think about it: if we set the limit to 1000 requests, that means that there will be 1000 SQL requests for a single HTTP query - that's huge, and that's if the limit is at 1000. If there's no limit (as the patch does), we could simply DOS the MySQL server.

Also, don't return in function hosting_client_validate(). We want to validate all fields so that the user sees all the error in the form in one shot, and not have to fix one error, submit the form, fix the other error, submit the form, etc.

ergonlogic’s picture

Status: Needs work » Fixed

Fixed in 1fc8aa1

anarcat’s picture

Status: Fixed » Needs work

fatal: ambiguous argument '1fc8aa1': unknown revision or path not in the working tree.

ergonlogic’s picture

Status: Needs work » Needs review

Rebase messed with me. Try a27c73059

anarcat’s picture

Status: Needs review » Needs work

sorry to be picky, but please bring back the for (;;) loop :)

ergonlogic’s picture

Status: Needs work » Fixed

Fixed in 60b5918.

anarcat’s picture

good, thanks.

anarcat’s picture

Project: Hostmaster (Aegir) » Hosting

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit f699566 on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by ergonlogic:
    Issue #1238618: Fix client form validation.
    

  • Commit f699566 on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by ergonlogic:
    Issue #1238618: Fix client form validation.