Where did you run into that? I haven't seen it in the docs, offhand.

Note that there's a non-trivial per-install cost here (White-listing the application x domain with Google).

Also I believe, that in Notifications app the "Unread Notifications" query should be default, not "All Notifications" as it is now.

You may modify your instance of Phabricator via forking or patching to suite your individual needs.

Isn't having "Mark as Read" link on list of already read notifications controversial? Usually when people click on something, then something should happen/change, but it doesn't in this case.

We're not interested in pursuing this in the upstream as the information is useful regardless of if it's been read or not. It's also consistent with how other notification systems work (Facebook, Twitter, etc). Thanks for the feedback.

Nuance is our future product intended to let installs interact with common folk (for issues) anywhere on the web.

Is this documented somewhere?

In T6309#79515, @epriestley wrote:

This software is also not targeted at consumers or the public at large. It is targeted at professionals in software fields and adjacent fields.

This software is also not targeted at consumers or the public at large. It is targeted at professionals in software fields and adjacent fields. Product and prioritization decisions we make in the upstream reflect that.

Then an interface is needed to set the site defaults for those.

If I look at https://secure.phabricator.com/settings/panel/emailpreferences/ , this seems rather easy conceptually: there is already one row (and selector) for each possible event, they only need to be "exploded" by the possible relations one can have to the event: Actions x {I made it; or not} x {I'm author of the task/whatever; I'm subscribed to it; I'm assigned to the task; I'm backer of the fund proposal; ... }. You already have the first two combinations, just need the latter.

I don't think a switchboard of checkboxes can accommodate requests like T6296.

@chase.mp told me on Sep 07 "there is no email broadcast, I had to write one" but I don't know any details either.

Cool, thanks!

Sorry I never got around to testing that temporary fix.

Closed by commit rP4d3cc7b28dd1.

2147483647 is the value on 32-bit systems, but %d may not work properly with 64-bit integers on a 32-bit system. I'm guessing the actual query we're running is chronologicalKey < 12 (for some incorrect, 32-bit-coerced value of 12) instead of chronlogicalKey < 6052774592759489916.

Sure thing; I'll need to wait until tonight since we've got people using our install throughout the day, and I still haven't set up any sort of 'test' environment.

Wow, i didn't realize PHP could have super different values for PHP_INT_MAX beyond like 32 bit vs 64 bit OS and stuff like that.

Aha! Can you try this patch and see if it works?

2147483647

@mholden, can you show us the output of this command on your system?

Just to clarify this issue is on a single instance only. I think @mholden has provided evidence that somehow the sql query which should work isn't. I am not sure what ghosts could be living in this specific instance, and of course perhaps this is just the first instance of this problem we've seen reported...

@epriestley - I am wildly stumped on this one. Code should work; does not.

Sorry I took a day to get back.

To cut to the chase a bit, can you talk more about the "magic" that you might have done to your instance? I don't think we should bother debugging stuff if you're confident its something you did to your instance.

If it would help, I can paste the results of any SQL I can run that might help you see what's going on..?

Hmmm, I can't seem to repro this. Would the "magic" involve making things with weird timestamps?

Thanks for the report. I am 99% sure this is some fallout from fixing T5975.

Blindly associating this with the "Notifications" project because that sounds like it would make sense.

Closed by commit rP85b767bbdc65.

I fear this wouldn't make a busy install much less busy. I like the idea of more of a 'synopsis' type feed, as beyond just people on vacation, could be beneficial to people outside of engineering. Some sort of daily summary with links to queries (5 tasks opened today, 12 tasks closed, 5 diffs committed, yada yada yada).

(We could also restore aggregation but use it only in feed, or only in notifications. All of the options here feel about equal to me for how I use the product, at least.)

Tangentially related: we have some story aggregation code in the codebase which we used to use a long time ago. It aggregates notifications and feed stories (specifically: multiple updates to the same object by one or more editors in roughly the same period of time) into stories like this:

Closed by commit rPdc69c4e58c2a.

Closed by commit rPc740d554f667.

Specifically: Settings > Email Preferences > Maniphest Tasks > "A task is moved between columns on a workboard." > Ignore

Closed by commit rP8ef1ea63ddb9.