[SOLVED] Permissions for Content Workflow Status Change

Bugs Solved Bugs
1

I have…

I’m submitting a…

  • [x] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

Before we pulled the latest Squidex, when we moved workflow state for a piece of content it called the content ‘status’ API endpoint which just changed the workflow state for that content,

However once we pulled the latest Squidex from GitHub, moving workflow state for a piece of content now calls the ‘bulk’ API endpoint,

This bulk endpoint requires the ‘AppContents’ permission which means you must give a user all permissions for contents of that schema, thus removing the ability to set granular permissions for that content i.e you can’t set a role so that it can move workflow state but not update or delete content,

Expected behavior

The expected behaviour here would be that moving workflow state does not require all contents permissions, should using the bulk endpoint for moving workflow state not be configurable?

I understand that the bulk endpoint most likely makes a few background API calls (therefore requiring more permissions), but this is quite a big change in the way that permissions work for changing workflow state

Minimal reproduction of the problem

Environment

  • [ ] Self hosted with docker
  • [x] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: [VERSION]

Browser:

  • [x] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge

Others:

2

Thats indeed a bug. The bulk middleware also checks the permissions:

. Therefore we can set the permissions of the API endpoint to read or AppContentsReadOwn.

3

Ah so you are saying that the ‘bulk’ endpoint will require the role to have ‘Read’ or ‘ReadOwn’ permissions (to atleast make the API call),

And then the granular permissions (i.e. ChangeStatus, Update, Delete) will all be validated inside the middleware?

Is this something that you will fix? We can raise the fix for this but will take substantially longer because of our business processes :confused: (for quite a small change from the sounds of it)

4

Yes, I will do it today.

1 Like
5

Pushed. Please tell me if it works for you.

6

Won’t setting the API permission to ‘ReadOwn’ only allow you to change workflow state for your own contents?

7

or will giving ‘Read.Own’ permission implictly give access to ‘Read’?

8

It means you need at least Read.Own permission. If you have Read you also have Read.Own.

9

Ah okay no problem there then,

we’ll do some testing on our side and see if this resolves the issue for us, i’ll post back if all looks good or we spot anything else,

Thanks Sebastian

1 Like
10

I have done some initial testing with a QA and on initial inspection it looks good,

We are going to do a pull from Squidex in the next week or two and will do more extensive testing on this to make sure there are no regression problems,

We will update if there is anything else we find

(Just out of interest, how often do you tag Master? We are currently pulling tags of Master but wouldn’t be able to pull this until there is a new tag)

1 Like
11

Check the release history. I do not have a plan for that.

12

This topic was automatically closed after 2 days. New replies are no longer allowed.