In PHPUnit 9.1, the following regexp-related assertions
have been deprecated and there are new alternatives for
all them:
- assertRegExp() -> assertMatchesRegularExpression()
- assertNotRegExp() -> assertDoesNotMatchRegularExpression()
This is about to, simply, move all cases to the new alternatives.
Source: https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md
Regexp to find all them:
ag 'assertRegExp|assertNotRegExp' -li
Both assertContains() and assertNotContains() are deprecated in PHPUnit 8
for operations on strings. Also the optional case parameter is. All uses
must be changed to one of:
- assertStringContainsString()
- assertStringContainsStringIgnoringCase()
- assertStringNotContainsString()
- assertStringNotContainsStringIgnoringCase()
More info: https://github.com/sebastianbergmann/phpunit/issues/3422
Regexp to find all uses:
ag 'assert(Not)?Contains\('
Added new MESSAGE_CONVERSATION_TYPE_SELF type for self-conversations
and upgraded legacy self-conversations to the new type, removing
repeated members in the message_conversation_members table.
Besides, from now, a self-conversation will be created by default for
all the existing users.
All the self-conversations have been also starred and a default message
will be displayed always to explain how to use them.
We need to be able to delay calling all member processors with localised
event data if a DB transaction is taking place. This code treats a
conversation message as a single item of work to be buffered, and stores
all localised eventdata, and processorlists for later reference. When
processing the buffer, we pass off all localised eventdata items to
their respective member's processors, before firing a single event.
Before this patch, we only checked that the given provider has been
configured in the user or system preferences. However, if the provider's
component is disabled, it does not even appear in these preferences.
Additionally, there was no check that the message / notification
provider is among providers allowed to be consumed by the recipient.
The patch checks that the message origin is among providers returned by
the message_get_providers_for_user() so disabled plugins can't act as
sources of messages and users can't receive messages from providers they
do not have capability for. This mitigates the risk of abusing a plugin
as a source of spam, for example.
Unit test is fixed and extended. When the $CFG->messaging is disabled,
no messages between users should be sent (I can't understand why the
unit test was written in an opposite way). Added assertions for the
raised debugging message.
Also deprecated the following functions -
1. message_move_userfrom_unread2read - It is not necessary
for us to mark a message as read on user deletion.
2. message_get_blocked_users - Horrible logic used to
determine if a user is blocked via reference on some
randomly chosen 'isblocked' variable.
3. message_get_contacts - The same as above. This can be
done in a much nicer way.
4. message_mark_message_read - We want two functions to do
this to avoid confusing messages and notifications.
5. message_can_delete_message - This assumed the variable
$message contained the 'useridto' property, which
was present in the old table structure. We do not want
future usages where a query is done on the new table
and is simply passed as this won't contain this property.
6. message_delete_message - Same as above.
This patch includes following fixes:
- messages may be now sent when database transactions active
- consistent return status on failure from message_send(), false is
returned only when message not created in message(_read)? table,
processor failure results in debugging message only and messages
are not marked as read
- message_sent is triggered always with id from message table
- logic for marking messages as viewed was standardised
- message_viewed event is triggered consistently
- improved performance when fetching user preferences
- full unit tests coverage for send_message() function
- fixed multiple other smaller issues discovered by unit tests
Some message providers have an associated capability. For example
the mod/quiz:emailconfirmsubmission capability. At the moment,
we only show the preferences for the capabilities that the user
has in the system context.
That does not work for the example capability above. Typically
the capability will be overridden in one quiz, to allow for
Students, and the user will have the Student role in the course
context. Therefore, this message type does not appear on the
preferences page.
This fix corrects the logic, so that all message types that are
to the current user are displayed.
cescobedo