Just a heads up, this looks to be resolved. I've changed all the projects to only have future-valid hashtags, which usually involves my renaming the project to remove the [ ], and then, renaming it back, thereby forcing the automatic hashtag to regenerate properly.

This is the policy on the IAM user:

Ok, I've reverted our prod system to last night's snapshots of mysql + root disk and it is back to working again (with zero changes in AWS).

Update: I freshly reinstalled Phabricator on Ubuntu 14.04, and couldn't reproduce this... but between the three instances there's very little in common. I'd never enabled Almanac stuff before on my other instance, and never on Haskell.org, but those exhibit this bug. A fresh install does not seem to, and there doesn't seem to be a stack trace.

It may also be useful to run arc unit --everything in libphutil/, as that will trigger a number of signature-related test cases.

We had to downgrade libphutil+phabricator to get it working again, so they're currently on the commit immediately prior to the v4 stuff.

Broadly, here's a command string (with live, active credentials) which works for me to put data into an eu-west-1 bucket:

I can't reproduce this. Before we move further, it looks like libphutil may be out of date?

We are too; that's expected to work correctly.

Oh, we're authenticating using an accesskey/secretkey for an IAM user, if that makes a difference.

Thanks. I'll bring up a eu-west-1 bucket and see if I can reproduce this.

Hi, here you go:

Can you show me the output of this command on your system?

Can you make a movie or give screenshots of where you are clicking?

I also can't reproduce this here or locally. I tried several different projects, and tried users with and without permission to edit the menu.

This should be resolved by D15112. I've made a note in T9789 to catch this class of issue sooner before we make the consequences more dire by pursuing changes planned there.

I'm at version a9e2e6c5aab94c8f4c57797ac63bfd88955a630d and php-fpm restarted after upgrading.
I don't have any editing permission on this install obviously, but the reproduce steps are the same. I see a 404 Not Found error on page after clicking "Edit Menu" rather than anything else.

I can't reproduce anything based on the steps you've provided here. Here's what I did on this install:

Thanks for the quick fix! Just updated to latest HEAD and it works fine.

This should be fixed in HEAD. Thanks for the report!

In T10207#155400, @paladox wrote:

Where do I ask questions.

Where do I ask questions.

I can't immediately reproduce this at HEAD but I'll poke around a little bit more.

This does not describe a bug in Phabricator. Please read Support Resources and Contributing Bug Reports carefully.

At some point in the future we'll redesign timeline and we'll keep your feedback in mind. Thanks!

(This is definitely confusing, but I'm not sure what the best way forward is offhand. I'm hesitant to just make Herald always trigger without putting more thought into the issue.)

Thanks, @epriestley (and sorry for getting back to you so late)! You're totally right that this is because I didn't actually update the revision.

I've retested everything here and in my installation and it seems that this solves all cases re: grouping, ordering, and paging.

Thanks for the quick fix !

Thank you very much! You solved all my problems :D

The first hit on Google for "phabricator daemons" should be the documentation for them:

Thanks epriestly for detailing about the error and also the solution to it. Yep that was an database issue. After logging in as admin I was successfully able to update the phabricator.

This is probably because the user you are connecting with does not have permission to access the database.

Ah, I didn't check if HEAD had an index for the unit table. We're about 8 months behind because we can't upgrade until we resolve all of the conflicts caused by the different Drydock architecture.

I think case (1) (and maybe cases (3) and (4)) is resolved at HEAD.

Herald has some very unusual code to preserve control values when you swap the selectors. Generally, the issue is:

HarbormasterBuildTarget->loadArtifact() also probably does a table scan when it doesn't need to, but if that isn't causing any problems I'll leave it alone for now until we hit it for real.

I can't reproduce the second issue; that index should already exist (or bin/storage adjust should create it if it does not). Here it is in the source:

I believe this is fixed at head. Let us know if you're still seeing issues.

(And there are no configuration settings you can change which will possibly impact or resolve it -- it can only be resolved by an upstream fix to the problematic implementation.)

Sorry, I wasn't very clear -- I know exactly why this is happening. It isn't related to configuration or arcanist (it's an implementation issue related to D14970), so I don't need any more information.

Quicksand issue most likely. Thanks for the report. I was mostly curious is people are using the column in the real world.

Yeah, these are "common" controls, but I think they only get used in Herald?

oops~

Hi chad,
We ran into this bug because a colleague use it and couldn't display project tasks.

Closing since this isn't a bug report. See Contributing Bug Reports for what we look for in a bug report (specifically, repeatable steps by us to reproduce the issue). General questions on using Phabricator are better suited for Ponder. Thanks!

Can I ask if you actually use the Conpherence sidebar? Or is this just something you ran across testing?

Uploading a file to Maniphest tasks sets the permissions to the view policy of that task. If you need to just upload any file to Phabricator, just drag and drop it onto your homepage or use the Files application.