Do not return Draft content items when setting X-Unpublished header

Support
1

I added a custom workflow status to my Squidex app to differentiate between internally and externally published content items. For internally published content items I introduced a new status called “Published internally”, for externally published content items I am using the built-in “Published” status.

On a specific page in my application, I want to query content items that have either status “Published” or “Published internally”. Since Squidex by default only returns content items that are “Published” when querying the data using the API, I have to use the X-Unpublished header to also return other statuses and add a custom filter to filter these statuses.

I’m submitting a…

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

Current behavior

Currently, when setting the X-Unpublished header, if a new “Draft” version is added of the same content item, the endpoint returns the data of that “Draft” version rather than the latest “Published” version (newStatus equals Draft).

Expected behavior

I am only interested in the “Published” or “Published internally” data, not in “Draft” data. How can I let the endpoint return only “Published” or “Published internally” data when a new “Draft” version is in the works?

Minimal reproduction of the problem

  • Create a new schema item.
  • Create a new custom workflow status “Published internally”.
  • Create a new content item and set status to “Published internally” or “Published”.
  • Create a new “Draft” version of the same content item.
  • Query content items with X-Unpublished header and the following JSON filter:
    {
       "filter":{
           "or": [
               {
                   "path": "status",
                    "op": "eq",
                    "value": "Published"
               },
               {
                   "path": "status",
                    "op": "eq",
                    "value": "Published internally"
               }
           ]
       }
    }

Environment

App Name: -

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

Version: 7.3

Browser:

  • N/A

Others:

2

Interesting problem. The singular Published status seems pretty sacrosanct, so having two statuses that get returned when X-Unpublished isn’t provided doesn’t seem likely to change, although maybe if there was an option when defining a workflow step to “Treat as Published”?

“Draft” itself is just another status like “Internal Only”, you can completely delete it, so I don’t think there will be any bespoke functionality around that status. Having said that if you remove “Draft” from the workflow what happens to the “New Draft” button?

My approach would be to just havve both with the same “Published” status but have a boolean field called something like “Internal Only” and use that to filter what gets shown on each page, however if you have dozens of pages that are only interested in “Published” and just this one that also wants “Published internally” that would be a lot of extra filtering that would be better to avoid.

3

Draft Status is not the same as “Draft Version”. The wording is a little bit confusing, that it is right.

Each content has 2 statuses:

  • The normal status
  • The draft status

So once your normal status is in Published then you can create a new draft, which follows the normal workflow until it is published.

When X-Unpublished is set to true, these draft versions are resolved. So we would need a new header for that.

1 Like
4

Do you have an idea how to name this header?r

5

Hi @slalFe and @Sebastian,

Thank you for your responses. For now I decided to drop the custom workflow status “Published internally” and added a boolean “isExternal” to the schema instead.

Another proposal could be to allow a custom workflow status to have the same behavior as “Published”, such that we do not have to use the X-Unpublished header and the API returns the latest version that is either “Published” or “Published internally”.

1 Like
6

Yes, I guess this would make more sense. It is also more explicit.

1 Like