Page should have author/user reference

I don't know what's the best way to store this but based on what we have in the designs, I'm anticipating we'd want to get following information:

1. Who last changed a page (and when)
2. Who created the page (and when)
3. Who published the page (and when)

Would the author/user reference provide us what we need to provide this?

Technically the revision log gives us all of that information, revision log entries always reference a user.

This issue would enable "edit|delete own" and "edit|delete any" permissions.

#2 that would require, respectively:

1. \Drupal\Core\Entity\RevisionLogInterface::getRevisionUser() + \Drupal\Core\Entity\RevisionLogInterface::getRevisionCreationTime()
2. \Drupal\user\EntityOwnerInterface
3. \Drupal\Core\Entity\EntityPublishedInterface in combination with 1

IOW: @mglaman is right.

Based on that, the new content entity type SHOULD extend \Drupal\Core\Entity\EditorialContentEntityBase.

WDYT, @mglaman?

The MR working on adding the entity type already extends Drupal\Core\Entity\EditorialContentEntityBase, so it'll be covered. But not the idea of "owning" a page like node and media already do

I think we should go with the standard permission approach we've taken for entity types in core which as pointed out by #3 requires author/user for the entity. The permissions seem a bit more complex than what may be needed but we would have to go through some extensive thinking to deviate from the existing pattern.

It also makes the standard way of doing "Who created the page" a lot easier (target default data table vs revisions)

Based on #5, this already is done in 📌 Create Page entity type Active ? What is then the scope of this issue? 🤔

This is not done in that issue. This issue is to implement entity owner interface.

Ahhh! I missed that — I thought it was part of EditorialContentEntityBase, but it's not 🙈

#3487071 is in now! 🚀

Ideally we'd be able to reuse EntityOwnerTrait just like Node does.

Not sure how heavy to go into the tests.

Haha, magnificently simple! 👏

As far as I'm concerned, this doesn't need any additional tests — why would we re-test what core already has solid test coverage for? That'd be overkill.

This MR just needs to update some test expectations and then it's ready IMHO.

AFAICT 📌 CI: update to 1.6.3 of the GitLab CI Template Active should make this pass, so merged in origin/0.x to get that here too.

Assuming #15 makes CI pass, this is good to go :)

Seems like E2E test failures in HEAD are causing this to fail as well, see 📌 Remove leftover wait() in empty canvas e2e test Active .

Not mergeable until HEAD is green. The failing end-to-end test can AFAICT not possibly be caused by the changes in this MR.

0.x is green again, so merged in upstream changes and hoping this will now be green too 😄

Only empty-canvas.cy.js failed in the Cypress E2E CI job. That's a known random failure: 📌 Remove leftover wait() in empty canvas e2e test Active . Going ahead and merging! 🚀

Automatically closed - issue fixed for 2 weeks with no activity.