feat(style-editor): Improved empty message

[KevinDavilaDotCMS]

• Added and to manage access to the style editor and permissions tabs based on feature flags and user permissions.
• Introduced to resolve permissions for displaying the permissions tab.
• Updated routing to include guards and resolvers for the new tabs.
• Enhanced component templates to reflect the new tab structure and logic.
• Added unit tests for guards and resolver to ensure correct functionality.

This implementation improves user experience by conditionally displaying tabs based on user permissions and feature availability.

Proposed Changes

• change 1
• change 2

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

** any additional useful context or info **

Screenshots

Original	Updated
** original screenshot **	** updated screenshot **

This PR fixes: #35466

This PR fixes: #35466

[claude]

Claude finished @KevinDavilaDotCMS's task in 2m 17s —— View job

---

PR Review

• Gather context and read changed files
• Review guard and resolver implementations
• Review layout component changes
• Review style editor empty state changes
• Review routing and test coverage
• Post findings

---

Three real issues, one design concern.

1. Unused RouterLink import

dot-uve-style-editor-empty-state.component.ts imports RouterLink in both the import statement and the imports array, but the template uses programmatic navigation via navigateToStyleEditor() — [routerLink] is never used in the template. Dead import that should be removed.

Fix this →

2. onTabChange parameter type (echoing human reviewer)

content-types-layout.component.ts:187:

onTabChange(tab: unknown): void {
    this.$activeTab.set(tab as string);
    this.#router.navigate([tab as string], { relativeTo: this.#route });
}

tab is cast to string twice with no narrowing. PrimeNG's Tabs emits string | number from valueChange. All tabs in this component use string values, so the parameter should be typed string directly. The unknown + double as string suppresses the type checker for no gain.

Fix this →

3. $styleSchemaContentTypeVar may be wrong content type

edit-ema-editor.component.ts:

readonly $styleSchemaContentTypeVar = computed(
    () => this.uveStore.editorActiveContentlet()?.contentlet?.contentType ?? ''
);

This reads from the active contentlet (the one the user has selected/is hovering). When the style editor tab is open and showing the empty state, there may be no active contentlet — e.g., if the user opened the palette without selecting anything. In that case contentType is '', the CTA is hidden, and the user has no action to take. The empty state message would display without a CTA button. That's arguably acceptable, but the empty-state.message i18n string doesn't tell the user how to get the CTA to appear. Worth confirming this is intentional UX.

4. Child routes with no components (design concern)

{ path: 'style-editor', canActivate: [styleEditorTabGuard], children: [] },
{ path: 'permissions', canActivate: [permissionsTabGuard], children: [] },

These routes carry guards purely for URL-based redirect logic; actual tab content is driven by the parent layout component's $activeTab signal. This works, but the contract is invisible: a future developer adding a component to these routes would break the layout (double-render), and the guard redirect logic depends on the URL shape matching what the regex expects. Worth adding a brief comment to the route config explaining the pattern.

---

Otherwise clean. Guard implementation, resolver, regex, and test coverage are all solid.

[KevinDavilaDotCMS]

Response to Claude bot review

Applied #2 (removed dead i18n keys) and #3 (converted to functional ResolveFn).

Skipping the rest:

#1 — Redundant API call: The resolver and guard serve different purposes — the resolver drives tab visibility in the parent template, while the guard protects direct URL access. Collapsing them by reading resolver data from the route snapshot would create tight coupling: if the resolver is ever removed, the guard would silently break. The extra API call is negligible for this path.

#4 — Weak test assertions (not.toBe(false)): The expect(router.parseUrl).toHaveBeenCalledWith(FIELDS_URL) assertion already covers the redirect intent. The not.toBe(false) is harmless redundancy; fixing it is not worth a separate commit.

#5 — Magic string 'permissions': The string appears in exactly two places (guard + resolver, same directory). Extracting it to a constant is not worth the overhead given the scope. If the portlet ID ever changes, both files are trivially discoverable.

#6 — [innerHTML] with HTML in i18n: Pre-existing pattern, acknowledged as low risk by the bot itself. Not introduced by this PR.

[rjvelazco]

Now that we has different route inside the contenttype builder, are we fetching/loading the contenttype schema every time we go back to field?

cc: @KevinDavilaDotCMS

[KevinDavilaDotCMS]

Now that we has different route inside the contenttype builder, are we fetching/loading the contenttype schema every time we go back to field?

cc: @KevinDavilaDotCMS

Yes, since is a route, is fetched every time the user enter