Thanks for the detailed investigation -- glad we've root-caused this and proposed a solution :)
Aug 17 2016
Aug 16 2016
Jan 5 2016
@dgoldstein, also, for future reference the way you find the list of email commands is to open an object of the type you care about (here, a task), click the circle/lifeboat thing, and then click "email commands."
Nov 20 2015
That worked for now -- hacky, but thanks.
The workaround I provided in the task description ("If you click the "refresh" icon next to the Google provider, you can add a second account.") no longer works after D14319.
Nov 3 2015
Nov 2 2015
Oct 28 2015
Oct 27 2015
@epriestley, do you have a time estimate of how long this would take to fix?
Oct 25 2015
Oct 23 2015
Oct 22 2015
Oct 19 2015
Oct 8 2015
Some people on our install are asking about this task.
Oct 1 2015
I think my preference would be the "Improve the error message and provide a button to close the audit" option. @epriestley, how long would this take? Assuming it's small, I think we'd want to prioritize this.
Sep 10 2015
I suspect they're the same, but I'm not confident. I'm happy with closing this as a duplicate, and then trying to repro after T5030 is fixed.
This just bit us again, via a different repro.
Sep 2 2015
We haven't yet applied a local patch for T9263. None of our patches seem to be relevant here.
Aug 31 2015
Actually, I just saw that you switched from .phui-object-item-bar-color-red to .phui-icon-view.red. It looks like we now have 14 color options; that's probably good enough for us for now.
We have 7 priorities (one more than the default). Our new priority is "Blocker!", which we put in between High and Needs Triage.
Also, barColor does not exist in master, we use icon + color now to convey information instead of just color (and yes, icons are configurable for Maniphest).
Aug 29 2015
Aug 28 2015
I think ordering by commit date would be great!
Aug 27 2015
To give more info: I'm sure the order makes sense for some use case (though I can't quite figure out what it is right now). The use case we have (in this scenario) is:
Aug 25 2015
Aug 12 2015
Aug 4 2015
Thanks for the pointer. We CC external mailing lists on most objects because we use Google Groups as the source of truth for group membership, and it's impossible to keep everything else synchronized with it. T3980 sounds interesting.
Our install isn't running any custom CSS. One of our engineers published a Chrome extension that re-skins Phabricator, and it looks like @ianm is running that extension. Ian, disabling the extension should help.
By inspecting the network call that that search field makes, I was able to find a URL for the custom search engine use case:
- Visit the wiki (eg, on this install it's https://secure.phabricator.com/w/)
- Change the dropdown next to the search bar to "Search Current Application"
- Perform a search using the search bar at the top of the page
Any workarounds you can suggest until this fix is pushed? I just tried to edit a Herald rule on this install (https://secure.phabricator.com/herald/edit/109/) and can't because of this error.
Aug 3 2015
Thanks for the comment! @epriestley, with that in mind, is bin/remove destroy our best option? Will we be able to receive upstream support if this command causes issues?
Aug 1 2015
@devd, I want to make sure I understand this correctly -- the task seems to be about making one specific use case of lint easier (not linting in general) but is vague about what that use case is.
Jul 31 2015
Jul 30 2015
Jul 21 2015
At a glance, in views that don't otherwise indicate priority (eg, workboard with natural sort order), I'd like to be able to visually distinguish between all of our different priorities.
Jul 15 2015
It sounds like the problem you want to solve is that people sometimes land code before tests have finished running, correct?
Sorry, I spoke without actually knowing for sure what bin/remove destroy does. I was guessing based on the warning text ("Destroying objects may cause related objects to stop working, and may leave scattered references to objects which no longer exist.") that it would leave dangling edges.
Jul 13 2015
We think we just ran into this today? But the problem mysteriously resolved itself after 2 hours, so we can't be much help in reproing.
@ryanseu, can you explain the use case and why setting the view policy isn't sufficient?
Jul 8 2015
Just installed XHProf and ran another profile. Services:
Chrome network console shows 654ms for the AJAX call to /differential/comment/inline/edit/####. The Services profile shows:
Jun 30 2015
In that case, this is a dupe of T8588.
Jun 24 2015
Jun 22 2015
Now that I think about it, one possible explanation is if we're executing O(N^2) queries for each workboard column of N open tasks. (The sum of the squares of the number of open tasks in each column is 2924.)
According to DarkConsole's services tab, query takes 12s overall.
Jun 18 2015
That sounds like another great solution option for this problem :)
Jun 17 2015
Jun 16 2015
I just updated T8522 with some more information -- we had database issues that night (possibly related to the later corruption, unsure) and I can't repro it.
I think this was a fluke. I later discovered that, about 15 minutes before I filed this bug, our database host had gone read-only and we needed to reboot it. This caused transient issues for the rest of the night (eg, none of our phdaemons were running for about an hour until someone kicked them).
I would propose that we make this task into: Prefetch/cache 50 users and 50 projects for the typeahead.
Another option: after T5791 is closed, you could temporarily write a global Herald rule to disable emails for the actions you're about to take, then delete the rule when you're done.
I really enjoyed reading this comment thread! :)
Re-running my experiment (typing two characters at a time), AJAX calls are now taking 700-1000 ms.
At rPee8de4a, this is (mostly) no longer timing out -- but the AJAX request is taking anywhere from 7 to 29 seconds to complete.
Jun 12 2015
In addition to the text being wrong (it always says "marked 0 inline comments as not done."), I'm observing that state is not being saved -- I mark a bunch of things as done and submit/save, only to see that many have become un-marked as done.
Jun 11 2015
Jun 10 2015
Yes, it is.
Some more useful data:
- Last week (before we upgraded Phabricator), I needed to create a user for something. I created a user from /people/, used ./bin/auth recover to log in as that user, and then the web UI immediately presented me with a "you must verify your email to use the website" screen.
- Today, I just went through the same steps -- and instead of seeing "you must verify your email," I see the "login failure" page.
- I checked our database to find a full list of all users with isEmailVerified=0. It's a bunch of really old test accounts, and then new accounts created this week. Every other account on our install is email verified.
- I double-checked our settings. auth.reuqire-email-verification displays as "false" in the list of all config settings, but when I click into it, it says "Value (Use Default)" and then further clarifies "By default, verification is optional unless auth.email-domains is nonempty." Our auth.email-domains setting is non-empty, so I think we do require email verification.
auth.require-approval is false
auth.require-email-verification is false
Do any of the details I provided in T8504 (like the mention of the gray circle) help you understand what's going on here?