D15636 is marked as fixing this. Specifically:

The use of sh as it is written in the documentation is important.

I've also added myself as a subscriber (even if i was auto subscribed because i'm the reviewer) but that doesn't change anything. Still no permissions.
The problem can also be reproduced when clicking on Download Raw Diff in the interface.

In T10725#168658, @chad wrote:

Files attached to other objects take on permissions of the object itself. So if you add a file to a restricted task, the restriction is also applied to the file.

Files attached to other objects take on permissions of the object itself. So if you add a file to a restricted task, the restriction is also applied to the file.

In T10725#168645, @chad wrote:

My question was what is the relation to User B and the Diff. Is User B a reviewer, a subscriber, or ... ?

But seems like Evan has a handle on this, regardless.

My question was what is the relation to User B and the Diff. Is User B a reviewer, a subscriber, or ... ?

In T10725#168508, @chad wrote:

What's the relationship between user b and the patch, specifically?

This should now be fully resolved in HEAD of master. Thanks for the report! Your details and stack traces were very helpful in understanding and resolving the issue.

After D15632:

Cool, let me see if I can repro that locally.

You're right; our amazon-ses.endpoint wasn't set. We just upgraded to HEAD and (incorrectly) configured amazon-ses.endpoint to email-smtp.us-east-1.amazonaws.com and got some exciting new errors that also might be worth fixing:

You should get a little further now in HEAD of master.

It looks like this is occurring during error handling so there's likely some other root error that this is masking, but we can fix this and see what it unveils.

(Oh, this one was with arc land --hold originally too -- I misremembered the context.)

T10727 is a similar report of this issue, although motivated via arc land --hold.

[Explanation Intensifies]

(That explanation might make approximately zero sense, I am not having a high-brain day today.)

This is probably the "object policy evaluated in the context of a different object" issue we've seen occasionally. If so, setting the visibility policy to any non-object-policy value (e.g., "All Users", or a specific list of users, etc -- anything which does not depend on the revision) should fix the error.

What's the relationship between user b and the patch, specifically?

Nice catch, thanks! D15619 should fix the docs.

Please see Contributing Bug Reports for what information is required for a valid bug report. Feel free to reopen once you've provided this information.

I think this may have broken https://secure.phabricator.com/book/phabricator/article/remarkup/#tables

• I'd currently consider this a user-expectation issue, but we're doing ourselves zero favors by not providing any kinds of hints about what expectation you should have. We should fix this first. I've realigned this task to discuss making the expectations/behavior more clear.
  • I believe the "edit permission is necessary" part of this rule is hard to reasonably get away from in light of column triggers (T5474). Not impossible, but hard.
  • The "edit permission is sufficient" part of this rule is easy to get away from, but we don't actually have use cases for requiring an additional project permission component right now (T6502).

My current expectation is that the rule is supposed to be that edit permission on the task is both necessary and sufficient to move it on the workboard, but this is almost certainly not fully reflected in the UI, and possibly not fully reflected in permission checks in some cases (?) although it sounds like we're good from this discussion.

At least, allowing people to move tasks without T6502 in place seems problematic. For instance here, that would allow any logged in user the ability to re-arrange the tasks. I assume this should just maybe merge into T6502 @epriestley ?

T6502 is workboard edit policy, as far as I understand it. We were planning on building it, but fundamentally couldn't come up with good reasons why you'd want different permissions for editing a task vs. editing a board. There are reasons, but they didn't seem worth the current cost of implementation.

@chad this isn't an everyone-everywhere change. Here the expectation, at least for me, is that the natural sort edit should follow the workboard edit policy, not the task edit policy.

To be clear, the Community work-around is totally fine for us. This ticket was filed just to call attention to it. We don't have a case where this matters directly for us (we're not using Phabricator for ticketing and thus won't have these workboards; this was just us encountering it when working on this installation of Phabricator).

T6502 is related except that even if that were to be permissive it wouldn't be possible to edit the sort since the underlying task lacks edit capability. That said, it is the ticket I was thinking of.

No, we don't want everyone being able to move tasks anywhere, anytime. Projects don't infer policies.

to be clear: the #Twitter project was already added to the project. The expectation was that changing the *natural* state (as opposed to the priority state) would be allowed.

Definitely open to this being a user expectation bug.

T6502 is the other task you're likely thinking of.

Trying to understand this, since moving tasks on a board is editing the underlying task.

This report does not describe a bug.

In T10717#168249, @chad wrote:

Is this what you installed? From the page it looks clear that 7.0.4 is a Developer install, not a Stable/Production Install.

@chad I get it even on php 5.6

We don't support PHP7, see my comments above for related tasks. I'll add this as another example though. Thanks for verifying!

Is this what you installed? From the page it looks clear that 7.0.4 is a Developer install, not a Stable/Production Install.

@chad ok ive installed php 7 64bit from http://windows.php.net/download/ and this is the error I still get

More specifically, we have no other reports on Windows issues with arcanist when installed in a supported environment.

@chad the php is based on the official one. Just modified a bit to run with wamstack. Unless it is not modified.

@chad the php is based on the official one. Just modified a bit to run with wamstack. Unless it is not modified.

We don't have PHP7 verified/supported (see T9888, T9640) and we don't support third party installers. In order to accept this you'll need to:

Other people having problems with proc_open https://github.com/mikehaertl/phpwkhtmltopdf/issues/56

On my mobile device (an iPhone 4S), I think it's slightly faster to tap-wait-tap-copy the URL bar than press-hold-copy a link.

It's an intentional change, so it's easier to copy and paste the task ID. I'm not sure I understand what functionality is different now that you desire. A place to get the full URL but not from the browser URL bar?

In the mobile, it's usually easier to touch the button instead of opening a sidebar to touch refresh button. If you're saying I can use keyboards on mobile, fine.

This report doesn't describe a bug.

This should now be resolved in production.

We have an additional safety check which is supposed to prevent this kind of issue: we refuse to process messages with the same "Message-ID" more than once.

I think this is happening:

Thanks for the report, D15573 should fix this. Sorry about that!

I can reproduce:

avive@vm:~/devtools/libphutil master$ arc backout @
Starting backout.
Backing out commit @ Implement a stream iterator and hashing iterator
Double-check the commit and push when ready.
avive@vm:~/devtools/libphutil master$ git log -1
commit 3546d1d307b6a3971162ab5e359df909ce84da64 (HEAD -> master)
Author: Aviv Eyal <avivey@gmail.com>
Date:   Fri Apr 1 21:05:33 2016 -0700

See Support Resources.

@epriestley Maybe a bug request wasn't the right thing to submit. How can I go about getting support or advice on this issue without figuring out how to reproduce it. At the end of the day it is likely not a bug but rather me breaking something through deleting a project.

I know you guys want reproduction steps

jx-tooltip is a free spirit :3

my pleasure! thanks for the swift reaction and resolution, and very clear messaging on when we can expect the fix to be available on the phacility instance.

This should now be resolved in HEAD of master. I've deployed the change here, and verified I can interact with the comment in D15565.