Description

When you open a content type in the Content Types editor and then go to Content Search, Content Search opens already filtered to that type. Content Drive doesn't do this, so after editing a type you have to pick it again in the Drive's filters.

How Content Search does it today (server side):

• Fetching a content type through GET /api/v1/contenttype/id/{idOrVar} saves its inode in the HTTP session as selectedStructure (ContentTypeResource.java, retrieveContentType).
• Content Search pre-selects that type when it opens without a ?filter= param (ViewContentletAction.resolveStructureSelected).
• Content Search's first search then removes the value from the session (ContentletAjax.java, searchContentletsByUser), so it's a one-time handoff. Reloading Content Search afterwards shows All.
• No REST endpoint returns that session value, so the Drive can't read it.

Proposed approach (frontend only):

• When the content type editor opens an existing type (dot-content-types-edit-resolver.service.ts), save the type's variable name to sessionStorage.
• When the Drive loads and its URL has no filters param, apply contentType:<variable> and clear the saved value right away.
• The Drive already keeps its filters in the URL (?filters=contentType:Blog), so after the handoff, reloading the page keeps the filter until the user clears it.

Other screens that fetch content types (Edit Content and others) don't change the value. Only the content type editor sets it, so the Drive gets "the last type I worked on," not "the last type any screen loaded."

Acceptance Criteria

Happy path

• Open an existing content type (for example Blog) in the Content Types editor, then open Content Drive from the menu: the Drive shows the Content Type filter set to Blog and the grid lists only Blog content.
• Create a new content type and save it, then open Content Drive: the Drive is filtered to the new type.
• After the Drive applies the filter, the URL contains filters=contentType:<variable>, and reloading the page keeps the filter.
• Open a folder link (URL with path and no filters) right after opening a type in the editor: the Drive opens that folder with the type filter applied.

One-time handoff

• After the Drive applies the type, clear the filter, then leave the Drive and open it again from the menu: the Drive opens with no content type filter.
• Opening a second type in the editor (for example News after Blog), then opening the Drive: the Drive is filtered to News, not Blog.

Does not override explicit filters

• Open a Drive URL that already has a filters param (for example filters=baseType:4) after opening a type in the editor: the Drive applies only the URL's filters, and the saved type is not applied.

Only the editor sets the value

• Opening a contentlet in Edit Content (which also fetches its content type), then opening the Drive: the Drive opens with no content type filter.

Storage lifetime

• The saved value lives in sessionStorage, so it's per tab: opening a type in the editor in tab A, then opening the Drive in a new tab B: tab B's Drive has no content type filter.
• Logging out removes the saved value, next to the existing experiments key cleanup in LoginService (clearExperimentPersistence).

Edge cases

• If the saved type was deleted, or the user has no permission on it, by the time the Drive opens: the Drive loads without an error message, the saved value is cleared, and the grid behaves as it does with an unknown content type in the URL.

Priority

Low

Additional Context

• Investigated and tested locally: with a type opened in the editor, Content Search pre-selected it, and one reload later it showed All.
• DotSessionStorageService in libs/data-access only handles the experiments variant id (its TODO says it needs a real name). Either extend it with get/set/remove for this key or add a small Drive-specific helper; don't call sessionStorage directly from components.
• Out of scope: changing how Content Search behaves, and exposing the server selectedStructure value through a new endpoint.