Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-24119

Reusable Field Groups with permission support

    Details

      Description

      The general idea here is to finally make Field Groups a native feature, but when doing so:

      • Make Field Groups native, to be managed from UI via API's
      • Introduce Field Groups permissions (content/read and content/edit / content/create? )
      • TBD: Make sure one content type can reuse a group from another one
        • Use this to help force content modeling cleanup

        Issue Links

          Activity

          Hide
          Bertrand Dunogier added a comment - - edited

          I'd like to prioritize the permission by field group aspect at some point. It is a useful feature. Some people have asked about it. No emergency, but maybe we could do a first spike about it so that we at least have a more serious estimate of the effort.

          According to Andrzej Longosz, it sounds feasible. We could dig a little and see if it seems possible. It would give a lot of flexibility to content designers, as different attributes of types can be managed by different persons. It avoids having to create related content types to prevent information from being seen. It would also benefit the REST API.

          Sylvain Guittard / Łukasz Serwatka could we find some time for it ?

          Show
          Bertrand Dunogier added a comment - - edited I'd like to prioritize the permission by field group aspect at some point. It is a useful feature. Some people have asked about it. No emergency, but maybe we could do a first spike about it so that we at least have a more serious estimate of the effort. According to Andrzej Longosz , it sounds feasible. We could dig a little and see if it seems possible. It would give a lot of flexibility to content designers, as different attributes of types can be managed by different persons. It avoids having to create related content types to prevent information from being seen. It would also benefit the REST API. Sylvain Guittard / Łukasz Serwatka could we find some time for it ?
          Hide
          Bertrand Dunogier added a comment -

          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.

          Show
          Bertrand Dunogier added a comment - 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.
          Hide
          Sylvain Guittard added a comment -

          First of all, I like this feature.

          Some people have asked about it.

          Any use case in particular?

          I think it's a big change and will require a lot of design updates on multiple interfaces: content type edit, content edit, role limitations.
          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.

          Show
          Sylvain Guittard added a comment - First of all, I like this feature. Some people have asked about it. Any use case in particular? I think it's a big change and will require a lot of design updates on multiple interfaces: content type edit, content edit, role limitations. 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.
          Hide
          André Rømcke added a comment - - edited

          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.

          Show
          André Rømcke added a comment - - edited 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              André Rømcke
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: