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

ParentDepth Limitation fails on content creation

    Details

      Description

      Steps to reproduce:

      Prepare environment:

      1. On "Users", create User Group "TestGroup";
      2. Inside "TestGroup", create user:

      username: test
      password: publish
      

      3. On "Roles", create role "Role", and enter it by clicking its link;
      4. Add policies:

      Module  |  Function     |  Limitation
      user      |  login          | No limitations
      content |  read          | No limitations
      content | versionread  | No limitations
      content |  create    | ParentDepth ( 3 )
      

      5. Assign the role "Role" to usergroup "TestGroup";
      6. On default landing page content "eZ Platform", create a folder content "FolderRoot" (will have depth=3);

      Test "ParentDepth" limitation:

      1. Logout as "admin" and login as "test" (you may need to reload the app after login to display the username on admin correctly);
      2. Open Firebug or similar dev tools and go to Network tab or wherever you can check HTTP Requests and Responses;
      3. On default landing page content "eZ Platform", try to create another content and publish it. You should not be able to, and you should see a notification:
      An error occurred while publishing the draft
      and dev tools Network tab shows permission "POST 401" error "User does not have access to (...)";
      4. Inside "FolderRoot", try to create another content (folder, for instance), and publish it. You should be able to (since you're trying to create under the parent depth you specified exactly, but instead, you'll still get (the same error):

      PUBLISH 401 Unauthorized
      

      - Params:
      {"ContentCreate":{"ContentType":{"_href":"/api/ezp/v2/content/types/1"},"mainLanguageCode":"eng-GB","LocationCreate":{"ParentLocation":{"_href":"/api/ezp/v2/content/locations/1/2"},"sortField":"PATH","sortOrder":"ASC"},"Section":null,"alwaysAvailable":true,"remoteId":null,"modificationDate":"2015-12-14T16:25:21.645Z","fields":{"field":[{"fieldDefinitionIdentifier":"name","fieldValue":"Meh"},{"fieldDefinitionIdentifier":"short_name","fieldValue":""},{"fieldDefinitionIdentifier":"short_description","fieldValue":{"xml":"<section xmlns=\"http://ez.no/namespaces/ezpublish5/xhtml5/edit\"/>"}},{"fieldDefinitionIdentifier":"description","fieldValue":{"xml":"<section xmlns=\"http://ez.no/namespaces/ezpublish5/xhtml5/edit\"/>"}}]}}}
      

      - Response:
      ErrorMessage:Object
          _media-type:"application/vnd.ez.api.ErrorMessage+json"
      	errorCode:401
      	errorMessage:"Unauthorized"
      	errorDescription:"User does not have access to 'create' 'content' with: parentLocationId '2', sectionId '1'"
      

      which is the same that would happen exactly if you'd try to publish under a depth which would otherwise be not permitted.

        Issue Links

          Activity

          Hide
          Rui Silva (Inactive) added a comment -

          Updated issue description to reflect correct interpretation from here, of how this limitation works. A different interpretation was being considered.
          Nevertheless the limitation itself still fails as described.

          Show
          Rui Silva (Inactive) added a comment - Updated issue description to reflect correct interpretation from here , of how this limitation works. A different interpretation was being considered. Nevertheless the limitation itself still fails as described.
          Hide
          Yannick Roger (Inactive) added a comment -

          Here is the result of my investigation:
          The ParentDepthLimitation requires Targets, basically the location where the content is being created, or it won't allow access: https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Limitation/ParentDepthLimitationType.php#L105

          The problem is that it is not provided (and doesn't seem available) when called in the content service: https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Repository/ContentService.php#L1422

          André Rømcke Does it sound like a valid explanation? Would you have leads on how to fix this?

          Show
          Yannick Roger (Inactive) added a comment - Here is the result of my investigation: The ParentDepthLimitation requires Targets, basically the location where the content is being created, or it won't allow access: https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Limitation/ParentDepthLimitationType.php#L105 The problem is that it is not provided (and doesn't seem available) when called in the content service: https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Repository/ContentService.php#L1422 André Rømcke Does it sound like a valid explanation? Would you have leads on how to fix this?
          Hide
          André Rømcke added a comment -

          Yes, that sounds plausible, and if so a similar solution to what was done in the other location related limitations can be used: https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Limitation/LocationLimitationType.php#L142

          Show
          André Rømcke added a comment - Yes, that sounds plausible, and if so a similar solution to what was done in the other location related limitations can be used: https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Limitation/LocationLimitationType.php#L142
          Show
          André Rømcke added a comment - PR: https://github.com/ezsystems/ezpublish-kernel/pull/1703
          Show
          Petar Spanja (Inactive) added a comment - New PR against 6.4 branch: https://github.com/ezsystems/ezpublish-kernel/pull/1706 Merged in: https://github.com/ezsystems/ezpublish-kernel/commit/7ae302b98dc44f08a65f788891eebc43950bcb70
          Hide
          Rui Silva (Inactive) added a comment -

          Tested and approved by QA for master.

          Show
          Rui Silva (Inactive) added a comment - Tested and approved by QA for master.

            People

            • Assignee:
              Unassigned
              Reporter:
              Rui Silva (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: