[VIVO-1545] Tracking of user changes to the content store

[grahamtriggs]

VIVO-1545: (please link to issue)

What does this pull request do?

The pull request adds a module that enables tracking of changes being made in the triple store by users through the Vitro user interface.

Changes are recorded in a triple store, with the users ID (URI), the time, and the changes that have been made.

A user interface (/audit) is also provided that, when logged in, displays the changes that have been made by that user.

What's new?

Adds a new AuditModule application module
TDBAuditModule can be configured / enabled via the applicationSetup.n3
A servlet request listener and RDFService change listener work in tandem to capture any changes made to the content store, and record those changes in a dedicated TDB store.

How should this be tested?

An unmodified applicationSetup.n3 should result in no changes to the application behaviour / home directory.
Adding the TDBAuditModule configuration to applicationSetup.n3 will:

• create a TDB store in the file system (the recommendation is to be "tdbAuditModels" within the Vitro home directory)
• Any modifications to the data (e.g. editing a Person's overview) will result in the changes being logged in audit TDB store, but otherwise there will be no difference to the perceived behaviour of the application.
• Whilst logged in, accessing /audit will show the changes that the logged in user has previously made

Everything else about the application should operate normally - every request will be going through the servlet request listener, but it will not be doing any work when there is no logged in user / changes made to the content store.

Additional Notes:

As it is adding a listener to the RDFService, this change will only work without side effects when the (already merged) change to do a stream reset inside the loop is present:
#79

Interested parties

@VIVO-project/vivo-committers

[awoods]

Instead of adding more code to the codebase, does this new feature represent an opportunity to have a pluggable, external library, optionally wired into Vitro?

[j2blake]

@awoods I like your idea, but how do we generalize it? Would it be feasible for this to become:

• a separate repo/codebase within the vivo-project?
  • or within vivo-community?
• a Maven artifact that could be optionally included in pom.xml by the VIVO administrator/installer?

What other portions of the VIVO codebase would be eligible for this sort of partitioning?

• The Data Distribution API?
• The Elasticsearch driver?
  • or perhaps the Solr 7 driver, if Elasticsearch becomes the default

Graham has already pointed out the perils of circular dependency, in relation to the Data Distribution API. We would need to make changes to the build script, so modules like these would be dependent on the vitro-api artifact, and then VIVO would be dependent on the result.

Food for thought...

[awoods]

@grahamtriggs : thoughts?

[gneissone]

Reopening this pull request. In an effort to follow current best practices, the VIVO project will now be developed against the master branch. As a result of removing the develop branch, this pull request was automatically closed by GitHub, apologies for any confusion this may have caused.

[litvinovg]

I think this PR should be closed because the approach of synchronizing the servlet request listener events and the RDFService change listener events by time will not work reliably.