Related to the GitHub issue:
https://github.com/strapi/strapi/issues/8270
I’m opening this thread to promote community discussion related to the RBAC feature, as this was released before we had the forums, I wanted to ensure our community voice was clearly heard.
Please feel free to give whatever feedback you would like, just remember to keep it constructive and in line with our Code of Conduct. Looking forward to hearing what you think.
Hello I’m following the issue of GitHub.
I think one more custom roles for community can be good
I think the EE vs Community limitation should occur at the number of administrators, not at customizing admin role permissions…
I partially agree here, to avoid let’s share a login (which is highly insecure but happens way too often, and also partially defeats the limitations) I understand limiting based on the amount of roles.
I however do agree that role configuration should be freely allowed.
What I think Strapi should do to this limitation is to be able to make a real distinction between EE and the Community.
And for this some axioms can make the distinction:
I think Strapi should judge this issue very carefully, maybe the community has not been of crucial use so far, but the real challenge is just beginning. The power of Strapi will not consist in what it is now, but in plugins and ready-to-use ORM schemas.
Think what wordpress would be without plugins and themes!
I think Strapi should encourage the community to contribute as much as possible.
I can think of no real reason to make this an enterprise feature. Once could take a cynical approach and assume that Strapi is monetizing and part of that plan is to make certain highly-useful features enterprise-only, but I’ll take this call for comment to indicate that this is not the case. I’m sure that Strapi is not interested in crowd-sourcing their business plan.
What I will contribute is that I am the head of a small team at a non-profit. We develop content-managed exhibits for museums. This feature could be very useful for us because we aren’t simply building blogging platforms etc. We will have need to develop custom roles in the course of our regular business, and we are in no way an “Enterprise” company. Quite to the contrary, we have a very few long-term, competent developers and use open-source, self-hosted, tools and technologies almost exclusively in our work. I will also echo what @jonasd said: Strapi should “make a real distinction between EE and the Community”. To me, that means making Enterprise features like support etc. more attractive to managers at “Enterprise” companies rather than restricting access to basic functionality for independent developers and small development-driven companies who are more likely to take part in the OSS community.
@SorinGFS, your observation The power of Strapi will not consist in what it is now, but in plugins and ready-to-use ORM schemas. has to be adopted as the Strapi team’s motto. The reference to WordPress further simplifies the adoption. Besides the RBAC implementation, this motto should be used in planning and implementing all future additions.
Saying this I am extending this discussion to include another “sore subject”, which is a huge issue for the Strapi team - just “google” the term strapi database migration issues. To be clear this issue can be more generally summarized as "bidirectional synchronization between the Strapi data model (as created and maintained by the Strapi GUI Builder) and the related database (see the “low level” discussion about this here: Database Migration / Deployment Questions. I am using the term low level because in this discussion people are using terminology specific to database migrations, while in my opinion the solution should be provided in terms of some intermediate representation which is then used for synchronization between the model (which is Strapi owned object) and a given database. Any direct approach seems to complex (see Migrate data from relational DB to NoSQL).
Now, back to Strapi RBAC implementation which has the same problem, described in the above paragraph. A few initial Strapi releases treated users the same way as any other content object, making it difficult to extract users to be handled by some IAM (Identity and Access Management) PaaS, like AWS IAM service. I had numerous private discussions with @DMehaffy (who is despite his youth incredibly smart and educated developer) about the better approach to add IAM support to Strapi. Yes, I admit using Derrick as the “sounding board”, knowing the Strapi core team is too busy to parse some ideas that are not in the current plan, even if that might result in forfeiting some good ideas.
Strapi’s way of adding IAM (without calling it that way) was by introducing RBAC, by first starting to handle users differently than other content, and then adding Role Based Access Control code as an integral part of the core code. (Who remembers wars with Microsoft when they took the position that Internet Explorer is an integral part of the Windows OS, and compare it with today’s situation where they licensed Chrome and renamed it to Microsoft Edge).
I could expand the RBAC implementation a lot further, but I already wrote a lot. @DMehaffy, please feel free to transform this text into multiple posts if necessary. I wanted to write this post maintaining the @SorinGFS “motto” defined above.
@adriatic exceed the scope of the goal of this post a little bit 
but I do see the link for you with regards of RBAC + SSO and IAM. The migration topic I think requires a much larger discussion itself so I don’t want to muddy the waters of this discussion. But thank you for the feedback @adriatic I do always love getting your point of view 
For the migration topic, lets keep that in: Database Migration / Deployment Questions - #4 by bykof
We both recognized the wide aspect of this post - so let’s cut it to several parts while keeping the motto The power of Strapi will not consist in what it is now, but in plugins and ready-to-use ORM schemas. once there are several comments to the wide post, all of which being interested to further discuss the @SorinGFS’s motto.
I believe that this discussion should not be limited by current development capacities - the power of this motto is require Strapi team to provide sufficiently powerful infrastructure to engage thousands of Strapi community members to create a lot more ambitious Strapi 5.x version 
I want to share another feedback I got from Strapi core team: Strapi cannot be everything for everybody - we do not expect for example to see Strapi customers “outsourcing” IAM to Okta or Auth0. My response would be why not - all PaaS service providers offer a free or very inexpensive tier and I would be extremely happy to be able to use such service.
In order to prove my Strapi IAM theory, I am preparing a large collection of full-stack samples, all of them using a simple Strapi back, coupled with a variety of front ends and IAM PaaS of interest to Strapi community. If this effort results in sufficient interest, it may become one of the larger community projects
Thanks for appreciating my message. I am a relatively new Strapi user, I found out about it like 2 months ago and saw this potential, then I read what I found interesting and saw these discussions about limitations that reminded me of a scene from The Social Network …
I have not done any project with Strapi yet, I am still studying, planning and waiting to see the points that Strapi proposed for Q4 2020 finished, because I noticed that there will be important transformations. As a new user I am interested in being able to rely on a long-term stable Strapi, or now Strapi has not yet decided which path to follow … On one hand I see a lot of good things in Strapi, and on the other hand I see that Strapi is spread over many work fronts that can barely be controlled. The battle in web development is on speed, and from what I see Strapi is more concerned with adding things instead of focusing on performance.
Regarding your intention for preparing a large collection of full-stack samples, I will be among the first to be interested in it. See my project, maybe it will help you to organize the samples more easily under a single domain.
@SorinGFS - your project excited me immediately. It clearly fits into my IAM concepts vision (note, this is the reference to the concepts in my head, not on the information already in that GitHub organization. My plan with this is to create the bare bones needed to attract a few Strapi community members which could and would help with writing a sufficient number of samples to create a more clear vision for Strapi in two years ahead. In this situation, I prefer to help the ground-up design process by enabling to extrapolate from these samples (gradually refined design). A good example is the series of .NET releases
Definitively interested in using your project as the first “intermediate” level of abstraction on top of real IAM. Let’s find a few more of us .
Hello I just wanted to add my perspective on the topic of the current RBAC implementation.
I was honestly very surprised to find out that the RBAC feature is so severely limited in the CE.
When the feature was introduced up until this point (looking at the documentation which does not mention RBAC at all) it is very hard to find informations about the limitations at all. I had to find out the hard way (seeing everything was grayed out in the Admin and wondering why) and after the fact read the announcement post again very carefully to find the limitations.
I fully understand that the decision was made to limit the feature for the CE and I was welcoming the middle ground with the 3 allowed roles.
For me this was understandable as non EE use cases rarely need more roles. I would have been able to manage just fine and I was really happy when RBAC was announced just as I was going to need it in my project, perfect timing I thought.
Now however my use case was the simple desire to prevent one role to delete content of a specific type.
To me that was the most basic requirement to get any use out of the RBAC feature.
I think this all or nothing approach is just too limiting.
Sorry that I don´t have anything postitiv to add to this discussion but I thought any perspective might be valuable.
No problem at all, we appreciate your candor, and it’s exactly what we are looking for.
Hey all I’m a fairly new user to strapi, and fairly novice when it comes to full-stack development, but I’d like to throw in my two cents please forgive my naivety.
To start I’ve been a designer / web developer for years, I work with several clients, small - medium sized at best. I understand my needs and use case probably won’t align with the core target demographic for Strapi.
Personally I have more front-end experience than I do back-end, and to that end Strapi gives me what wordpress gave me for the front-end —- a few years back when I was starting out, and that is a set of “training wheels”. Although I can navigate around databases and have somewhat of a working understand of SQL related backends, I personally do not feel confident enough to manage a custom implementation on my own. The more I learn the more I find that there are more things that DO NOT understand than things that I actually do. For this reason, I have gravitated towards Strapi, it feels like a set of training wheels, there are some best practices in place and a few abstractions as well. I appreciate that.
All this is to say that I’d like to see the CE version remain a bit as it is, with high marks for usability provided with sensible options for building on top of what already exists. For me this feels like a great way to grow the community as Strapi already does with plugins and such.
So my two cents really is this…
I think you guys should def find a solid form of monetization, but I believe the real strength of Strapi is in it’s flexibility. I’ve tried several other CMS’s (of various varieties) and I have to say the biggest advantage of Strapi is that it’s usable.
Just for contrast I recently worked with a Sanity based CMS for a project, and although it was fairly easy to get along with I was turned off by the monitoring they did in the dashboard, tracking your usage and limiting it to a certain amount (don’t recall the exacts), but that was enough to turn my off before I got too far in, for someone like me who learns my making mistakes (often a ton of em), something that was tracking my mistakes felt like a huge issue, especially in development!!
I hope that makes sense, I apologize for the rant… really loving Strapi and hope to get to point to be able to contribute some goodness to the community! Thank you for all your hard work and efforts you are appreciated!
The comment I am about to write is inspired by gshah’s post - since it is wider than this discussion, I will post it again (when @DMehaffy tells me where 
)
The concept of using Strapi as a set of training wheels fits in my own perception of Strapi, for the same reason as @gshah2020. However, in order to make it a lot more valuable tool, there should be a user-friendly (GUI, most likely) tool that records keystrokes generated in the construction of Strapi code. That tool, call it a “player” should be be able to run using the saved keystrokes and create a new instance of Strapi app using just the saved “keystrokes log”.
This is not any novelty - I created a saved keystrokes based scripting programmers editor (originally to save myself from troubles in supporting this product, where the user would report "your thing crashed and I do not know how to reproduce it) Rocket-chat is another similar tool which being open source may be a good partner for Strapi.
One paragraph-long description may be insufficient, so I would be happy to expand it in the proper context
@adriatic yeah this thread really isn’t the place for it but we do have the templates system: https://strapi.io/documentation/v3.x/concepts/templates.html#templates
And a number of templates we have built (though anyone can build them): strapi · GitHub
The fact that roles cannot be edited in any meaningful way in community edition is frustrating, but worse the documentation and all available resources are misleading in a way that by accident or intention could funnel new developers on small projects testing out the framework into either being forced to upgrade or forced to give up hours of development due to the lack of this basic feature.
I spent hours researching Strapi before choosing it for a current project and nowhere on the pricing page (Strapi | Self-Hosted Pricing & Plans) or the documentation (https://strapi.io/documentation/v3.x/plugins/users-permissions.html) is this limitation clearly outlined. It’s left to the developer to stumble upon.
This leaves a seriously bad taste in my mouth. What other landmines are there in terms of necessary features that are now or will in the future be locked behind an unclear paywall?
I just wanted to remind everyone, your comments are not going unnoticed. These are all certainly important concerns to us and we are actively discussing all your feedback.
I just wanted to thank you all for being frank and straightforward with us, we rely on our community to let us know if we are missing something.
I was very delighted to find this thread. We’ve been using Strapi for months in our small company, and the inability to forbid roles to Create/Delete content was frustrating.
We have freelancers working with us to whom we can’t delegate the above capabilities.
I hope this basic feature will become accessible in CE, which will make Strapi a de-facto choice for many more teams.