Bug #13101

When "Enable description change logging" is set to "yes", all Description updates are hidden

Added by Corinne Rogers about 2 years ago. Updated almost 2 years ago.

Status:FeedbackStart date:06/26/2019
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:Description updates
Target version:-
Google Code Legacy ID: Tested version:2.5, 2.6
Sponsored:No Requires documentation:

Description

To recreate:
In Settings, ensure that "Enable description change logging" is set to "no"
From Admin tab, look at "Description updates" and ensure that there are updates visible (if not, create some updates to descriptions)
Return to Settings and change "Enable description change logging" to "yes", and save
Go back to Description Updates and observe that all updates are now not visible

Expected behaviour: description updates remain visible when description change logging is on.

History

#1 Updated by Dan Gillean almost 2 years ago

  • Category set to Description updates
  • Status changed from New to Feedback

This has turned out to be more complicated than a simple bug fix. From Mike Cantelon:

Basically when audit logging's turned off, the updates page looks at the ElasticSearch index to get create/last update times. When the audit log's turned on, the updates page looks at the MySQL audit log table to get create/update times. With the audit log multiple updates can be tracked (rather than the last update) as well as the user who performed them.

[The Description updates page] works with two different datasets with different granularity. Given that we could add logic to, when audit logging's enabled, prepopulate the MySQL audit log based on what's in ElasticSearch.
Or we could just tell the user, when they're enabled audit logging, that only updates done with audit logging enabled will be visible on the updates page, etc

David J has responded with some further thoughts:

A decision needs to be made about how to resolve the MySQL/Elasticsearch split before this feature can be worked on. It also needs an estimate of time required.

Also, Mike's suggestion of adding the data from Elasticsearch to the MySQL audit log seems backwards to me, for several reasons:
1) MySQL is our primary data store, there should not be any data in Elasticsearch that is not already in MySQL.
2) The audit log has more data about the history of changes to an archival description than is available in Elasticsearch
3) Elasticsearch is faster for reporting on aggregate data than MySQL, so it should be used for the audit log reporting in preference to MySQL.

I personally agree with David - we moved Description updates to use ES in version 2.4 specifically for scalability and performance reasons, and shouldn't undo that work. Rather, it would be better to add the missing data to the index and use ES for all queries, regardless of setting.

To determine if we can get this into an upcoming release, we'll need some time estimates for that. Work involved would include:

- update ES index for descriptions to be able to include all audit log info - usernames, modification dates, etc.
- update Description updates to use ES when audit log is enabled
- testing, esp. to confirm that reindexing will solve issues for any 2.5.0 users running into this issue

Also available in: Atom PDF