Is it possible to allow only "delete" inhibiting the "disassociate" in a relationship?

Help me!
1

I have a collection “A” that has many “B”.

In the collection “A” settings there is a field in the relationships that allows me to choos if the relationship is “read only” or not. I set the relationship as NOT “read only”.

And in the role settings I have the following settings:

Screenshot 2023-03-06 at 09.27.43
Screenshot 2023-03-06 at 09.27.431988×314 14.1 KB

Now, from the “A” collection I go to the related “B” records.

In this list I can select one of the “B” records and I can delete it.

Screenshot 2023-03-06 at 09.14.48
Screenshot 2023-03-06 at 09.14.48696×310 16.7 KB

I’d like to be able to “delete” this record, but I’d like to inhibit the “disassociate the relationship” feature. Is it possible to remove the “disassociate” option?

Thank you,
Matteo

2

Similarly, I’d like to allow only “new” elements, preventing the user from associating existing elements:
Screenshot 2023-03-06 at 10.04.16

How can I achieve this?

Thank you,
Matteo

4

Hello @Matteo,

Thanks for reaching out :raised_hands:

Your questions are perfectly clear.
Unfortunately, there is no way today to do what you’re trying to achieve (the other way around is possible though - having the “dissociate” without the “delete” for instance).

I’m pushing a request to our Product board so that it can be tackled in the future.

Thanks again for your feedback and sorry for the inconvenience.

1 Like
5

Hi Forest.
Any update about this from your product board?

Is this covered in the new @forestadmin/agent?

Thank you,
Matteo

@morganperre I’m tagging you here because you liked the previous answer and the Forest Guy who answered me in march 2023 is now “anon###” so maybe at the moment he’s not a Forest Guy any more :sweat_smile:

6

Hello Mateo,

Unfortunately, we did have done anything regarding this.

Though, you can disable dissociation while maintaining delete by combining role permission Delete :heavy_check_mark: and Update :heavy_multiplication_x: (but not sure you don’t want to allow Updates). Dissociate is only available when having both permissions (which make sense since dissociating is only an update). :slight_smile:

As you pointed-out something on the frontend I’m not sure to understand.
For sure you could do something on the agent side to throw and forbids it manually using a hook before update.

Let me know if the workaround is enough for you. In the meanwhile I will re forward the feedback to the product team.

Kind regards,
Morgan

7

Thank you @morganperre
We can’t manage this thing with roles, as the roles we need will allow both Delete and Disassociate… that’s our point :man_shrugging:

With the legacy forest express sequelize, we managed this with a number of route overrides (one for each relationship where we needed to prevent Disassociate) and we’re now migrating to the new agent, so I was wondering if we had to do the same with a before update hook :smile:

…and it looks like we still have to :muscle:

Thank you for your answer.
Matteo

1 Like
8

Hey again,

It seems possible from the frontend only :sparkles: (with some downside you loose the bulk delete from the related view too)

You will need to:

  • Setting up the relationship (A) as “read only” in the collection B
  • Allowing the collection delete permission
Example

image
image1144×802 56 KB

Let me know if it works for you. :pray:

King regards,
Morgan

9

Hi @morganperre
We’re not able to do what you suggest.

We set up the relationship (A) as “read only” in the collection B
We allowed the collection B delete permission

But now we can both:

  • delete B
  • disassociate B

:man_shrugging:

Maybe I’m missing something… don’t know :pray:

By the way, since we’re migrating to the new agent @forestadmin/agent, it would be very nice if, in the deleteOverride function, you tell in the context if the function call comes from a delete or a disassociate (i.e. understanding the http route where the function call comes from…).

DELETE /forest/A/2971/relationships/B

The same we suggest for the updateOverride in this comment.

…but wait!!!

in the past I’m pretty sure that you used to send an http POST in this case. not a DELETE!!! How is this possible?!? Did you change something?

We created (about 1.5 years ago) a complex mechanism (with route overrides) to prevent the disassociate on our side, by overriding the involved routes and allowing updates (POST to the relationship route) only if there is a create (POST in the “B” route) at most 3 seconds before.

Now we just realized that this does not work any more!! Because you are now disassociating through a DELETE to the relationship route!

@jeffladiray you recently told us that in the new agent @forestadmin/agent everything about the disassociate passes through the deleteOverride (in the new agent).
But I’m really sure that previously you sent a POST (not a DELETE) the the relationship route to disassociate.

May you please confirm that you changed this behaviour? Or am I allucinating?? :open_mouth:

Thank you,
Matteo

10

Hello @Matteo,

I’m a little bit disappointed. I tried it on my side and it was working. From where did you try to delete or dissociate ? (related data (has many relation) or the belongsTo)

Maybe you need to do the read only trick on both side depending on how you navigate your data.

Nevertheless, this is not ideal and I have shared your feedback to the team. I will ping them again to emphase the issue.

We didn’t change the contract.
In our old documentation you can see:

DELETE /forest/{modelName}/{id}/relationships/{hasManyRelationName} ⟶ Dissociate records from relations

Let me know if you end up configuring it correctly.

Kind regards,
Morgan

11

Hey there,

We did release the ability to hide “Dissociate the relationship” action. You can now hide at the team level that default action, for a relationship they don’t want to dissociate.

Here is a little video demonstrating the feature.

Kind regards,
Morgan

1 Like
12

Thank you @morganperre
That’s great! :muscle: