mirror of
https://github.com/google/nomulus.git
synced 2025-08-04 08:52:12 +02:00
d32b52d3a2
* Don't destroy existing registry lock passwords in contacts The existing code assumes that the "contacts" segment of the form contains an exact representation of the registrar contacts. This breaks when we have a contact with an existing registry lock password because we don't want to keep passing around that password in plain text (we never store it in plain text) This PR changes the code so that instead of assuming the contact is provided in its entirety, we load the contact from storage first (matching by email address) if it exists. We then set the required fields from the JSON object, and set the password optionally if it was provided. Alternatives: - Create a separate RegistrarContactPassword object with a RegistrarContact parent. This increases complexity significantly since we'd be adding a parent-child relationship and adding more objects to Datastore during the transition to SQL. It also doesn't completely solve the problem of "When should we set the password?" because the password field still must be part of the same form. - Rearrange the UI so that the password is set as part of a completely separate form with a separate submit action. This would be possible but is sub-optimal for two reasons. First, we are trying to not re-engineer the web console as much as possible since we're likely starting it from scratch before too long anyway. Second, we want the lock-password-setting to be part of the standard contact modification workflow. * Responses to CR * Actually we need to allow "removal" of fields * Remove optional * one-statement building the contacts |
||
|---|---|---|
| .. | ||
| gradle/dependency-locks | ||
| src | ||
| build.gradle | ||
| Dockerfile | ||