webiny/webiny-js

⚒️ HCMS Revision vs Entry Dates and Identity Fields Update

m0nikaza opened this issue · 0 comments

We decided to make a change to what dates and owners/actors ids in our GQL API and make the distinction between HCMS revisions and Entries a lot clearer. In this way we are hoping to improve you experience with Webiny and ensure that you have all the information you may need to sort/filter and perhaps pull content dynamically from our HCSM. Currently we have these fields. They will be slowly deprecated:

  • createdOn - the first time when a revision of the record is created or equivalent
  • savedOn - the last time when the record was changed or equivalent
  • modifiedOn- set upon modifying (not creating) a revision
  • publishedOn - the last time when the record was published or equivalent
  • createdBy - this is the creator of the latest revision
  • modifiedBy - this is the last person who modified the latest revision
  • ownedBy - this is the person who first created the entry
  • publishedBy- set upon publishing a revision

In 5.39.0 we will introduce the following fields:

Revision-level Fields

All of the fields listed in this section contain info tied to a specific revision of a content Entry.

xOn Fields

  • revisionCreatedOn 🆕 - set upon creating a revision
  • revisionModifiedOn🆕 - set upon modifying (not creating) a revision
  • revisionSavedOn🆕- set when a revision is created or modified, but not when it is published
  • revisionPublishedOn🆕 - set upon publishing a revision

xBy Fields

  • revisionCreatedBy🆕 - set upon creating a revision
  • revisionModifiedBy🆕 - set upon modifying (not creating) a revision
  • revisionSavedBy🆕 - set when a revision is created or modified, but not when it is published
  • revisionPublishedBy🆕 - set upon publishing a revision

Entry-level Fields

All new fields. Unlike with the above fields, these are tied to the whole entry, not to a specific entry revision.

xOn Fields

  • entryCreatedOn🆕 - set upon creating entry (first revision) and propagated to all future revisions
  • entryModifiedOn🆕 - check Additional Notes
  • entrySavedOn🆕 - check Additional Notes
  • entryFirstPublishedOn🆕 - never changes, it's the DT when the entry was first published
  • entryLastPublishedOn🆕 - it's the DT when the entry was last published

xBy Fields

  • entryCreatedBy🆕 - set upon creating entry (first revision) and propagated to all future revisions
  • entryModifiedBy🆕 - check Additional Notes
  • entrySavedBy🆕 - check Additional Notes
  • entryFirstPublishedBy🆕 - never changes, it's the identity that first published
  • entryLastPublishedBy🆕 - it's the identity that last published

Why is this a breaking change that requires manual adjustment? We will provide the automatic migration for you as part of the upgrade process. All existing date and ID fields content will be saved in the new corresponding field. However, if you have built custom code that uses one of the fields to be deprecated, you will have to manually adjust this code and add the new field there. If you have any questions on this change, please either comment here or get in touch on Slack.