Otherwise, if $list->getValues() contains the number 0,
any non-numerical string will match, because 'foo'==0 is true.
This, in combination with a broken maintenance script that had
inserted 0s into some users' blacklist, broke all notifications
for those users.
Bug: T177825
Change-Id: If8700b4d0de0fdba876eb9d5cc4997e185dfeb3c
With 349457, anytime a revision is created, a corresponding record
is created in the new ip_changes table. This may cause tests to fail
if they don't drop the ip_changes table between individual tests.
https://gerrit.wikimedia.org/r/#/c/349457/
Change-Id: I48f0b64f19f9582b40540fa1b42a39d281979625
The return value from the method is only suitable for passing to
$db->insert(). To get the inserted ID, you need to call $db->insertId()
even if $db->nextSequenceValue() returned non-null.
Bug: T164900
Change-Id: I466fd372804927b3ad72125c7a69d253bd7a24f8
Some browser tests were broken by 945fccf009.
The badge element is now technically rendered offscreen, with only the
:before and :after pseudoelements being onscreen. Because of this, Selenium
thinks that the badges are invisible, and this breaks various things in
totally unexpected ways.
* article_page.rb: Store references to the parent <li> elements of badges.
This might not be necessary but I don't know how to access them otherwise.
* badge_steps.rb: When clicking the badges, click the parent <li> element
rather than the not-really-invisible <a>. Effectively, the <a> gets
clicked anyway, since they overlap.
* no_javascript.feature/no_javascript.rb: Wait for page load before
checking that we're on the right page. The wait is no longer
implicit, since Selenium thinks we're clicking the <li> rather than
<a> (links are special-cased).
* notification_steps.rb:
* Check whether the badges exist on the page, rather than whether they
are visible.
* Use a weird hack to read badge text. Apparently you can't read the text
of elements that Selenium thinks are invisible.
http://stackoverflow.com/questions/20888592/gettext-method-of-selenium-chrome-driver-sometimes-returns-an-empty-string
Bug: T161941
Change-Id: Ic6bcd1088249109e49a47cc9007e6ee002d3d8ba
Other tests (possibly from other enabled extensions) could also,
by chance, create Echo notifications for the user MWEchoThankYouEditTests
uses. In order to those tests be reliable, they should make sure
there is no notification data in the database prior to running tests.
Bug: T161087
Change-Id: I870a50b1f831795731235fa8ec97477b3e470b50
When content is changed and the change contains the signature
of the user, the method checking for reasonable mentions in
that changes did not consider multiple signatures.
The patch fixes that and adds a test for it.
Bug: T154406
Change-Id: I86303f42e97d16c68e3235b0e2d13542ceedf1fe
This speeds up the tests from 2 mins to 50 seconds for me.
(with a slow setup, no caching etc.)
Bug: T158120
Change-Id: I8adb6c8fe783d1be8841a1139bb141da3b046f9d
For the used diff engines an empty/new page is equivalent
to an empty line. When adding content that includes an
empty line the content will be split into two parts. The
interpreted diff will then consist of one addition, one
copied line and another addition.
Is the ping in the first addition and the signature in the
second addition the DiscussionParser does not send mentions.
The patch introduces a special case when interpreting diffs
if content is added to empty content. This will also skip
execution off diff engines since the interpretation is trivial.
Bug: T155998
Change-Id: Id5e44bc3245940c1f77c80f036db637756542552
Freeze time to avoid a race condition
where a second is ticking in the middle
of a unit test.
Bug: T154188
Change-Id: I6b0c8ae06360e6da016d97361cc2ccdeaf2e4343
Purge all cache when unread count changes and
repopulate on read.
Also fix client-side estimation when
marking a foreign notification as read.
Bug: T151389
Change-Id: I62def3d40a5640e26c234bb0335bc506dbf864a0
Whether we estimate or not, the actual stored count should always be
normalized within the range of 0-cap. Estimation should always skip if
the current count is at the cap; in that case, the count can only be
changed when we get the value from the API through setCount() (used
when the value is known, rather than estimated.)
Change-Id: Ie8b81a4433e8254ee0e90f59e5b25d727158eecf
This sends out a notification when a user gets mentioned in a change as
long as a signature is added in the same section.
Bug: T138938
Change-Id: Ie183fbb8150bd9451a5b0a9fea0227e3241b26a0
Has bugs, and will likely cause deployment problems.
This'll need to be reverted in wmf.19 at least
until we fix it up.
This reverts commit 00e0b9f45d.
Change-Id: Ia9d220ebcb607f96dee6bc856755305ed8501fcc
Target page entries used to exist for each user
that was notified for an event. They were
removed as the notifications were marked as read.
Now they remain so that the association between
pages and events can be used for moderation
regardless of the notifications read status.
This patch removes everything about
echo_target_page.etp_user from sql and php code.
Bug: T143959
Change-Id: Ib57510e6b0e9202a7e035f8ea59955dca8a0b24a
- Add a 'hasUnseen' data to the xwiki bundle so the badge can
consider its value when changing its color even without the
bundle being opened.
- Check and store seenTimes from all sources that the xwiki
has in a new JS object that the SeenTimeModel can store
Bug: T134855
Change-Id: Ifdcee88b4378cdc7acb4ae5c0cbc60b76339757e
This patch fixes mentions not being send when multiple sections were added
in between sections.
Since we only want to send mentions when userlinks and signature are present
in the same section a new method was added extracting sections and the related
content from an addition. The results are checked whether a section content
contains a signature and might be relevant for mentions.
Bug: T141863
Change-Id: I434c664552bbadbeef6e897e20703e813f5a4c52
The previous check here meant that different
setups could run these tests with current diff
engines thus these tests could result in different
successes / failures.
Change-Id: I62a52dee1dd1ecd2ebd36e1aa540245e90a57ddd
This patch logs multiple section edits that could trigger mentions.
Since we only want to send mentions when userlinks and signature are present
in the same section a new method was added extracting sections and the related
content from an addition. The results are checked whether a section content
contains a signature and might be relevant for mentions.
Bug: T141863
Change-Id: Ib06cd855b2c7fbd51d8ab6602882cb38aadf8350
While manual rebasing the bundle patch the wrong
line was removed.
Also improves tests to check for notifyAgent.
See I1069aeb5523db8710da4e8e21065bf447d031e3c
Change-Id: I33ddeccea153d6f6ae97e5c60e8b47dc24fb4833
