Not sure this will fit for the next sprints, but we (PMs) can work on it in order to have a clear scope for the spike
It's indeed big, at this point it makes far more sense as a 3.x scope both because of the resources it will take, and because of the db changes it will need.
André Rømcke I'm not sure I get the immediate benefit of a closer integration of groups. Do you refer to the fact that they're just identifiers, and require configuration ?
We could indeed improve that. On the other hand, it isn't really coupled to permissions, does it ? As long as we have defined the API for it. We have an identifier, we should be able to work with that.
I'm not sure I follow at all here. One of the major points here is to finally be able to provide field permissions, but on a more suitable/manageable level of the content model: the field groups.
PS: On possibility is that field group definition should be file (php) based, so it can be deployed with code. Implying things like identifiers and if set also field validation values can not be set in UI, This would allow us to introduce deployable content type definitions once we have support for migration, but still allowing UI to edit /add fields to standard field group. While php based once are the once reusable across content types, and which implicit imply a domain.