configuration.move_name_taken

A constant jadpo config move was asked to make a setting has the name of a setting config { } already declares.

Area 14, Tools; not declinable; the next step is usually the agent's.

Why Jadpo refuses it

jadpo config move <constant> adds a setting of the constant's name and rewrites every read to config.<name>. When config { } already has a setting of that name, the two would be one name for two values, and reads that meant the constant would start reading the setting. Which of them should keep the name is a choice about what the code means, so the move is refused and nothing changes.

What it looks like

config.jadpo already has a max_login_attempts, for the admin site:

config.jadpo:

use accounts/types { LoginAttempts }config {    /// Failed sign-ins to the admin site before an account is locked.    max_login_attempts: LoginAttempts {        default: 3    }}

jadpo config move security.max_login_attempts

  |5 |     constant max_login_attempts: LoginAttempts = 5  |              ^^^^^^^^^^^^^^^^^^ a setting has this name

(agent) at the end of the next: line means your coding agent can make the fix itself.

How to fix it

If the setting is the admin site's own, give it a name that says so, then move the constant:

config {    /// Failed sign-ins to the admin site before an account is locked.    admin_max_login_attempts: LoginAttempts {        default: 3    }}

jadpo config move security.max_login_attempts

A deployment then sets the two apart, as ADMIN_MAX_LOGIN_ATTEMPTS and MAX_LOGIN_ATTEMPTS.

If both should be one value, delete the constant, and the library it leaves empty, and read the setting instead:

action sign_in(failed_attempts: LoginAttempts) -> AccountLocked {    return AccountLocked(failed_attempts >= config.max_login_attempts)}

Every sign-in, to the app or the admin site, is then locked after the setting's number of attempts.

Related

• Making a constant a setting
• jadpo config move