Save permissions and plugin settings to a file

[brooth]

Describe the topic

Sorry if already asked, I couldn't find any related issues.

So the problem is that you have to configure things twice (at least), in dev and in prod. Of course, it's often forgotten to do so in prod which leads to fails. It wouldn't be an issue if the plugins save their settings into a JSON file as Content-Type Builder does. Besides, it seems to me that it's not architectural correct to mix the presentation (setting manager, layout config), application (roles&permissions, endpoints access) and the data layers. I wouldn't mind submitting an RP if it won't be rejected.

Your suggestions for this topic

N/A

Screenshots

N/A

Code snippets

N/A

Additional context

N/A

[derrickmehaffy]

@brooth I have updated your OP to use the discussion template. Normally issues created without a template are closed.

Straight and to the point, I have suggested a number of options related to this and it all comes down to two use cases:

1. Those of us who love to source control everything (IE dumping this stuff to files)
2. Those who prefer to just edit things in production and save to the database

One of the suggestions made by @Aurelsicoko and @alexandrebodin is a sort of hybrid system where say you edit the permissions in development, those settings are stored in the database, in which those could also be dumped into a CSV/JSON/Whatever format on save also (Source control tracking).

Then you would have the option when you deploy into production where:

1. Permissions is empty doesn't exist -> Seed it from that stored file
2. Permissions do exist and you have the option to forcefully overwrite them (drop the table and import) or do nothing

I understand why the Strapi team want to allow for these changes in production without going through the whole develop locally -> deploy to staging to test -> deploy into production. For instance especially if you run in a cluster with load balancing and fail over you could hit a case where half of your cluster is running off one set of permissions (or adminUI CTM layout) and the other is not ect. But doing something like the above import/export would realistically solve both issues (unless you modified permissions in production but never did it in development which opens up a whole other discussion about locking out changes in production. Maybe with a config setting?)

[derrickmehaffy]

Forcing a choice in either direction though is not a good solution in my opinion, everyone uses Strapi differently with different expectations and requirements that it is not a good practice to force a storage choice. (Hence the reason Strapi supports both MongoDB and the SQL databases despite the guerrilla warfare both those sides have on each other 😉 )

[Aurelsicoko]

Great summary @derrickmehaffy!

@brooth You hit the issue but the easiest/fastest way to solve it by storing everything in a file isn't the right long-term solution (IMO). Like Derrick said, how do you handle it when you have a cluster of servers? The best solution is to store everything in the database, but right now it's a pain point because we don't offer an easy way to switch from development to production, and vice-versa.

There are a lot of issues talking about this topic:

• Permissions flow between environments #672
• Running Strapi in production and version control sync #1986 (comment)

PS: I'm not sure we should keep the issue opened because it seems to be a duplicate, and the topic has already been largely discussed.

[derrickmehaffy]

@Aurelsicoko I think it should be fine to leave this open for discussion and maybe get some more outside views on how best to handle this before an RFC is drawn up for deeper discussion on implementation.

But yes those two issues are good reference points.

[brooth]

@derrickmehaffy Thanks for cleaning my post up, I'm quite new in contributing on GitHub but this issue is bugging me a lot so I need to learn how the things are going.

I understand why the Strapi team want to allow for these changes in production

I respect all the team for the work they've done. Strapi is a lifesaver and really helps me in my work. But since it's a community-driven project let's stop taking into account one's preferences. The idea behind a framework is to help the developer.

@Aurelsicoko Sorry I missed #672, it clarifies some, especially that solving this problem other than saving settings into a file leads to confusing solutions.

Let's do some pros and cons:

Cons:

1. Inconsistent environment. When I push new code that relies on e.g. /endpoint is open for public users but it doesn't, the code fails.
2. Allowing editing settings in production that can stop business logic working correctly.

I personally have such experience when a customer decided to change some permissions, which he thought were too much to allow, and our team ended up spending hours to figure out why code started to fail without any changes.

One more time friends, in production those settings are open for editing to the end-users, even if they are super admins (or customers who think they are) - it's a matter of time when they screw things up.
If I, as a developer, decided to make a model property read-only - I did this for the exact same reason - I know that editing this property can stop the app working - and I expect this property will be read-only in production.

The bottom line - the only developer can have access to edit settings that affect business logic. Thus, permissions and content-manager plugins must be available in development env only.

Pros:

1. I didn't fully get the cluster point, as being said, the inconsistent environment is more likely to fail. The best practice would be not to push untested code to all nodes.

[derrickmehaffy]

I didn't fully get the cluster point, as being said, the inconsistent environment is more likely to fail. The best practice would be not to push untested code to all nodes.

Trust me when I say this as a systems and network engineer (with a bit of devops thrown around) no one ever wants to follow proper standards.

Believe me I agree that a file override system would be the best solution (providing the best of both worlds), and the easiest way to explain that is this:

IF api/blogpost/config/blogpost_permissions.json exists use it ELSE use the database table

Doing the above solution would effectively lock those permissions so they cannot be edited (maybe adding a simple way to dump current permissions into that file.

However with the above solution as @Aurelsicoko has mentioned to me in slack and probably somewhere here in the github, this violates the typical developer mentality of a "Since source of truth" (Which I understand and agree with). The conflict here is core developers who want to source control everything, with proper upgrade, change management, and approvals/ect.

But Strapi is not just an enterprise product, trust me when I say being the most active user on both the Strapi github and slack a good 40% to 60% of users are not building large projects with lots of team members (or even doing proper staging deployments for testing). Strapi's core purpose is to be easy, and many of the users are coming from other solutions like Wordpress, Drupal, Contentful, IBM's loopback, GraphCMS, and insert some other random CMS name

Strapi itself defines the project as a "headless cms" specifically a stateless one to allow for scaling (not defined by them this way, but that's how it's built) as much as I and others in the community view it as much more than that, and more like a framework (API framework) that is not how it is designed.

Personally I think the permission system needs a massive overhaul splitting the adminUI permissions from the REST/GraphQL (which is planned but not quite to the level I'm thinking) and adding in deep level permissions at multiple levels:

REST/GraphQL

• User based (Individual user permissions)
• Role based (including viewable fields and relational views)
• Field permissions (GET/POST/PUT)

AdminUI

• Accessible plugins
• Configuration
• Email and other templates
• Model based (View, Create, Edit, Delete)
• Field based (View, Create, Edit, Delete)

[lauriejim]

Thank you all for this discussion.
We got all your insight ;)

[jiv-e]

Hi,
I want to chime in for this. I have worked with Drupal several years. I think it is the only major open source CMS with exactly the same problem space called "configuration management".

I have just started to work with Strapi. I hope that it can replace Drupal in many cases, if not all. It has many of the features I need and is also more slick and modern solution for my needs.

The database vs. files discussion has been going for a long time in Drupal world and the community has a lot of experience of practical issues and workflows related to configuration management. Here's a video offering a peek into it:
https://www.youtube.com/watch?v=hyuGFtmPK3Y

[alexandrebodin]

@jiv-e Thank you for this insight. Will be interesting to watch !