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
Maybe I’m missing something… don’t know 
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?? 
Thank you,
Matteo