• Start Date: 2020-08-20
• RFC PR:

Summary

Current way of Collection name's pluralizing does not work in other languages as different languages has different rules in order to pluralize words.

Example

For example, when I try to use word "Produkt" (in slovak it means product), the content-type-builder makes "Produkts" from it in order to pluralize it, which is wrong, because right form of this word in slovak language is "Produkty".

I will cite another example from #7505 from @bernhardw:

The problem is, the "Display name" as shown in your screenshot is pluralized based on English rules.

In German for example the plural of events is "Veranstaltungen" and Strapi automatically adds an "s" to the end => "Veranstaltungens" - which is not correct.

Motivation

These inconsistencies could be critical (for us, that are not working for English-speaking clients) in order to present our work to our clients, that expects precision and professionalism from our solution.

Detailed design

Most simplified solution would be to let admins decide, whether content-type-builder should use pluralize package (default option) or admin will provide pluralized form of targetted word.

Pluralized form could be potentially added from Main tab area (maybe below display name) or from "Advanced Settings" Tab during collection creation.

I don't know strapi's internals good enough yet, but maybe we can store both forms (singular and plural) inside of json model and use appropriate form when needed.

Tradeoffs

• Some code is definitelly needed.
• Users will have one more more thing to do in order to pluralize word by themself.
• English users & english based projects will most certainly not need to use this feature.

Alternatives

I'm not able to thing of any alternative right now. Maybe, I will add something later

Unresolved questions

I don't see any right now, but I might add them later

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

Link to the roadmap (related)

Motivations

As we expect to display relational fields in the list view of the Content Manager, it now makes sense to filters the entries based on relational fields.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Don't forget to solve the issue whatever the kind of relationships.
  In other words, the list view must handle one-way, one-to-one, one-to-many, many-to-one, and many-to-many relationships.
• Make the filters too difficult to use and not readable.

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

Link to the roadmap

Motivations

In several cases, it might be interesting to not really delete the entries in databases but only make them unavailable from a user perspective.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Don't follow development best-practices.
• Performance issues.

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

Link to the roadmap

Motivations

A generated API exposes a create route (POST). The route only supports creating one entry at a time. We suggest that we could enhance the current create route or to create a new route to support bulk entries creation.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Don't forget to support bulk updates.
• Performance issues

Vite is a new breed of frontend build tool that significantly improves the frontend development experience. It consists of two major parts:

• A dev server that serves your source files over native ES modules, with rich built-in features and astonishingly fast Hot Module Replacement (HMR).

• A build command that bundles your code with Rollup, pre-configured to output highly optimized static assets for production.

In addition, Vite is highly extensible via its Plugin API and JavaScript API with full typing support.

In a list of products I have a relation where one product has many prices
and it shows like this:

I would like to change this preview or add another option where I could show thoses prices in a chart without to must change it to a custom field because I could lost my relationship.

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

No link to the roadmap available

Motivations

By default, Strapi setups an SMTP server to send emails. We do it to send "Forgot password" and "Email confirmation" emails. Some users raised the idea to create custom email templates. Even, if it's not the main goal of a CMS, there are interesting use cases where the functionality is required.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Remove the email management from the "Users & Permissions" plugin.

Intended for V5

Strapi should give an error and tell you that you don't have authorization to view content-type X only when specific requested it. on the API layer if I make a request but I request data I don't have auth for strapis senatization just removes it and does not error.

Examples of what is not specific

{populate: "*" }

Examples of what is specific:

{ populate: ["relationName"] }
{ populate: ["otherrelation.relationName"] }
{ populate: { relationName: true }

If I tell strapi to populate a specific relationship. I want an ForbiddenError by default if I don't have permissions.

WHY I want this since lots of beginning and even veteran strapi users get stuck for hours since strapi removes there relationship without us being able to see why.

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

Link to the roadmap

Motivations

The list view of the Content Manager doesn't display the relational fields. It only displays simple fields (text, number, boolean, etc) and media.

For instance, when you look for all the blog posts written by a specific user you can't. You have to go to the details page to know the author of the blog post.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Don't forget to solve the issue whatever the kind of relationships.
  In other words, the list view must handle one-way, one-to-one, one-to-many, many-to-one, and many-to-many relationships.
• Maintain high visibility and readability. It means as we did with the media field, we might have to only display information using the hover behavior.

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

Link to the roadmap

Motivations

The current implementation doesn't offer the ability to refresh an existing valid token. Thus, it forces the user to log in every month to generate a new JWT token.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Security breach
• Required a better authentication flow (see strapi/strapi#2704)

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

Link to the roadmap

Motivations

By default, the generated APIs populate the relational field. Even, if it can be very useful, it can cause performance issues, increase the payload for no reason, etc. That's why with this feature we could remove this default behavior and add a new parameter in the request to include the asked relations.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Don't follow developers practices
• Over-engineer the parameters system. It must be easy-to-use and human-readable.