Login.ChangePassword() leaves MustChangePassword and IsLocked stale - the property bag is never updated or invalidated

src/Microsoft/SqlServer/Management/Smo/LoginBase.cs から始め、ChangePassword のオーバーロードと ExecuteLoginPasswordOptions を読み、次にそれらの動作を SetMustChangePassword と比較します。記録を伴わない実行が成功した後、影響を受けるキャッシュ済みプロパティを無効化し、同じオブジェクトからの読み取りが、MustChangePassword、IsLocked、IsPasswordExpired、IsMustChange、PasswordLastSetTime、PasswordHash について ALTER LOGIN の結果を反映するようにします。

After a successful Login.ChangePassword(newPassword, unlock: true, mustChange: true), reading login.MustChangePassword on the same object still returns the old value (typically False) until Refresh() is called. The same applies to the other properties the ALTER changes: IsLocked after an unlock, IsPasswordExpired, PasswordLastSetTime, IsMustChange.

This is the same object-cache pattern as #40 (Database.SetOwner() not updating .Owner): a method executes DDL immediately but neither updates nor invalidates the cached properties it just changed on the server.

Repro

$login = $server.Logins["testlogin"]   # SQL login, MustChangePassword currently False
$login.ChangePassword("N3wP@ssw0rd!", $true, $true)
$login.MustChangePassword              # False - stale; the server says otherwise:
# SELECT LOGINPROPERTY('testlogin', 'IsMustChange')  --> 1
$login.Refresh()
$login.MustChangePassword              # True

dbatools carries the workaround with the comment "We need to refresh login after ChangePassword. Otherwise, MustChangePassword will appear as False" (New-DbaLogin.ps1#L610-L611), and its Set-DbaLogin re-reads the login after unlocking for the same reason.

Mechanism

All ChangePassword overloads (LoginBase.cs#L142-L282) end in ExecuteLoginPasswordOptions (LoginBase.cs#L533-L555), which builds ALTER LOGIN ... WITH PASSWORD=... [UNLOCK] [MUST_CHANGE] and runs ExecutionManager.ExecuteNonQuery — and returns. Nothing touches the property bag.

A helper that does update the bag exists — SetMustChangePassword (LoginBase.cs#L334-L347) — but it early-returns unless the object is in design mode, and is only called from Create().

Suggested fix

After a successful non-recording execution, invalidate the affected cached properties so the next read fetches current values from the server — the approach proposed for #40 in PR #231. For ChangePassword that covers at least MustChangePassword, IsLocked, IsPasswordExpired, IsMustChange, PasswordLastSetTime, PasswordHash.

Happy to submit a PR along those lines if that helps.

This was created by Claude and reviewed by Andreas Jordan.