Have you ever noticed there is at least one entity in the Model-Driven apps (and in Dynamics before) which would sometimes claim a form is read-only, but which would still be somewhat updatable in the user interface?
Even more, this peculiar behavior may not be easily controlled through java scripts.
See, you can update “Regarding” field on the completed emails, even though the form will be telling you that the record is read-only:
What will happen as a result is that you’ll see “unsaved changes” notification in the status bar:
Even though you won’t see the usual “save” button there.
However, eventually “Autosave” will kick in and updated “regarding” will be saved. Or you could also use CTRL+S to save the changes right away.
That seems to be a bit of user-interface inconsistency, but there is a good reason for why “regarding” is not made read-only (even if the implementation feels more as a workaround). When an email comes in, and if it does not get linked to the right record, you may still want to change “regarding” on such an email even though it’s already been marked as “received” (or, possible, as “sent”).
One might argue that it’s no different from how other entities works, and we just need to re-activate them in such cases. However, it’s a little more complicated with emails since we can’t easily reactivate an email (I guess this is because, otherwise, it would turn into a mess really quickly if somebody tried to send an email that had already been sent etc)
While it appears to be contradictory to a developer I might suggest that regarding vs body is the difference between CRM and evidence.