Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Apostrophe versions] authorId and author fields is null for aposDocVersions #2243

Open
okfmohamed opened this issue Jul 13, 2020 · 9 comments
Labels

Comments

@okfmohamed
Copy link

okfmohamed commented Jul 13, 2020

To Reproduce

Step by step instructions to reproduce the behavior:

  1. Download and install the Apostrophe Open Museum project from:
    https://github.com/apostrophecms/apostrophe-open-museum
  1. Add various content types from the back end modal using the open museum project.
  1. Edit any content type and click on More/Versions:
  1. Few versions are missing the user title and instead of displaying the message: _ admin made changes on DD/MM/YYYY_ it display as: made changes on DD/MM/YYYY

Expected behavior

The user title should always be displayed for each content type in the versions modal as only logged in users should be allowed to edit and make changes to the back end content using the modal

Describe the bug

The authorId and author fields are not always saved as the current logged in user and in many instances they are instead saved as null in the aposDocVersions collection for many documents:

image

Details

Version of Node.js:
v12.14.0

Server Operating System:
Linux (Ubuntu 18x) while no Docker is installed

Additional context:

The same issue can be replicated across different browsers and different devices (OS)

Screenshots

image

Mongo DB Dump

This DB dump shows all aposDocVersions documents where the authorId and author fields is null for out of the box Git Hub Apostrophe boiler plate installation and no extra configuration. So far there are about 20 reported entries while in some other Prod sites the number of authorId and author fields null records can reach +200k entries.

Also this dump has more recent entries than the one showed in the screen shot.

Attached:

mongodb.zip

@okfmohamed okfmohamed added the bug label Jul 13, 2020
@okfmohamed okfmohamed changed the title [Apostrophe versions] authorId and author fields are saved as null for aposDocVersions collection [Apostrophe versions] authorId and author fields is null for aposDocVersions Jul 13, 2020
@boutell
Copy link
Member

boutell commented Jul 13, 2020 via email

@okfmohamed
Copy link
Author

@boutell

Thank you so much for your reply

I will try to replicate the issue as I still don't fully understand how it happens but for now I can see from the date stamps in the DB dump that some of these entries are more recent than the one on the screen shot

@okfmohamed
Copy link
Author

@boutell

Can this be caused by:

const req = apos.tasks.getAnonReq() OR

const req = apos.tasks.getReq()

@okfmohamed
Copy link
Author

@boutell

Again I only used Apostrophe git Hub project with no custom configuration

@okfmohamed
Copy link
Author

Do you think it is better to add place holder for the req object if the author field wasn't an actual user req object instead of showing it as empty?

@boutell
Copy link
Member

boutell commented Jul 14, 2020 via email

@okfmohamed
Copy link
Author

Okay thanks for the update though don't you think that as version log it should show all users making any changes to the back end content? These users don't have to be always logged in users but they can be 3rd party APIs or command line tasks

I think it would be much much better user experience that if no actual user is present in the context it would default to the name of the task that created that content so per say it could be (command line task, API request...etc) and that could be overridden on project level code to include any custom name and that would only be the case as well if there was no actual user object

Also back end users will never know why the user title was missing besides this would be very good thing to narrow down the scope of the issue as I can't tell now for sure if this is a bug or it is just code improvement/tweak?

@boutell
Copy link
Member

boutell commented Jul 14, 2020 via email

@boutell
Copy link
Member

boutell commented Jul 14, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants