Allow for change of registry lock passwords in User objects

[gbrodman]

This essentially enables the "forgot password" flow

---

This change is 

[ptkach]

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @gbrodman)

---

core/src/main/java/google/registry/tools/UpdateUserCommand.java line 30 at r1 (raw file):

public class UpdateUserCommand extends CreateOrUpdateUserCommand {

  @Parameter(names = "--remove_registry_lock_password", description = "Removes the registry ")

Should we replace it with more broad - update_password, which can be used to remove as well, by providing an empty string

[gbrodman]

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @ptkach)

---

core/src/main/java/google/registry/tools/UpdateUserCommand.java line 30 at r1 (raw file):

Previously, ptkach (Pavlo Tkach) wrote…

Should we replace it with more broad - update_password, which can be used to remove as well, by providing an empty string

I don't think so, because then it allows support to change things that maybe they shouldn't be able to change. This is clearer for sure

[ptkach]

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @gbrodman)

---

core/src/main/java/google/registry/tools/UpdateUserCommand.java line 30 at r1 (raw file):

Previously, gbrodman wrote…

I don't think so, because then it allows support to change things that maybe they shouldn't be able to change. This is clearer for sure

it can be put behind the check for user role or admin flag or both

[gbrodman]

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @ptkach)

---

core/src/main/java/google/registry/tools/UpdateUserCommand.java line 30 at r1 (raw file):

Previously, ptkach (Pavlo Tkach) wrote…

it can be put behind the check for user role or admin flag or both

No, we don't have a way of injecting the user running the command into the command itself unfortunately.

But either way, eh we can do this.

[ptkach]

Reviewed 2 of 3 files at r2, all commit messages.
Reviewable status: 2 of 3 files reviewed, 2 unresolved discussions (waiting on @gbrodman)

---

core/src/main/java/google/registry/tools/UpdateUserCommand.java line 43 at r2 (raw file):

        checkArgumentPresent(
            tm().loadByKeyIfPresent(VKey.create(User.class, email)), "User %s not found", email);
    if (!removeRegistryLockPassword && registryLockPassword == null) {

do you think that executeInTransaction from CreateOrUpdateUserCommand.java might be a better place for applying the updates, comparing to getExistingUser method?

[gbrodman]

Reviewable status: 2 of 3 files reviewed, 2 unresolved discussions (waiting on @ptkach)

---

core/src/main/java/google/registry/tools/UpdateUserCommand.java line 43 at r2 (raw file):

Previously, ptkach (Pavlo Tkach) wrote…

do you think that executeInTransaction from CreateOrUpdateUserCommand.java might be a better place for applying the updates, comparing to getExistingUser method?

It's a bit awkward but sure

[gbrodman]

friendly ping

Reviewable status: 1 of 4 files reviewed, 2 unresolved discussions (waiting on @ptkach)

[ptkach]

Reviewed 4 of 4 files at r4, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @gbrodman)

---

core/src/main/java/google/registry/tools/CreateOrUpdateUserCommand.java line 117 at r4 (raw file):

      } else {
        checkArgument(
            user != null && user.getRegistryLockEmailAddress().isPresent(),

good catch that we need to check both param and existing user.