How Customer Portal User Management and Passwords Work

Source: `customer_portal_users_controller.rb`, `customer_portal_user.rb`

• The create-password flow requires a valid, non-expired signup token and the user must not already have a password set; if the token is expired, a new invitation must be sent
• Expired signup links cannot be self-service resolved; support must resend the portal invitation to generate a new token
• The password reset response is deliberately vague ("if an account exists, an email has been sent") to prevent account enumeration attacks
• Password reset reactivates a portal user even if they were previously deactivated -- this is intentional but can be surprising
• Password requirements: minimum 8 characters, must include at least one uppercase letter, must not be a common password, and must not be the same as the username
• Usernames are always lowercased on save and uniqueness is checked case-insensitively
• Portal invitation requires the customer to have an email address on file; if the invitation is sent via SMS, the system checks that the company has sufficient SMS balance

Support scenarios

• "Customer says their signup link expired" → Signup tokens expire and cannot be renewed by the customer. Support must resend the portal invitation from the customer record to generate a fresh token.
• "A deactivated portal user somehow logged back in" → Password reset reactivates the portal user, even if they were previously deactivated. If the user should remain deactivated, deactivate them again after they reset their password, or remove their email to prevent resets.
• "Customer says they didn't get a password reset email" → The reset response is intentionally vague. Check that the username/email matches exactly (usernames are lowercased). Also verify the customer's email address is correct.
• "Customer can't set a password, says it doesn't meet requirements" → Password must be at least 8 characters, include an uppercase letter, not be a common password, and not match their username.