Button trigger context

I was wondering if there is some way of understanding the context in which a button was triggered. For example, it is possible to trigger a button of an entity inside a collection (when it is in a one-to-many relation). So if a I have a collection of sub projects linked to a parent project:

image

I can call “Test Button” against each of the sub-projects. However, would I be able to know that the “Test Button” was called inside Project A and have access to Project A’s fields?

1 Like

In most cases, you can access the Project’s fields in buttons (and rules) using formulas.
There’s no way for Fibery to distinguish the button being pressed from within the collection field of a Project (compared to say from a table view or the entity view) but you can use filters and/or formulas to determine what should happen to a item based on whether or not it has a parent Project.

1 Like

Related: Make "creation context" available to scripts

1 Like

Yes, that is precisely what I’ve done in the case that I’ve been working on. The basic structure that I have is as follows:

image

The intent of the button is to create a new copy of an Initiative entity and add it to the current Service Category. The action is to Create a new Initiative and I set the fields as follows:

[Name] = [Step 1 Initiative].Name
[Type] = [Step 1 Initiative].Type
[Service Category] = [Step 1 Initiative].[Service Category].Sort(Name).First()

The challenge is that Initiatives and Service Categories have a many-to-many relation, which means if there are more than 1 Service Categories assigned to the Initiative, then it is possible that the new copy is assigned to the wrong Service Category (as I am sorting by Name which is arbitrary so that I can call First()). For this to function properly, then I need to be able to know which Service Category entity’s collection the button was invoked from.

1 Like

That isn’t what your workspace map is showing in the image you shared :thinking:

@Chr1sG you’ve got a good eye :wink: I’ve simplified the structure for the sake of this discussion/post and so the graphic doesn’t quite match-up with reality. But the relation is a many-to-many relation.

Can try and record a screen capture to better describe the full setup if that is helpful

So you want to run an Initiative button automation from the collection field of a Service Category entity view, right?
Or is it from another view you have in mind?

Is there anything that distinguishes the Initiative to be duplicated from other Initiatives within the same Service Category?

Yes!

Not really. I can add more fields to distinguish duplicated ones, but not sure how that might help.

Hey,

I am running into something similar in this simple example:

We have an entity with Shoots (for some captures we do), and here we have passes with assigned labels so we know what to shoot. In all passes we then add as many takes as necessary until we have one thats good.
It would be nice to press the “Create Pass from Label” button, and immediately add a pass to the currently open shoot (if its shown inside of one), and otherwise open a window asking for the shoot to add to.

The “opening a window and select the shoot” works fine, but its an extra thing people need to do to get the desired result. Just pressing the button creates a way smoother experience.

In the views, new data is already assigned with the provided filters, so its clear that the views have an understanding of their current context. Extending this to the enitities in the views would really help smoothing out some processes

Unfortunately, buttons do not ‘know’ anything about what view the user was looking at when the button is pressed - they only have access to the information that exists in the entity(s) whose button was pressed.

However, in your example, assuming that the relation between shoot and labels is one-to-many, it would certainly be possible to define automations which will allow a pass to be created with the same shoot as its parent. However, it requires that the label db is linked to the pass db - so that a button in the label db can create an entity in the pass db.
There are workarounds, but the issue is not one of the label button not ‘knowing the context’.