I think this was resolved. I nuked Discourse anyway so it's effectively resolved until another report shows up.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 20 2022
Mar 12 2021
Mar 11 2021
An issue arose when a user loads a page of notifications which include stories they don't have permission to view.
Feb 26 2021
I deployed this and nothing blew up, presuming this is resolved.
Feb 25 2021
When users are @mentioned on an object, render their name in a disabled style if they've been muted.
Sep 19 2019
Sep 18 2019
Mar 16 2019
Feb 25 2019
A very mild point in favor of this feature is that we haven't seen any negative feedback or confusion, although I think you might be the first user to say they actually like/use it.
FWIW I appreciate and use the mute feature (though only occasionally)
Jan 2 2019
Apr 20 2018
Apr 19 2018
After D19384, we'll automatically mark these "phantom" notifications as read when you open the menu to review them:
Feb 8 2018
I largely agree. This is getting leeway because it's backed by support mana (PHI126 basically just asks for this feature, verbatim). I think the actual change in D19033 is small enough that I don't feel too bad about giving this a shot, but I'd like this feature to see significant use and not generate a lot of confusion/support load if it's going to stay in the upstream. I'm also more comfortable trying this because it's very easy to revert.
For what it's worth, I think the Mute feature adds a lot of complexities to the system, in excess to the norms of the last few years:
- Code to handle it in the sending mechanism
- Prioritizing this feature against any other notify feature (like T9031)
- UI to show the to the muting user (on the object and in /mail/?)
- UI to show to other users that this user will not be notified (What if all members of a project are muting a thread?)
- Can a mailing list/project mute a topic?
- "why did I not receive this notification?" - there's still some issues about this - novice users don't know/understand /mail/, and admins can't see this for them. I suspect this question will require a written checklist somewhere.
If this feature doesn't see much use, I'd like to remove or deemphasize it (for example, by moving it to a keystroke or removing the UI and just providing access via !mute) at some point since I think UI space in the curtain is premium real estate. This doesn't need to be 200 mutes per user per day, but I could imagine this seeing essentially zero use.
Nov 8 2017
Could this be closed now that Phab supports this? (in /settings/user/Username/page/notifications/)
Oct 11 2017
Sep 13 2017
This is also affecting other persistent sticky notifications, notably "Read-Only Mode" and "High Security Mode". I need "Read-Only" mode for PHI36 so I'll take a look at this.
Sep 12 2017
Aug 28 2017
Aug 23 2017
Should be quick to implement.
Aug 16 2017
Aug 6 2017
It's discoverable in settings just fine.
Jul 12 2017
What if they're on the page, is that notification annoying? I love click that little guy.
+1, we've also had a handful of users request this as a per-user preference.
Jul 5 2017
We've also had a request for this (disabling the in-application popups) at #dropbox, as a per-user preference.
Jun 18 2017
Jun 2 2017
Arguments against:
May 12 2017
May 4 2017
May 3 2017
Apr 17 2017
Mar 29 2017
Feb 21 2017
Agreed this dialog is pretty annoying.
Jan 10 2017
I'm just going to merge this into T10448, this task doesn't have anything not already covered there.
Jan 8 2017
Jan 4 2017
100% accurate mockup of this feature
Oct 24 2016
Oct 19 2016
As said in Q501 it will be useful to have some components (e.g. an administrative panel) that appear on top of all the dashboards.
Sep 16 2016
Aug 10 2016
In T8145#113258, @epriestley wrote:Does anyone have a use case for this which isn't maintenance notifications?
Aug 5 2016
Aug 4 2016
(Possibly it might be easier to select the correct audience in Phabricator since you can use projects or other rules, but all of the use cases here and elsewhere just want to hit everyone, I think.)
Yeah, basically like the Facebook Rooster system except making it act as "pinned notifications" instead of "pinned dashboard panels". We could do either, reasonably, although it's slightly messier to do a real-time notification of "a new panel appeared on all dashboards, go look". But I'm basically not sure why this is better than email in any case where the users are employees.
I think a global banner (or some equally omnipresent, persistent element) is reasonable for "this system is going down in a couple of minutes". But if that's the only really good use case we have for it, though, I wonder if we shouldn't just build a "shutdown in X minutes" feature that automatically does this, counts down, stops new batch jobs from starting, maybe pauses builds, puts the system into read-only when the countdown finishes, etc. -- a dedicated "graceful shutdown" feature instead of just a broadcast feature. I don't think any of these things are really problems today, but I could imagine more of a "shutdown process" being useful in the future.
The "Rooster" system we had at Facebook is essentially a panel (closable) that would persist on every homepage. I would be OK forcing a panel onto all dashboards if the users can also close it. I think we need closable panels for NUX anyways. But the issue is this is still a "pull" notification, meaning the user has to visit a page to get the information. A "push" system (notification, email) is better for things like downtime. "pull" systems are good for just general FYI stuff (all-hands meeting upcoming).
To your point, we did have some users complain that even just on the primary dashboard a ticking timer was a bit distracting. But, you know, when your boss's boss's boss asks if something is feasible, you at least look into it. :) And I think countdown scenario aside, a global information display that doesn't assume the user has some specific dashboard config is potentially valuable.
@epriestley, somewhat an edict from on high, but I do think there is potentially some value in a persistent banner (a single row tall, similar to the main phab bar but perhaps even a bit skinnier.)
@bjshively, for this use case:
Jul 25 2016
Jul 16 2016
Jul 8 2016
Jun 6 2016
T10402 is the "check client/server agreement about HTTPS" task.
Configuring the Preamble script is important for reverse-proxied configurations (you probably need to set REMOTE_ADDR up as well), and required for many things - which is why it is part of the install guide.
Wow, thanks for your fast and precise answers!! Using the file
We ran into this on a recent install - the fix was to configure the Preamble script to tell Phabricator it was being accessed over HTTPS (else it filtered out the HTTPS notification server) - check to see if "Connected" or "Disconnected" at the bottom of the notification popup (menu at the top of the screen - see this install). If you just get a grey bar at the bottom without either, you're hitting the same case where the client doesn't think it has a valid notification server.
https://hub.docker.com/r/hachque/phabricator/
is not supported by this install