Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Edit styling on message thread page; add from column to notifications and show the correct message authors
Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

When replying to a message from another user, the full message history
is now shown, if it is available (recorded in the database).
Signed-off-by: Evan Goldenberg <evang@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

This gets rid of the PluginNotificationInternal::update_notification method,
which was way overkill for what it actually needs to be. We only actually need
to update the notification if it needs to be marked as read or its URL needs to
change.

Noticed as part of the previous commit. This variable doesn't need to exist on
the object, we can just pass it around where needed.

This was happening because a variable ($userdata->internalid) was being used
for two purposes - one to hold the ID of the notification as put into the
notification table, and also to see if the notification needed to be updated
after having been inserted for any reason (either the notification was sent by
another method successfully so it needed to be marked as read, or the URL set
in the table needed to change post-insert).

The particular method this bug is in is called repeatedly in a loop, once for
each user who is getting a notification. Unfortunately, $userdata->internalid
comes from converting the object to a stdclass, and the previous internalid is
set on the class too. So if the notification didn't need to be marked as read
or have its url changed (e.g. it's a forum post notification going straight to
the activity log), then it would still be updated - this would have been
harmless, but the update would ovewrite the user who owned the notification.

Will make a few more patches to make the code more consise and limit the chance
of more damage. This problem took me hours to debug...

This allows messages to appear to be from a given user instead of from the system itself.

Also add a flag for activity types to choose whether this means exposing the user's email address. Contact Us implements this and shows the address while forum posts hide the address.

This is a much better logical split. Though the whole system is still roundly indecipherable :)

Allow notifications to override the message contents for email notifications entirely if they choose.

Change user message notification url to allow replies
Quote original message when sending a user message as a reply

(cherry picked from commit 823ab316)

artefact_get_viewaccess_users - field in right join used in WHERE clause, causing users to not be notified if they haven't set account preferences.

Also change the quoting on the query in order to remove some backslashes, and a couple of other minor tidyups.

Make the default notification plugin for all notifications types 'email'. This should encourage more use of the system by users.

The name is largely irrelevant as it's only the creator of the file.

Hack to avoid sending multiple watchlist notifications on the same view (doesn't really fix bug 1879)