Handle deletion of referenced items

Hrm, hard to say. I could probably make a convincing argument for both approaches. ;) It's a bit hard to tell what "other customers" of this module would expect, and I'm trying to think outside of the project_issue box.

If it wasn't a ton of complication and code, I'd almost say this is something you should just be able to configure when you define the dereference field in the first place. Then we don't have to decide and we just let users get the semantics they want on a per-field basis. However, that might be more trouble than it's worth.

Short of that, I think I lean towards leaving the code simple and the semantics a little loose. Namely, you can delete a value in the "parent" field and then the next time you edit any entities that dereference and point to that parent, you get a validation error and have to pick one of the remaining/new choices.

But, I'm not at all sold on this, and would happily entertain an argument that we should provide different semantics. But, my instinct is that if it's not trivial to just let users decide as needed, we should err on the side of simplicity and less code...

I lean towards leaving the code simple and the semantics a little loose. Namely, you can delete a value in the "parent" field and then the next time you edit any entities that dereference and point to that parent, you get a validation error and have to pick one of the remaining/new choices.

That matches my understanding of what Project Issue does in 6.x. Seems like we don't need this for Drupal.org D7.

.

The code I'm seeing in this module looks like it is set up to gracefully handle dead-end references, and deletions do happen.