Content Editing XP

Currently the dropdown only loads a fixed number of results from relation. this becomes an issue as while selecting categories or tags, the business has to rely n editorial mind recollection instead of scrolling and assessing which once are best suited relations.

While close accordions in dynamic zones are fine when they load first, but I would like to propose that while the accordion is being added it remains open to make the editing experience more focused and the editor does not have to wonder where did the added component go.

In my project, the content editors are often writing their content in a tool of their choice, such as Notion or Google Docs. Currently, rich text formatting from tools like Google Docs is stripped, and the content is pasted as plain text. Between Google Docs & Notion, copy-pasting automagically preserves basic formatting in both ways. I'm not sure how it works, but it would be nice to have this convenience in Strapi too. Notion generally pastes into plain text fields as Markdown, also in the Blocks Editor, but that Markdown isn't auto-converted to its blocks editor equivalents.

As an enterprise user of Strapi, we have found that the current SSO functionality (OIDC providers) lacks dynamic role mapping based on group claims. In large organizations, managing access across different software is challenging, and Strapi currently requires manual role updates or custom code to handle this. Many enterprise OIDC providers (Azure AD, Okta, Keycloak, etc.) return group claims in the ID token or via the userinfo endpoint. Strapi should natively support mapping these external group claims to multiple Strapi roles and update them dynamically on every login. Example Scenario: • Group-to-role mapping: • axxxx → Admin • bxxxx → Editor • cxxxx → Author • First login: user belongs to ["axxxx", "bxxxx"] → roles: Admin + Editor • Second login: user belongs to ["bxxxx", "cxxxx"] → roles: Editor + Author This ensures roles always reflect the user’s current group membership and reduces the operational burden for enterprise IT teams. Benefits for Enterprise Users: • Dynamic, real-time role updates without custom code • Consistent access management across multiple systems • Support for multiple roles per user • Works with any OIDC-compliant provider Proposed UX / Implementation Idea: • Allow defining group-to-role mappings per OIDC provider in the users-permissions plugin • Automatically update user roles at login based on current group claims

It's currently not possible to filter/sort by status in the list of a collection type. This would be a useful feature.

Some components' attribute names are not very understandable. Allow adding an optional description would increase user understanding. This description would be displayed next to the attribute name on the administration panel to help the user fill the component.

Our plan is to make the Admin Panel work well on small screens and mobile phones. 1️⃣ Navigation & Layout We plan to update the main menu to work better on mobile. It will open as a side drawer that's easy to reach without taking up too much space. We also plan to improve the sub-menu. On small screens, complex menus can be hard to use. We'll make the sub-menu mobile-friendly while keeping it organized and easy to navigate. 2️⃣ Editing Content (Edit View) Most of our work will focus on making the Edit View work on mobile, since this is where people spend most of their time. We plan to redesign the header to fit narrow screens. Important buttons and information will stay visible and won't get cut off. Forms will stack neatly on small screens. We'll adjust spacing, improve field layouts, and make sure everything works well with touch controls. 3️⃣ Content History The Content History header will work on mobile. You'll be able to easily read information and use controls. History actions and details will move into mobile-friendly drawers. This will keep things consistent and easy to use. We'll make sure history comparisons and data display properly on small screens without breaking the layout or requiring horizontal scrolling. 4️⃣ List View Improvements We plan to redesign filters to work better on mobile. Instead of showing everything at once, filters will open in drawers or pop-ups. You'll still get all the filtering options, just organized better for small screens. 5️⃣ Rich Content & Complex Fields The rich text editor will work reliably on mobile devices. The toolbar will be easy to access, typing will be smooth, and everything will work well with touch. Components and dynamic zones can be tricky on small screens. We'll make sure you can still rearrange and edit structured content easily on mobile, not just on desktop. 6️⃣ Text & Visual Design We plan to improve how text looks on small screens. This will include adjusting font sizes, spacing, and layouts to make everything easy to read without feeling cramped.

I have a collection with a rich text field called “text”. Because it is rich text, I can’t use it as the entry title when I configure the view. This is very inconvenient because I’m either faced with not having a label, or having to duplicate the data with a normal text field called “InternalLabel” See: https://github.com/strapi/strapi/issues/12549

Would be great for authors, if they could copy and paste components between content type items. E.g. if a content type represents pages, an editor could duplicate components from one page's dynamic zone into another dynamic zone.

The easiest example to explain is laid out like this, we have the following models: Make Model Sales In this context we are talking about cars, so the make would contain a list of car manufacturers (Subaru, Toyota, Ford, Chevy, ect). Thus the model would contain some options like WRX, GT86, Mustang, Corvette. The way we would setup the sales model would be a oneWay relation to each make/model, and in the context of this request when we create a new "sale" we would select the make (say subaru) now when I go to select the model I should only be able to see/select the "WRX" model since it's made by Subaru. I should not be able to select "Toyota" "Mustang" as that car doesn't exist. See for more information: https://github.com/strapi/strapi/issues/8708