Merge-up: Merge v17/dev into main

[iOvergaard]

Description

Merges v17/dev into main. It brings two PRs:

• Password reset: Report an unconfigured application URL before the user lookup and always apply the minimum response time #24152 Password reset: report an unconfigured application URL before the user lookup, always apply the minimum response time. Merges cleanly.
• Content Types: Refresh composing types when a property is added to a composition (closes #24117) #24126 Content Types: refresh composing types when a property is added to a composition (closes Property added to a composition reads as empty on composing document types until restart (ModelsMode Nothing) #24117). It needs resolving, so @AndyButland, I'd appreciate your review of the points below.

1. ContentTypeServiceBase.ComposeContentTypeChanges

main has reworked change detection into granular change types (PropertyAdded, AliasChanged, …). The resolution keeps that model for the saved content type. It replaces the old one-level GetComposedOf propagation with #24126's transitive one (GetDirectReferencingTypes / GetComposedOfTransitive, with the lookup built once per batch):

• Main-impact changes: deriving types get RefreshMain and share the rebuild requirement, as before.
• A property addition or a content type alias change: deriving types now get RefreshOther, as in Content Types: Refresh composing types when a property is added to a composition (closes #24117) #24126.

Question: should deriving types get the granular PropertyAdded instead of a plain RefreshOther? Nothing in core checks PropertyAdded specifically, so for core they behave the same, and I kept #24126's choice.

2. ContentCacheRefresher

#24126 adds a constructor taking IPublishedContentTypeCache. On 18 that constructor has the same length as the obsolete one taking both IPublishStatusManagementService and IDocumentPublishStatusManagementService. Both can be satisfied by the container, so it throws "constructors are ambiguous" at startup. I tried this: 187 integration tests failed. [ActivatorUtilitiesConstructor] doesn't help, because the container resolves the refresher by type.

So on main the constructors are unchanged, and the cache is resolved lazily through StaticServiceProvider the first time a "refresh all" needs it, with a TODO (V19). On v19/dev, which has a single constructor, it will be injected normally when this goes up.

3. Tests adapted to 18

• DocumentHybridCacheDocumentTypeTests.Batch_Save_Reports_A_Single_Change_For_A_Type_Deriving_From_Several_Saved_Types used the synchronous batch Save, which doesn't exist on 18. It now saves each composition with UpdateAsync and classifies both in one ComposeContentTypeChanges call, the same pattern as the existing alias-rename test in that file. The assertion is unchanged.
• ContentCacheRefresherIdKeyMapTests goes back to main's constructor.
• In Content Types: Refresh composing types when a property is added to a composition (closes #24117) #24126's three new ContentTypeEditingServiceTests, the saved content type now expects main's granular flags (PropertyAdded, PropertyVariationChanged, PropertyRemoved | RawDataUnaffected) instead of v17's RefreshOther / RefreshMain. The deriving types' expectations are unchanged and pass as written.

How to test

All of the following pass:

• Unit tests: ContentCacheRefresher*, EnsureMinimumResponseTimeFilterTests, UriProviderTests.
• Integration tests: PublishedContentTypeCacheTests, ReloadPublishedCacheTests, ContentTypeEditingServiceTests, DocumentHybridCacheDocumentTypeTests, UserServiceCrudTests, ContentTypeServiceTests.

Merge with a merge commit (not squash), so v17/dev stays an ancestor of main.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[claude]

Claude finished @iOvergaard's task in 1m 12s —— View job

---

PR Review

Target: origin/main · Based on commit: 643da950

Merge-up of v17/dev into main. It brings in #24152 (password reset: config checked before the user lookup, minimum response time always applied) and #24126 (deriving content types refreshed transitively when a composition changes), with conflicts resolved against main's granular ContentTypeChangeTypes.

• Modified public API: IForgotPasswordUriProvider.CanCreateForgotPasswordUriAsync(), a new member with a default implementation and a TODO (V19) (§6.3 pattern).
• Other changes:
  • Forgot-password returns ApplicationUrlNotConfigured before the user lookup, so the result is the same for every email.
  • The minimum response time is now applied even when the remaining wait is under 1 µs (fixes the old forceWait.Microseconds > 0 component check).
  • Adding a property, or changing a content type's alias, now sends RefreshOther to all types deriving from it, at any depth.
  • Main-impact changes now propagate RefreshMain transitively instead of one level deep.
  • A "refresh all" ContentCacheRefresher payload now clears IPublishedContentTypeCache.

---

Resolution check

• ComposeContentTypeChanges: The resolution is correct.
  • The saved type keeps main's granular flags.
  • When a main-impact change propagates, deriving types still join rebuildRequiredIds / rawDataUnaffectedCandidateIds, so the Id-keyed RawDataUnaffected resolution at the end still covers them.
  • The lookup is built once per batch, which is cheaper than main's per-type GetComposedOf → GetAll().
  • Moving the propagation below the non-structural block is safe, because AddChange ORs the flags.
• On question 1 (PropertyAdded vs RefreshOther for deriving types): Nothing under src/ checks PropertyAdded, AliasChanged, CompositionAdded or PropertyAliasChanged outside the producer, so the two are equivalent for core.
  • RefreshOther is arguably the more accurate contract. The granular flags describe what happened to that type's own definition, and the deriving type's definition didn't change.
  • It also doesn't regress anything: on main, deriving types got no entry at all for a property addition.
  • Keeping Content Types: Refresh composing types when a property is added to a composition (closes #24117) #24126's choice looks right to me.
• ContentCacheRefresher: The lazy StaticServiceProvider resolution with a TODO (V19) is a pragmatic way around the constructor ambiguity, and it is only reached on RefreshAll.
  • None of the unit tests that construct the refresher send a RefreshAll payload, so they don't depend on StaticServiceProvider.
  • ContentTypeCacheRefresher / DataTypeCacheRefresher already inject the same cache, so the service is always registered.
• Tests: The adapted expectations match main's semantics.
  • The new ReloadPublishedCacheTests sidesteps the no-op messenger false-green (per tests/Umbraco.Tests.Integration/CLAUDE.md).
  • It also checks that a cache hit returns the same instance, so the "not same" assertion actually tests the clear.

No Critical, Important or Suggestion findings, so there are no inline comments.

Labels: I added category/api because Management API files changed. area/backend was already on the PR.

---

Approved

This looks good to be merged as-is, but please do a manual sanity check and testing before merging. (Use a merge commit, as noted in the description.)

[sonarqubecloud]

Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
16.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud