I'm going to sort out the infrastructure issues first, then we can see where the UI goes. Specifically:

Does this being added to 'Prioritized' mean Phacility are working on it, so
there's really no point in me plodding along trying to do it? :-)

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?

Let's keep it open, can use it to decide what Remarkup options to add. I'm partial to adding full, fuller, fullest options to image sizes. :)

Thanks much for the info. What should happen with this very task then? Close it?

T9379 is the Phriction v3 task, we don't have anything on radar for Pholio v2 summarized yet.

By full fixed-width I mean convert all of Phabricator. It was only explored in Photoshop and some light banter between Evan and I.

The 'mild redesign' we've been rolling out will have a fixed-width option likely per user under Accessibility

Honestly I'd love to add some cool Medium like stuff, it's what I had in mind with the Phame update, we just haven't been able to prioritize building anything like that out. If it's something you're interested in, we can look at more. I think going larger with images (or tables) separately should be doable,

It's just one of those design/usability tenants, whitespace improves visual comprehension. Plenty of usability research out there supports this.

It might also be worth exploring this stuff in Pholio v2... but maybe we can find some workarounds in Remarkup in the meantime. Maybe @epriestley has thoughts too.

Stuff like this:

It's just one of those design/usability tenants, whitespace improves visual comprehension. Plenty of usability research out there supports this. We moved to fixed width... maybe 3 years ago or so? Longer? I can't even really tell.

Wikipedia, the ultimate wiki, is full page width (https://en.wikipedia.org/wiki/Phabricator).

This is especially limiting when making tables that contains images like UI screenshots, which you would really want to use as much space as possible.

I think this makes 99% of pages look really really bad and unreadable, and 1% look better.

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.

I expect two more diffs for this task: one for awarding/revoking badges in the badges.edit API call, and one for querying who awarded whom.

oops. sorry

[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?

If we did add configuration, I think there are three ways we could do it:

A couple of general notes/thoughts:

Nice catch, thanks! D15619 should fix the docs.

I see your point with different "open" statuses.

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

Adding a data point.

• 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).

I look forward to this post surviving a thousand years and being the only cultural reference future humans have post apocalyptic calamity for 21st century human ingenuity.

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.