Site or Folder field: default location from role/user attribute + remember last-selected location within session

Description

As a content contributor who works primarily within one folder (e.g. my department's tree), I want new content to default to a sensible location for me — declared by an admin and/or remembered from what I last used — instead of always opening at the site root, so I spend less time navigating and place content correctly on the first try.

Background / Problem

The Site or Folder field currently defaults to the site root (when the field is required) or System Host (when it isn't), regardless of where the saving user has permissions. On sites where contributors are scoped to specific folders, this produces two recurring problems:

Repetitive navigation. Contributors must manually navigate to their folder on every new content item, even when they only ever work in one place. This is the same friction described in #19972 (option 1: "Have dotCMS remember the last selected folder"), which was scoped to Image/File fields and never implemented for the Site or Folder field.

Accidental root saves. Contributors forget to change the field, save at root, and — depending on permissions — either lose access to their own content (lockout) or place it outside the folder-scoped pages/feeds it was written for.

Note on the lockout: the accidental-save lockout itself is not a defect. As verified with a customer, when a role's Add Children permission is correctly scoped (i.e. the role does not have Add Children at the host root), dotCMS correctly blocks the save with "User has no Add Children Permissions on selected host". The lockout the customer reported was caused by a role that had Add Children but not Edit inherited at the host root. Permissions behave as designed; this enhancement is about the default-location experience, not the permission check.

Suggested Solution

A hybrid default-location behaviour for the Site or Folder field, combining an admin-declared default with in-session memory. Product owns the final implementation approach; the following describes the requested behaviour:

1. Optional "Default content location" attribute on role and/or user.

• Empty by default → exactly today's behaviour; no change for anyone who doesn't opt in.
• When set → the Site or Folder picker opens at that location for new content, instead of the site root / System Host.
• It is a default, not a restriction — the field stays fully editable, and existing permission checks still govern what is actually save-able.
• No system-maintained mapping and no inference: the location is declared explicitly by an admin. A stale value fails soft — the picker opens somewhere unhelpful and the user navigates, which is the current status quo for every user.
• Conceptually the same shape as the per-content-type defaultPath field variable (#30713), resolved from the saving user's role/user rather than fixed per content type.

2. In-session memory of last-selected location.

• After the user selects a location, that selection is remembered for the duration of their session and used as the default for subsequent new content.

Hybrid behavior: the admin-declared default is always the starting point (e.g. on a new login); once the user selects a folder, session memory takes over and sticks to the last-selected location until they change it again within that session. If no default is set and nothing has been selected yet, current default behavior applies.

How this aligns with the customer's goal

Combined with correctly scoped permissions — which restrict save-able locations to the user's own folder, confirmed working by the customer — the admin-declared default lands a contributor on their own folder from the start, session memory removes repeat navigation, and the existing permission check remains the safety net against misplacement. Together these deliver the practical benefit of a per-user default without a system-maintained mapping.

Open Design Questions (for Product)

• Does in-session memory persist across logout, or is it strictly per browser session?
• Is the remembered location tracked per content type, or shared across all content types?
• Should the default attribute live on role, user, or both — and if both, what is the precedence order?

Acceptance Criteria

• An optional default-location attribute can be set on a role and/or user; when unset, current behavior is unchanged.
• When set, the Site or Folder field opens at the declared default for new content (provided the user has View permission on it).
• Within a session, after the user selects a location, that selection becomes the default for subsequent new content, overriding the declared default until changed.
• If a declared default or remembered location is no longer valid/viewable, the field falls back gracefully (to the other mechanism, then to current default behavior) without error.
• None of this overrides permission enforcement — saving into a location the user lacks Add Children on is still blocked as it is today.

Priority

High

Additional Context

FD ticket: https://dotcms.freshdesk.com/a/tickets/38368

Alternatives Considered

• System-inferred / system-maintained per-user default (rejected). Having the platform automatically determine or maintain each user's default folder — this is the version that carries maintenance-at-scale and ambiguity concerns. The suggested solution deliberately avoids this by making the attribute opt-in and admin-declared.
• Per-content-type defaultPath field variable. Covered by #30713, closed without an implementation shipping; per-type rather than per-user, so it can't serve multiple departments sharing the same content types.

No source files or tests are named. Start by locating the Site or Folder field and the new-content initialization path, then trace how role or user defaults, session memory, and permission validation are represented. Done means the acceptance criteria hold, including graceful fallback and unchanged permission enforcement.