Implement cumulative activity updates

[booski]

Feature summary:

• Cumulative update support
• Ability to choose between cumulative or standalone updates at the project level

Research projects need activity updates to build on one another. Imagine the following situation (assuming standalone updates):

Activity template:

• Heading 1
• Heading 2

Update 1:

• Heading 1
  text text text

• Heading 2
  foo foo foo

Update 2:

• Heading 1
  bar bar bar

• Heading 2
  baz baz baz

These two updates can't be presented as cohesive text. They could be presented like this:

• Heading 1
  text text text
  bar bar bar

• Heading 2
  foo foo foo
  baz baz baz

However, this becomes messy since the writer of each update needs to keep track of what was previously written on their own and can't change anything from a previous update to make text flow better or resolve inconsistencies.

A better approach then would be this (trailing + and - denote differences to the previous update/template):

Activity template:

• Heading 1
• Heading 2

Update 1:

• Heading 1
  text text text +
• Heading 2
  foo foo foo +

Update 2:

• Heading 1
  text text text
  bar bar bar +

• Heading 2
  foo foo foo -
  baz baz baz

The final text would then become:

• Heading 1
  text text text
  bar bar bar

• Heading 2
  baz baz baz

Since each update builds on the previous but doesn't change anything in older updates, auditability comes baked in. The final cumulative state of the activity update text would simply be the 'playback' of all the diffs in order. The cumulative state at some previous point in time is just all updates 'played back' up to that date.

The project summary page should show the cumulative state of all existing updates under each activity.
Viewing a single update should show the cumulative state for all covered activities up until that point.

Ability to view more detailed diffs showing what exactly was added and/or removed by a specific update may become important in the future, but is not necessary at the moment. The option should be kept open though.

Each project should be able to choose whether they want to use standalone or cumulative updates. This should be part of project creation.

[pavelsokolov]

It's a bit unclear how to handle it with respect to draft updates i.e. text merge (people can simultaneously create project updates, some of them can remain in draft state with some texts saved). Should we look for some php libraries to support text merge?

[booski]

I've been looking a bit at how mediawiki and moin store their articles. Moin stores the full text of each revision and generates diffs between them on demand. Mediawiki is somewhat unclear to me and the codebase is huge, but it seems to follow a similar concept. So storing the full text of each update and diffing them on demand to see what has changed is probaby a good way to go. Automatic merging of stored diffs would be nice in theory, but merge conflicts etc would make things complicated in a hurry.

If implemented that way, the details page of each update should be able to present a diff to the previous update via some mechanism, but implementation of that feature can wait until the research milestone.

There is an edge case here that will need handling in some way: If someone starts an update and saves it as a draft, then someone else writes and commits their update, the draft will not reflect the latest changes. Not sure how to approach that, maybe for now disallow new updates on an activity that has a pending draft.

This library for making diffs in php looks promising, but there are probably others: https://github.com/jfcherng/php-diff

[pavelsokolov]

Derived diff aspects to #32, so closing this.