We need a fixed-width CSS table with a number of fixed-width
cells and one cell that takes up the remaining width, with
text truncation. This is a pain to do with CSS tables,
but this trick I found on StackOverflow[1] works well:
wrap the contents of the cell in a div that's position: relative;,
containing another div that's position: absolute; width: 100%;
[1] http://stackoverflow.com/questions/7569436/css-constrain-a-table-with-long-cell-contents-to-page-width
Bug: T140349
Change-Id: I507f915f06185c767d7a5c8edbff6c341e07b6e2
Check it for both $wgUser and $this->user because they
could theoretically be different.
Bug: T139665
Change-Id: I59cb4f0122a9fccb32ca165fda065dee2467b1da
When we are viewing a certain read state filter ('read' or 'unread')
the visibility of items should correspond to that state even when
the user marks a specific item as read/unread. That means that the
system should remove these items from view when the action is taken.
In this commit:
* The controller makes the judgment of whether to remove items when
read/unread action is taken, based on whether a filter is set.
* We clean up the terminology of discard - no more 'remove' - to
make sure we have consistency in the code.
* Related: The 'discard' event is now scoped within the hierarchy;
meaning, lists emit 'discard' when an item is removed, grouplist
emits 'discard' when a group is removed, and the manager emits
'discard' when an entire notification model is removed. This
means we can actually have proper hierarchy and organization with
a single event, and not worry about clashing between the intentional
'discard' action and the event 'remove' that is also used while
resorting happens.
* The model manager emits a discard event when a model is removed
so that the general list can listen to the manager and remove an
entire batch of items if needed.
* The pagination model now updates the count for the current page
rather than some vague notion of the last page. This is also
updated when the controller removes items, so we can get an
accurate count in the page for the number of notifications that
are displayed.
Bug: T136891
Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
This organizes the operation of seenTime so we can store and
follow up on it based on different sources, as well as update
it correctly remotely when needed.
Change-Id: I629ecfc84999be998b45c9c7adb00ea7e3e51742
If we have a central ID, in theory it should not trigger
CA failures when getting a token. However, it is, so maybe:
* This is the wrong way of checking attached-ness.
* It is somehow losing the central ID later.
or something else is going on.
Bug: T140144
Bug: T119736
Change-Id: I71c6f121a728e503aa9d62778e64c650cd8d46af
Attempting to get a CentralAuth token for an unattached
user (or a user mid-attachment) throws an exception.
Bug: T119736
Change-Id: I2a34754f55b952f5bcd4da6c6f89a32ebc29ecf1
This would make the wiki names localized to the current user
interface language, rather than the wiki language.
Bug: T139807
Change-Id: I2b787e1486819d6833e169ac6db519cd36a3c3eb
The message for tooltip-pt-notifications-message was removed to comply
with the new naming. The problem is that in the back end, sections are
still defined as 'message' vs 'alerts' and the sections in the user
toolbar are defined with those terms. In no-JS mode (which is before
the user clicks any of the badges) this tooltip is created automatically
by MediaWiki based on class names.
It's easier to return the message key with different text for translation
and wait for the bigger tech debt to correct all instances of 'message'
to 'notice' (including in the API, which would require a much more
massive work)
Bug: T139520
Change-Id: I6368b63e38f64aa065f2580df812de1c63a93716
