Edit checks should use viewmodel attributes, should identify how the association changed.

[chrisandreae]

(1) it might be nicer for viewmodel edit checks to deal in terms of viewmodel’s attributes and association’s rather than model’s.

To do this, we could use the attribute_changed! during deserialization that’s used in VM::Record.

(2) This is awkward to do, because we have limitations on how we can edit check associations to children, when permissions vary depending on what you’ve done to the child.

For example, if we have Lessons and LessonIssues. There are CREATE, EDIT, VIEW permissions for LessonIssue. Anyone who has CREATE or EDIT is allowed to create a LessonIssue (and attach it to a lesson)

However, someone with CREATE shouldn’t be able to move a LessonIssue from one lesson to another.

However, currently, this is only enforced by the lesson_id model attribute change in the LessonIssue (i.e. to change attributes on an existing issue, you have to have EDIT)

But if lesson_id were no longer present in the LessonIssue changes, we’d have to enforce the change from the Lesson side.

So the Lesson side would have to know whether the issue that’s being attached to it is new (in which case allow it with CREATE) or pre-existing (in which case allow it with EDIT)

In this specific case it’s potentially simpler, because LessonIssues must have a lesson. Because they can’t previously be unparented, the edit check in Lesson could be presented with the information about whether the changed associated records are being attached or detached from the Lesson. The attach could be allowed to everybody, but the detach could require edit. That’s enough to prevent a CREATEor from moving a lesson from another parent.

However, if LessonIssues were allowed to have null parents, then “moving” one from no parent to a parent would still only be an attach, and therefore couldn’t be prevented by the parent. (unless the parent had a view into the content of the child, which we would want to avoid)

However, maybe this is still all consistent.
If we claim that associations are always owned 100% in the down direction, then attaching a lesson issue to a lesson is not a property of the lessonissue, but of the lesson.
and we’re therefore required to come up with a permissions scheme that makes sense in that context.