There have been many discussions around the left navigation bar and the new database configuraiton UI, but the main thing I was interested in, is the ability to group databases in the same space. This is still not possible.
Now I still have to create multiple spaces, only to organize the databases.
This will be okay for me if we get nested spaces. But simple folders will do for me too.
Given that you can group spaces in folders, why do you want to put databases in folders?
If what you are asking for is this:
Space
- Folder A
– DB1
– DB2
- Folder B
– DB3
– DB4
why not do this:
Folder
- Space A
– DB1
– DB2
- Space B
– DB3
– DB4
?
Is is because you want access control to be the same for all DBs?
Given that databases are effectively a ‘behind-the-scenes’ concept, does it even matter how they are grouped? Isn’t the grouping of views more important?
- Permission Templates Eliminate Space Dependency: Fibery’s permission templates allow centralized access control for departments, removing the need for multiple spaces to manage permissions.
- Folders Reduce Workspace Complexity: Grouping databases in folders within a single space simplifies organization, avoiding the redundancy and clutter of multiple spaces.
- Flexible Reorganization Without Maintenance Overhead: Folders enable easy database regrouping within a space, preventing the need to update scripts or templates tied to hardcoded Space/Database values.
Because I am continously creating new functionality in fibery, grouping databases happens often because I want to see them grouped by functionality, but not grouped by permissions
..and do not want to keep on changing hardcoded Space/Database values in:
- scripts
- markdown templates
- mention links
(and changing space likely has more impact than only that)
Lets get to the root of the issue, which is beyond the current topic alone:
Databases, just like Rules, are not entities, and for that reason I as system and workflow designer, have major prolems with organizing them in, for me, meaning ful ways.
It would help if any configuration that is not an entity (such as Databases Buttons and Rules and Views) can at least be ‘tagged’ somehow, if turning them into entities would be a too big step for fibery. That would allow better administration of these configuration items.
Over the last two years I tried to workaround creating databases for:
Views
Rules
Buttons
Databases
Which still is very complex to maintain, requiring internal links to the corresponding configuration pages their URLs, while fibery does not open its link field as panel but as new browser tab, disrupting the UX and efficiency of it.