When configuring a view in Fibery and selecting levels within the database hierarchy, only the database name is currently displayed. However, it is often necessary to know which Space the database belongs to, especially when working in environments with many similarly named databases across multiple Spaces.
Current Behavior:
Currently, I need to manually click on each selection to identify the Space that the database is from. This is time-consuming and could be streamlined.
To enhance usability, consider displaying the Space name alongside the database name in the selector dropdown. This would eliminate the need for extra clicks and provide immediate context.
Thx for the feedback.
Interesting that you have so many databases with the same name. This might indicate that your schema is not optimal.
What are your reasons for doing so?
For the times that multiple spaces have needed the same kind of thing, we just created a database that each space can add to, and the database is stored in a separate Space that we use for several of these ācentral/basic databasesā. One such database is task, another is docsā¦ we have around 8 of these databases in our ādatabase Spaceā.
Thx @Michael_Ichter
From the first post (incl screenshot) it looks like multiple databases for the same type, each in a different space @Renato_Carvalho
So why should each space get a database for the same thing?
@Chr1sG are you responding to my post? Iām not the original poster. My post is showing that we do what you are suggesting, and I was just sharing our practice as a possibility for Renato to get around the struggle of having several databases with the same name (and perhaps the same purpose).
But, perhaps I wasnāt very clear as to WHY I was posting. Sorry if I caused some confusion!
You should probably consider having a single Task database, and then a database for Departments. You can link Tasks to Departments (and/or to Users) and then create dedicated filtered views so each person only sees relevant Tasks (based on their Department membership and/or Task assignments).
Maybe a board view (filtered for Assigned to Me) with status as columns and Departments as rows.
It kinda depends on how Tasks map to Users.
But in general, there arenāt often good reasons to make multiple Task databases, especially now that permissions can be as granular as you like.
A couple of other things that make a single Task database nice: you can set it so that Users assigned to a Department automatically receive access to Tasks related to that Department (and can customize what level of access is inherited). Also, for common automations (like date reminders), you only have to create them once instead of making it multiple times in the case of having multiple Task databases.
I have developed a number of solutions in fibery that can be pitched to customers, all present in one workspace. This results in a workspace with 130 databases spread across 6 unrelated solutions.
It is obvious that the sidebar is a mess and very difficult to work with. I managed up to now to hide everything I am not busy with in āHidden for Meā. There are no separators in the sidebar to group the databases and spaces per product, so it is one long list and very difficult to find which database belongs to which space or solution (solutions have more than one space to also solve the permissions shortcomings by assigning views to spaces without databases in the space).
In the light of this explanation, adding a space name to a database selector or something similar, could be helpful to navigate a sidebar with 130 databases
Yeah, besides the conversation about space design and optimization, I find other cases with way less databases where I need to remind myself from where that database is coming from.
So, showing somehow the name of the space close to the database might still be helpful.
@Renato_Carvalho I would say this is very case-by-case. Sometimes, it made sense for us to add a field to the central Task database as it was something helpful for most people (such as a relation to another database like Docs). Other times, we found that a team wasnāt really wanting a database for tracking normal tasks. In one case, a team was wanting to define the normal workflow for a task that occurs regularly (annually) to easily be shared, which seemed like more of a wiki/āstandard operating procedureā function. In this case, using our Doc database was better. In another case, the teamās tasks were centered around new recruits, and it was better for us to make a Recruit database that contained all the info and needs per Recruit (I thought about also creating a relation between Recruits and Tasks, but this doesnāt seem to be needed).
If there is a type of thing that has distinctly different fields/relations to an existing database, then yeah, it maybe warrants being a database itself, but in that case, it possibly should be named differently (since it is a different type of thing)
i.e. if itās a ātaskā then use the Task db, but if itās different to a ātaskā, then it can live in another db, but it shouldnāt be in a database called Task (!)
