Squidex Status field behavior with different X-Unpublished header value

Support
1

I have an issue with getting the current status of the Content item.

I’m submitting a…

[X] Bug report

Current behavior

When I send a get request with an ID parameter to get a particular item from Squidex > Content section, I get a few fields that are related to the status:

{
  status: "Published",
  editingStatus: "Published"
  newStatus: ""
}

Test cases
The Content item was Published and then was created a new Draft from this published version.
image

  1. GET request sent with X-Unpublished equal to false.

Result:

{
  status: "Published",
  editingStatus: "Published",
  newStatus: ""
}
  1. GET request sent with X-Unpublished equal to true.

Result:

{
  status: "Published",
  editingStatus: "Draft",
  newStatus: "Draft"
}

Expected behavior

I expect that when I send a request to get the latest Published version with X-Unpublished equal to false of the Content item that is now in Draft, it will respond with the correct current Status. For example:

{
  status: "Published",
  editingStatus: "Draft",
  newStatus: "Draft"
}

Because now I have to send several requests:

  1. to get the current status (X-Unpublished equal to true)
  2. to get the latest Published version (X-Unpublished equal to false)

Environment

  • [ ] Self hosted with docker

Version: 13.0.0

Browser:

  • [ ] Chrome (desktop)
2

Because of the feature with draft content, each content item has 2 data objects:

  1. The main data ( = status)
  2. The new version data ( = newStatus) (not always there)

This can be very slow, because some users have very large data objects of several megabytes and it is just doubled.

Therefore 2 content collection exists:

  1. A collection with published content, which is usually used for all API requests.
  2. A collection with all content items, which is used for the Management UI.

The X-Unpublished header only tells the API to use the second collection. If you want to restrict that you can use additional requests. There are no plans to change that, because of compatibility reasons.

1 Like