The converation favourites were previously set in the system context
which is not right, as they should be stored:
- In the conversation context when defined.
- In the user context, when contextid is null (that means is an
individual conversation).
Changed the settings page in the message drawer to display all message
notification processors (e.g. email, mobile, jabber) for the user to
configure based on which processors are enabled on the site.
We were already caching these preferences when a user object is provided
to get_user_preferences, or when $USER is provided.
This changee swaps get_user_preferences to use the global USER object
when the USER->id matches the userid supplied to the function.
If A is related to B, then we should be able to view this relationship
from both badge A and badge B. The following badge methods were updated:
- get_related_badges()
- has_related()
- delete_related_badge()
* providers for paging preferences
* Moved the user pref persistence to the factory
* Added client defined namespace in config
* Define custom client events in the client instead of passing to the
factory
Not all AMD modules need an explicit function call to start working. The
patch makes the function name optional, in which case the js_call_amd()
simply loads the module.
Fix some of the behat tests that are looking for generic button
names that match some of the buttons in the message drawer which
happen to appear earlier in the DOM.
* Added missing icon mappings for font-awesome
* Fixed focus on dialogue button when it opens
* Fixed UI updates on user block / unblock
* Fix jQuery syntax error when sending message with quotes
* Fix message/index.php opening drawer when no conversation found
* Fix placeholders rendered for new requests
This will allow the capability to be applied at a range of contexts and
not just the system, making the system much more definable to a range of
users.
This was originalyl intended as a performance improvement, but the
parent is already stored, and once calculated the value of locked is
already returned.
This chagne adds support for a new feature known as Context Locking.
This allows a context to be locked, thereby removing all write
capabilities for all users (including admin) for that context, and all
child contexts.
