I propose a setting in the Space configuration, to disable a space, without deleting it.
use case:
I have different spaces that are not ‘production spaces’ because they are being tested, developed or tried out after being imported from space templates.
Benefit of disabling spaces, is that all databases from these disabled spaces will be automatically excluded from normal search, ai search and ai chatbot knowledge. Ideally this needs a solution such that re-indexing would not be necessary when re-enabling the space, to prevent costs.
Also, there will be a tag or separate section where these spaces are grouped.
databases can be excluded from search: Yes but then the search index is lost when excluding from search, and needs to be rebuilt when including the databases. Also, a space can have many databases that will need to be manually disabled from search, which is not efficient.
spaces can be hidden from non-admins using permissions: Given that development of features in spaces is done by admins, the spaces need to stay accessible, but not treated as production spaces. Meaning: hiding spaces is not the purpose of the request.
dbs need to be opted in to ai search/chatbots: Again same issue as the search index, and more expensive to turn on and off.
spaces can be moved to the ‘hidden’ area of the left menu: This is not the main purpose of the request.
But let’s first look at my main tension here:
Whenever I a database needs to be selected, that is either when creating a new entity through the search interface, setting a databases in a relationships view, using the select box in chrome extension, searching for an entity in the search interface, etc. the testing or development space databases keep on showing up, cluttering the list of databases that can be selected.
Instead of disabling a space, a workaround could be to make it easy for users to export and import a space to a remote or local host.
Btw I’m interested to learn how the Fbery team works with spaces, when developing concurrent branches of spaces, test spaces, staging spaces, or features that rely on spaces being turned on or off as mentioned above. Are you using multiple workspaces for that? If so, that would indicate that users as space creators likely require that also.
I think you overestimate how often other users (Fibery or customers) find themselves ‘developing concurrent branches of spaces, test spaces, staging spaces’.
The establishment of the optimal schema tends to be 90+% done in the first few days/weeks of use.
The idea is that Fibery should be mostly used for real work (adding/updating content a.k.a. entities) not experimenting with alternative schemas.
export and import only one space, or specified collection of databases, instead of exporting the whole workspace?
disable a specified collection of databases using a script, such that they don’t show up in the search as well as database selection dropdown of views etc?