Issue #3005678 by Kingdutch: Loading the CsvEncoder as a service causes the user export to be broken (#1056)

Issue #2998991 by ribel: Add default settings for anonymous event enrollment

Issue #2992009 by truls1502: Properly namespace Behat test context classes

#2938410: See more threads in Social Private Message Inbox 3.x

After a remark from one of our customers we've discussed what to do
with the texts in the anonymous enrollment feature. We have decided
to continue using the term "anonymous enrollment" and "anonymous
user" for our settings page because it corresponds to documentation
and is in line with other screens that are available to the site
manager.

For 'regular' platform users we've gone with "Sign up as Guest"
for people that are not already a member of the platform. When
creating an event we've chosen the term "Allow users to enroll for
this event without creating an account" because using the phrasing
"Allow users to enroll as guest" may confuse the user into thinking
that the checkbox controls all user enrollment for that event.

The tab for "Anonymous enrollment" has been renamed to "Guest
enrollment" because the enrollments are not anonymous (people fill
out user info) but they are guests to the platform.

The warning message for when anonymous enrollment is enabled for
an event but the visibility of the event is changed from public to
something else has been revised to be in line with the wording of
the checkbox itself: "without account".

Bram ten Hove authored Oct 04, 2018 and Bram ten Hove committed Oct 04, 2018

IE explorer svg issue

Bram ten Hove authored Oct 04, 2018 and Bram ten Hove committed Oct 04, 2018

2938410: See more threads in Social Private Message Inbox

Bram ten Hove authored Oct 04, 2018 and Bram ten Hove committed Oct 04, 2018

3000480: Mobile login icon invisible

3002541 by slowflyer: Buttons in hero section on landing pages

Issue #3003810 by Kingdutch, bramtenhove: Inconsistency in the way comments are unpublished

#2992332 by ronaldtebrake: Default visibility fix for Open Groups

Issue #3002475 moving content between groups

Issue #3000445 by mathew.oakes: Incorrect grammar on group delete message

Issue #2999042 by Omar Alahmed: Undefined index: #plugin_id

Platforms that are based on Open Social but have more than just the
core distribution often add custom fields to Entities that are
required. This causes an issue when the platform tries to use the
Open Social tests to verify that basic functions still work because
those required fields cause validation errors when creating test
content.

To solve this we add a dummy step that those platforms can overwrite
to fill in those custom values for the distro tests which should
lead to a reduction of duplicated tests.

This is the result of the code review that was done by Natasha.

We ended up on using `event organiser(s)` because this was in line
with the functionality that could be provided by the Event Organiser
module. It was most fitting for the first setting and was then
consistently applied to the other settings.

Issue #3003810 by bramtenhove, Kingdutch: Ensure proper behaviour for unpublished comment reply links

The reply link was displaying incorrectly. In the proper logic for
this code the link is set to an inactive display when a comment is
unpublished. Then the normal logic runs to determine whether to show
the link (or unpublished placeholder) at all.

This ensures that the word "Reply" is only shown in the correct
places and ensures that a comment's structure is always the same
whether it's published or not. This is the desired UX that was
determined by Xinyu.

The author field of a comment also contains the published status and
the social_comment module contains a function to hide all other fields
but the published status. This commit ensures that the published
status field is visible as part of Issue #3003810

As part of the comment moderation we've decided to make the submit
button of a comment edit field a primary button (it's also the
primary action). This is now also done for the post_comment button
as part of Issue #3003810.

Comments on posts can not be a reply to another comment on a post.
Thus a comment on a post can never have a parent. The demo content
contained a comment for a post with a parent which caused a hard
to debug bug in the social_mentions module that was discovered while
working on issue #3003810.

As part of Issue #3003810 some investigation was done into the
differences between post comments and other comments. It was found
that the post-comments have a separate template but do not have any
changes (only lack thereof) with respect to the regular comments.

This is required for sitemanagers and contentmanagers to be able
to unpublish comments.