Changes

The main purpose of this PR is to introduce new xBy and xOn entry meta fields for all CMS entries.

More specifically, instead of just having revision-level meta fields (createdBy, ownedBy, modifiedBy, createdOn, savedOn, publishedOn), each CMS entry now has revision and entry level fields:

• revision-level fields are updated on each update of a revision
• entry-level fields are updated on an update of any revision of an entry

With this, there are additional changes that this PR brings. More in the following section.

Other Changes

1. Eight Publishing-related Fields

Instead of having just a single publishedOn field, CMS entries now have eight publishing-related fields that users can use accordingly:

• revisionFirstPublishedOn
• revisionLastPublishedOn
• revisionFirstPublishedBy
• revisionLastPublishedBy
• entryFirstPublishedOn
• entryLastPublishedOn
• entryFirstPublishedBy
• entryLastPublishedBy

2. Improved Meta Fields Consistency

Prior to this PR, a CMS entry did not have savedBy but had savedOn. It also did not have modifiedOn, but did have modifiedBy. By adding the missing savedBy and modifiedOn fields, this inconsistency has now been resolved.

3. Simplified Overriding of Publishing-related Meta Fields and Instant Publishing

ℹ️ INFO
The functionality described in this section is needed for data migrations, where users are migrating data from one system to Webiny.

Prior to this PR, if a user wanted to create an entry with an already set published date, the user would need to first create an entry with the published date, and then publish the record with a special updateSavedOn and updatePublishedOn flags set to false. In other words, two GraphQL mutations would need to be performed.

With this PR, this process is simpler. The user now can achieve the same thing with a single GraphQL mutation, where they just set the status field of an entry to published, and set the publishing date. No need to call the subsequent publish mutation.

4. ACO, FM, APW Also Using New Fields

The three apps that rely on HCMS (ACO, FM, and APW) to store data were also revisited and updated accordingly.

In short, on GraphQL/SDK levels, users still use the regular createdOn, createdBy, modifiedOn, ... fields. But, behind the scenes, these fields are actually mapped to entry-level fields, so: entryCreatedOn, entryCreatedBy, entryModifiedOn, ...

This is fine because all of the records within the three apps do not use revisions. They are all working with the first revision of an CMS entry and never publish anything.

5. ACO Filters - Using Revision IDs instead of Entry IDs

While testing, I noticed the new Filters ACO entity works with entry IDs. At first, it looked fine, but then I noticed that when getting entries, we have to rely on getEntry call instead of getEntryById call. This is problematic because the getEntry behind the scenes actually performs a listEntries call. Meaning, in DDB+ES systems, the query would be ran against ES. In order to make this more performant, we need to use getEntryById, and that also means we need to work with revision IDs, not with entry IDs.

6. Refactored createEntry.crud.ts File

Overtime, the createEntry.crud.ts file has grown into a file with ~2300LOC. This introduces clarity problems, and increases the possibility of merge conflicts and bugs.

It'd be time consuming to refactor everything, so I just chose one single thing and that is the code that deals with the creation of const entry = { ... data within different CRUD methods. Ended up extracting const entry = { ... data preparation code for six different CRUD methods, which is now placed in six separate files:

createEntryData.ts
createEntryRevisionFromData.ts
createPublishEntryData.ts
createRepublishEntryData.ts
createUnpublishEntryData.ts
createUpdateEntryData.ts

Ultimately, this reduced the LOC from ~2300 to ~1500. Not to mention that the actual createContentEntryCrud function now starts on L98, which was previously L260.

7. useTestModel Testing Utility

During writing tests, I created a simple useTestModelHandler handler that works with a simple model with just title and slug fields, which enables us to test some of the more simple use cases.

It exposes both manage and read API methods, and additionally the setup method that sets everything up for the user (creates the content model group and the actual content model). No need to import another utility (setupGroupAndModels) in order to do this. Example usage can be found in four new test files, one of which is packages/api-headless-cms/tests/contentAPI/contentEntriesOnByMetaFieldsQueries.test.ts.

8. Added jest-extended NPM Package

The jest-extended package is a collection of often used matchers, like for example toBeDateString

9. Introduced yarn webiny open Command

In order to access the Admin/Website apps more easily, users can now simply run yarn webiny open admin --env xxx or yarn webiny open website --env xxx. No need to get the URLs via yarn webiny output or yarn webiny info commands and then click the URL or manually copy/paste it into the browser.

How Has This Been Tested?

Jest.

Documentation

• changelog
• upgrade notes
• dedicated article on meta fields