I deployed this, seems to have worked properly in production.

Vaguely related: aphlict exited on notify001 with this error:

See Restarting Phabricator for detailed instructions on how to restart Phabricator after an upgrade.

Hit by the exact same issue of Unknown column 'event.dateFrom' in 'order clause', and arrived here through search. In hope this helps somebody else, here's how I fixed it.

• LGTM, thanks.
• That icon makes sense now that I know what it indicates. I doubt that there's a universal icon for this particular purpose. Maybe something like (or the open version added in the newest FA), but that's still unclear if you don't already know what it means.
• That's reasonable.
• I created the all day event E1211 to span the 14th and 15th (see image below). It appears correctly in the month view, but the event page says:

Since this is a highly desired feature for us and many other Phabricator users (tokens, tokens, tokens), I would really like to contribute. I already did some work and it turned out - thanks to the flexible architecture of Phabricator - not that much is needed to get something quite nice and robust:

• A typeahead datasource for project columns
• A new Herald field for task cards
• A new condition type in HeraldAdapter class
• Minor extension of the project column query class

It's entirely possible I missed some things in supporting the 25,000 different URI forms we now support, but just file a new issue if you run into anything since this task is now 200 years old with seventy pages of unrelated disucssion.

• D16852 should fix the coloring on the mobile month view.
• The icon means you're invited, not that other users have joined the event. Could we pick an icon that you'd find more clear? (Available Icons).
• Old events have undergone several migrations and probably aren't unambiguously fixable at this point, so I don't expect to correct any remaining migration issues.
• I can't reproduce the last issue you describe ("but are extended forward by a day on the event page"). Can you provide specific reproduction instructions?

Thank you for giving Calendar some attention! Looking forward to it becoming a proper grown-up application.

Certificates have been deprecated in favor of tokens (they were less flexible, and users frequently found working with them confusing). Everything you describe is working as intended, so this is not a bug in Phabricator. We also don't provide support with third-party code.

Both 32GB volumes have been swapped for 128GB volumes.

D16115 + D16847 + D16848 make these changes:

I think that will prevent these edits from occurring by accident via the web UI. Yell if you manage to trick it or it causes any weird stuff.

I think the root cause is that in SUSE 11 SP4 cannot run the .php file under the command line.
because in the ./bin/config file , it only a line "../scripts/setup/manage_config.php", i don't know how to fix this issue under SUSE OS.

Another possibility for assigning to members not already on the board would be to add an "Another User…" category, perhaps only once you start dragging, and if you drop on it, you have to select/type a user in a modal dialog to complete the 'drop' operation (or cancel it). This might work better than guessing; every column would have "Unassigned", headings for users with tasks actualy in that column, and "Another User…". On the other hand, for us, guessing is likely to result in a lot of wasted space, because the users we assign to in different columns are very different. The feature would quite probably be useful to us, though, as moving columns concurrently with reassignment is an extremely common task for us.

This is way outside the realm of an upstreamable bug report with reproduction steps, but run this again:

Here's the raw data from that install:

Dragging a card on a workboard while in a priority-ordered view changes the global priority (see T8135). Mail tags in "other" groups are arbitrary, unclear, and going away (see T10448). I'm going to merge this into T10448.

I was able to reproduce in this test instance. There is a parent project called Parent, and two subprojects: Sub1 and Sub2. Sub2 produces the error.

Sounds similar to T10779

I can't reproduce this. Can you create a test instance in Phacility and reproduce this there?

Versions:

• phabricator 111c63955155046bbd57c3836c78d460ebe13dfb (Sat, Nov 5)
• arcanist e17fe43ca3fe6dc6dd0b5ce056f56310ea1d3d51 (Fri, Oct 21)
• phutil 40e473e057885dab5de4fb42901f7fff2d340a6a (Sat, Nov 5)

Hi @avivey! Thanks for your answer! It works!

(Also note that maniphest.edit is the preferred way to create and edit tasks in modern versions of Phabricator.)

There's no array_fuse() call anywhere near line 834 at HEAD of master, so I suspect this may already have been fixed in a more recent version.

I can't reproduce this. Here's what I did:

The " Active" thing is a little weird.

Thanks for that confirmation. I like the look of your code comment: "Possibly we should white-list this kind of mail and deny all other types of mail." I'll create an enhancement request task related to that.

is Phab supposed to send email to users who are unverified?

Re scenario 1, I found another way to investigate it rather than digging up old logs. Question, though: is Phab supposed to send email to users who are unverified? Looking at mail logs, it seems one of our most recently added users was sent quite a lot of mail, perhaps all mail they would ordinarily get, prior to verification. If Phab is supposed to send mail to unverified users, then this would be an enhancement request which I could submit with a proper description of the use case. If not, I can investigate how to reproduce the behaviour.

Most of the work is disk/DB bound, so not having a high cpu load makes sense. That said, processing a lot of tasks will take a while.
When a task fails in an unexpected way, the daemon thread backs-off for a while, so it takes much longer to fail a task than to complete it; Unless most of the commits are failing, it should speed up at some point.
These tasks are also lower-priority than Herald and Publish tasks, which is why those get executed before these; Once these tasks are out of the queue, expect work to happen faster on the commit parsing tasks.

First, thank you for taking the time to answer...

Are the daemons doing anything? Are any tasks, at all, getting done? Are some tasks failing?

Sorry, I should have been more clear..

./bin/phd start will start all the right daemons. Look in the Daemons app in the web interface to see what's going on.

Nope, phd is definitely *not* making any progress on the PhabricatorRepositoryGitCommitMessageParserWorker queued tasks I'm stumped. When I run this:

Yes.. interesting, I had not considered that. I'll re-activate the repo

are the daemons running? You might need to activate the repository for the commits to be parsed.

One other thing that I should note, these commits are all in a repository that is no longer active. (if that matters)

OK, Here's the issue (from what I can tell)
PhabricatorRepositoryGitCommitMessageParserWorker has a count of 105,000 in the queue, but for some reason those commits are not getting parsed. I don't want to 're-queue' them by removing the --force-local, because (according to the help) that will duplicate the work that is already queued. How can I get phd to start working on those commits?

Will try.. Thank you.

I believe that if you drop --force-local, the reparse code will schedule the reparse to run using the daemons, which should fail to parse this commit and continue to the next one.

The task for parsing this commit should auto-cancel because it encountered a PhabricatorWorkerPermanentFailureException. In this case, you're manually re-parsing it, but it shouldn't be happening automatically.

What can I do next to get the commit parser to stop trying to parse this.

Related thought: I wonder how the sticky task order fares when a task is on multiple workboards; since the subpriority seems to be a task parameter, not a workboard card parameter, I guess moving it on one workboard may clobber its position on another; quite possibly not a problem in practice.