login bug

services/newAccount.go

@@ -0,0 +1,46 @@
+package services
+
+import (
+	"strings"
+
+	"nearle/models"
+)
+
+// The console's default configuration id.
+//
+// `weblogin` filters on it — `WHERE authname = ? AND configid = ?` — so an
+// account carrying 0 is invisible to the sign-in query however correct
+// everything else about it is.
+const ConsoleConfigID = 1
+
+// PrepareNewAccount fills in the two fields without which an account cannot
+// sign in.
+//
+// Both were left to whatever the caller sent, and the caller is a form that has
+// no reason to know about either. The result was an account that is created
+// successfully, appears in every list, has the right name, email, role and
+// branch — and is refused at the login screen with "we do not recognise that
+// email", because:
+//
+//   - **authname** is what `GetUserLogin` matches on. An account with an email
+//     and no authname is unreachable: nothing on the sign-in path ever looks at
+//     the email column.
+//   - **configid** is ANDed into the same query. Zero matches no console
+//     account, and zero is what an omitted field arrives as.
+//
+// Observed 2026-09-01: a merchant added their own administrator through the
+// console, got a green confirmation, and could not sign in as them.
+//
+// Neither value is ever overwritten. A caller that supplies its own authname —
+// somebody whose sign-in name is not their email — keeps it.
+func PrepareNewAccount(user models.User) models.User {
+	if strings.TrimSpace(user.Authname) == "" {
+		// The email IS the sign-in name everywhere in this console; the form
+		// even labels it "This is how they sign in".
+		user.Authname = strings.TrimSpace(user.Email)
+	}
+	if user.Configid == 0 {
+		user.Configid = ConsoleConfigID
+	}
+	return user
+}