Page MenuHomePhabricator

Add a setting for 'mark all read' notifications
AbandonedPublic

Authored by epriestley on Aug 25 2017, 9:11 PM.
Tags
None
Referenced Files
F13221566: D18479.diff
Sun, May 19, 2:52 AM
F13203980: D18479.diff
Wed, May 15, 12:15 AM
F13200700: D18479.diff
Tue, May 14, 2:41 AM
F13198939: D18479.id44393.diff
Mon, May 13, 10:29 AM
F13186674: D18479.diff
Sat, May 11, 3:48 AM
Unknown Object (File)
Tue, May 7, 7:07 AM
Unknown Object (File)
Fri, May 3, 5:12 AM
Unknown Object (File)
Sat, Apr 27, 3:23 AM
Subscribers

Details

Reviewers
chad
Summary

Adds a setting to toggle the prompt when marking all notifications read. If users opt into the toggle, we no longer show a dialog with a verification button first, and instead just mark them all read (as of time of render) and reload the page.

This does not update the button on /notifications/ which I'll follow up in next diff.

Test Plan

Save setting, spawn some notifications from a second account. Use Mark All Read from dropdown. See page reload and count vanish.

Diff Detail

Repository
rP Phabricator
Branch
notification-setting (branched from master)
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 18180
Build 24441: Run Core Tests
Build 24440: arc lint + arc unit

Event Timeline

chad edited the test plan for this revision. (Show Details)

Let me test this some more.

chad edited the test plan for this revision. (Show Details)

This approach seemed cleaner as simpler than my last over-engineered attempt. It just reloads the page after it sends the request off. Is this a decent approach? I'll follow up with adding a checkbox directly on the dialog for the setting. As for the button on /notifications/ I'm having some issue finding a clean solution since search results always want a PHUIButtonView and not a form. I'll think more about the best approach there, but I don't think it's any priority.

epriestley edited reviewers, added: chad; removed: epriestley.

I believe this allows an attacker to clear a user's notifications with a CSRF attack, because it executes a write action without calling validateCSRF() or any method which calls that for you (like isFormPost() or isDialogFormPost()).

I'll just write this piece, since we don't have any similar behavior anywhere else and it isn't something you can really guess or figure out.