My Space List of Projects (across all spaces) - Show Each Space Name

Hi - I am trying to create a list view in My Space that displays all projects in all spaces (based on filters). My project names are often not unique (enough) to indicate to which space they belong.

Is there any way to:

  1. display the space name (for each set of projects that belong to the same space) - ie. effectively a group by function; OR

  2. display the space name for each project; OR

  3. calc the space name as a formula field in the project database and use that formula to display the space name for each project.

I’m guessing opt 3 is the most doable, but I don’t know how to reference the space name in a formula.

Current Workaround
I’m prefixing each project with a mnemonic for the space name.


If there is no better solution, it should be possible to use a simple script to set a text field for each entity to whatever name you want, including the Space name, which the script can get from args.currentEntities[0].Type.

Hmmm - regardless of how I might calc the space name, it seems that the My Space views can only show “standard” fields, which kind of makes sense, since the standard fields are the only ones guaranteed to be available for all databases in all spaces. Otherwise, the behavior of a cross-space view could be unpredictable.

So, looks like a space name mnemonic in each project name is the way to go for now.

Not sure what you mean with this. It should be possible to choose any available fields.
Perhaps you can provide a screenshot

just a quick note - the availbale fields are only the default out-of-the-box fields (eg name, state, created by, creation date…). Custom fields that I have created are not in the list of available fields…

Can you provide a screenshot. You should be able to show any field, including ones you have.
If you’re only looking at the field settings for ‘All databases’ then yes, it will be limited to any fields they have in common, but you can click on each database and choose which fields to show.

Got it! I was working off ‘All Databases’ - I can see my custom fields now, thx!

But while I’ve got your attention - can I ask, is there a way to display the assoicated Space for each project? I tried created a calculated field, but I’m not sure if that’s possible - can I ask what the syntax would be to ‘compute’ the name of the Space for each Project within that Space?

To be honest, we find it rare to have databases with the same name, where distinguishing them relies on knowing which space they belong to.
If you have multiple databases called Project, I wonder why?

The beauty of Fibery is that you can create multiple different views of entities in the same database, so normally you can ‘slice and dice’ the data in many ways.

If the databases represent things that are sufficiently different so as to warrant separate data types, then normally this would imply that they are conceptually different ‘things’ and so would be named differently.

Perhaps I have misunderstood what you’re trying to do :person_shrugging:

Permissions. We have multiple copies of a specific space because there is no other way to limit what different users can see (different teams using the EOS structure of Goals/Rocks/Issues/Todos etc)

Have you experimented with entity permissions?

Could you not achieve the permissions setup you needed with entity permissions so that all Projects can live in the same db?
If not, please tell us what was missing?

We started this before entity permissions existed.

But entity permissions or access templates don’t have a way to add users based on for example roles or groups. For each entity, you have to manually add which users have access to what.

If you have a team of 10 people and have 10 issues, that’s a lot of actions you perform for all entities combined. The real numbers are much higher for us so I don’t see this as a path forward for us.

I know you are working on it but at the current state it seems unfinished and fragile to use, especially if you have entities that absolutely should not be seen by certain teams/people.

Do you have any tips on what we could do to simplify our setup? Structurally, it would be very helpful to have everything in one space to keep the administration work down.

Have you checked out this topic:

In general, you would only need to create an access template per role, and then assign each person to a given team with a given access template. So for 10 people, there would be 10 assignments (one time only)

Fairly soon we plan on rolling out the ability to grant access templates to multiple people at once, and we also plan on adding support to automatically assign an access template based on a person being connected with an entity, so it will be even simpler.

Going forward, you should probably limit spending time on workarounds that are predicated on multiple databases for the same type of entity, since it will be time wasted when these features are rolled out.

1 Like

It may be sth you rarely encounter, but I could I trouble you to advise whether a calculated field can return the name of the space to which that entity belongs, and if so, what is the formula?


It’s not possible with a formula, only by updating a text field with a script, as @Matt_Blais mentioned.

OK, thx - I’ll go with that

The simplest solution would be to define a Formula field that just returns the Space name as a string constant – then you could reference this field in all other Formulas, so you only have to update this one place if the Space is renamed:

But any solution like this would need to be implemented in every DB that needs to access its Space name.

1 Like

Yeah, I thought about this and actually tried it. I don’t have a problem updating every DB, but I’m already doing that for my deep copy function (ie defining the space name as a constant), so this just becomes one more manual step (that I’m likely to forget). So I’ll just stick with prefixing each project with a mnemonic to indicate the space. Not a big deal, but it seems kind of odd that the space name can’t automatically retrieved in a formula.

I guess the thing is that most users don’t have multiple databases with the same name spread across different spaces, so knowing the db type is enough :person_shrugging:
Solving the underlying problem that might cause a user to have multiple dbs with the same name and same function is more important than adding a new functionality to formulas.

The current Access Model is still limited and forces you to create multiple, identical databases if you want full functionality AND correct access control.