“The idea is being able to see a history of permission changes.”
What problem might it solve?
“In the case of multiple developers involved in the backend project, it’s almost vital to being able to track changes to understand who and why made them. Even one developer after a long time easily could forget why he did some changes. I think having that feature should reduce uncertainty and make the development process more robust.”
“I see a few ways to achieve that ability. The first one is a history of all changes in permissions, kind of log of changes, accessible via 8base console, where you can see who and what changed. The second one is an ability to make the code as a source of truth and take advantage of git to control changes. (the Graphcool way)”
Personally, I don’t have a preference for where to store the permissions configuration. Probably later, after enough usage of 8base, I could form some opinion on that.
I think there is another important question we should discuss. If we can edit permission from both UI and code what will be the source of truth? Should we pick one and leave with that decision for the rest of the project life? Is there a solution that satisfies everyone? One of the solutions I see is having the code as a source of truth but that code should be accessible from both 8base UI and developer and every change from UI gets a reflection in a code.
I’m ok with having a log of all changes in permissions system or generally in 8base configuration (tables, settings) where I can see who and what changed. For the big projects with many developers involved and tools, they are using for tracking tasks, the code as a source of truth has a preference. But the different projects have different requirements, and least of all I want to see that you avoid small/middle projects by making their life complicated with code as a source of truth in the first place.