Here's a workaround:

I can't repro on any of these steps. Can you give us more specific details maybe that we're missing. Sounds like Javascript didn't fire or something for you. Can you reproduce on this install?

phabricator a45fe337a12f29efdf425086018f1160906f0d0f (Sun, Feb 7)
arcanist 57f6fb59d73994d90cd94143787424ce0fdbf73b (Mon, Jan 25)
phutil f43291e99d36045bc459e5133454c0d8fd8768ea (Thu, Jan 21)

That's a good point, and certainly makes me feel less bad about putting IAM user credentials in a file on the host.

I often want to know when the last comment was on a task and who made it. This is a shortcut for digging through my emails; I want to be able to check boards and see if tasks have activity since I last touched them. Any chance of something like this making it in as an option?

I agree, it's fishing. I've done all I can do and gave up. I converted to using SSH instead, which is probably better anyway.

You can use a policy like this to restrict a key to requests originating from a particular VPC:

I think you missed the point. The attacker in this instance is an employee, or a contractor, or an ex-employee. If you have static credentials sitting in files on your servers, all your ex-employees probably have them, too. And they can use them until you rotate them, which is pretty much never, in practice.

Thanks to you guys for helping through my first commit. Probably took longer to review,c comment, approve than to just do it yourself. Appreciate the hand holding, looking forward to other contributes in the future.

Since IAM role credentials are always rotating, anyone who wants to abuse those credentials (possibly to avoid using their own credentials which would get them caught) only has an hour at most. It's pretty easy to see who SSHed into the server in the past hour. Not so easy to see who might have had access to the filesystem, ever.

I believe we generally have an acceptable way forward here, at least in broad strokes, now so I'm going to close this out since I think it has served its purpose, but feel free to file a followup if things stall or you run into trouble.

This isn't necessarily "won't ever fix", but the cost to secure SVG sufficiently is enormous and I can't imagine it making sense to pursue until we are a huge organization with as many as 4 or 5 full time engineers.

Looking through the security situation in more detail in response to a recent report via HackerOne, I think it's unlikely that we'll pursue support for this in the upstream. Browsers will execute Javascript and other dangerous actions (external includes, entity expansion) in SVGs, and there is no way to avoid this in a categorical way or otherise delegate security to the browser.

Resolved by D15207. Thanks!

In T10296#157687, @chad wrote:

You're welcome to spin up a test instance on http://phacility.com/ and reproduce there (our platform - your client).

You're welcome to spin up a test instance on http://phacility.com/ and reproduce there (our platform - your client).

In T10296#157683, @chad wrote:

You'll want to start debugging your curl / ssl certificates (I don't think this is a Phabricator issue).

You'll want to start debugging your curl / ssl certificates (I don't think this is a Phabricator issue).

go for it!

I installed compiled and installed git from sources on the server, v2.7.1 and that did not solve the problem:

I'm more than happy to take on this task as my first contribution to Phabricator, but in reading the contributor guide it says all feature requests/bug reports should be first discussed.

Yeah, it's just a bit tedious to go back through like 40+ projects in the system and add a link which is probably hard-coded and might break in the future (if the project gets renamed or something?)

If you haven't played with the new nav, it's pretty configurable. Build buttons to new tasks, phriction pages, harbormaster queries, whatever. It's a bit manual at the moment, but otherwise powerful.

Oh I guess it was just an icon when it was on the workboard. Those have been removed, you can add it back via "Manage Project" -> "Edit Menu", then build a link menu to the URL. We'll have more tools likely for managing those down the road. Our long term goal is to let you put links, dashboards, milestones, nearly anything on that side menu, configurable per project.

Yeah, there used to be a button on the project page somewhere which linked you to the Maniphest query page with that project prefilled in the "Projects" query field. I used it for doing bulk edits on tasks a lot when cleaning up projects that were no longer active or on the backburner (like bulk removing assignees or bulk changing statuses from whatever they were to Wishlist).

I'm not sure what you mean by "View all tasks" button. Are you referring to the link in the sidenav?

Ah, I'm using it in conjunction with the bulk editor. The "View All Tasks" button used to take you to the Maniphest query page where you could then use the bulk editor to manipulate tasks.

With the new column design, there's no more "View All Tasks" button as far as I can see, which is slowing down my work today quite a bit. I keep having to go to the advanced Maniphest search and query different things there instead of just clicking a tag on a task and then going "View All Tasks" to find tasks like it.

T10294 talks about showing subprojects on a board, which may be confusing. One path we could take is allowing people to toggle on/off various columns (milestones, subprojects, hidden, backlog) like we do hidden columns today.

Fair enough

Suscinting that to "Bugs > Interns" or "Company > Interns" just doesn't work. @epriestley and I went back and forth on this most of last weekend. :( We arrived at "do what you want".

Overall, If your tag looks janky, that's what we expect you to solve. There is no UI I can present automatically (that I've found) to present 16 levels of information. So we're leaving it to you to present. We took a very basic route (which you can copy) for Milestones. However if you really want "Company > Org > Team > Backend > Bugs > Interns" to show up on a tag, that's just what it's going to look like.

Yeah I know, I'm just giving feedback in the event that your expectations for how users will see / use it was different.

it is a prototype.

Yeah that's why I was using sub-projects. But I kind of expected them to have the context of the parent project shown in UIs? Now I'm back to doing this sort of thing in subprojects so that I have the right context in various places, which seems kind of janky:

Milestones are only 1 level, subprojects go... 16?

And knowing I could technically have a task in two subprojects is also somewhat unexpected - I guess I was looking for milestones (without their own end dates) that could be broken down into further milestones.

I think I kind of expected subprojects to act a bit more like milestones than they currently do - for example, the fact that a subproject doesn't have the parent project's name in it when it's shown against tasks isn't ideal ("Protogame Version" on it's own doesn't mean much; what if we have multiple projects with Protogame versions?), and this carries across to tasks as well (searching for "Sixty Seconds" doesn't show the subprojects).

Once I added a single task to the subproject, it started working again.

I have concerns giving users too much rope (normal column, milestone, subproject) will result in a lot of confused users and bad feelings towards Phabricator. My general feeling moving forward is that more time will be taken to ensure even with lots of rope, the experience never confuses someone to the point of hating the product. We get many requests that certainly seem reasonable, but once they're wild in the field, lead to a very poor experience. I'd rather start with shorter rope and dole it out over time if that makes sense. In this case I think having multiple cards displaying isn't a good user experience, no matter the logical intent.

I just hit this exception when I had:

The problem is that it means a card may appear more than once on a workboard (in multiple subproject columns) which violates a lot of assumptions the code makes and will probably be confusing to users forever. We technically generate these columns today, they're just hidden at the last second to avoid obvious brokenness in the UI.

(Should I repost the task description as a comment on that task so it doesn't get lost?)

Yeah I realise they're prototype features (and I mentioned so in the task filing). I just wanted to document something that caught me off guard if it wasn't already on your radar.

T10010 is tracking subprojects. It should be labeled in the UI these are currently prototype features.

We have some plans to explore other approaches to "view with comments". I think that's probably the right action overall, and the new edit treatment feels good to me.

The dimmed state is pretty obvious to my eye (it has possibly changed since this was originally filed) and we haven't seen feedback from other installs about this being difficult to parse visually. If we did see more feedback in this vein, I'd want to start by making the dimmed state more aggressive.

In T10288#157504, @epriestley wrote:

If we're requiring setup and active management before we show a bar, maybe this bar is better?

(-----X~~~Y          )

The left side of the bar is "Start Date". The right side of the bar is "End Date".

... snip ...

Yes, in theory -- this is a problem with assigning sub-priorities as a side effect of dragging cards around on a priority-ordered workboard. That code hasn't been touched.

Given all the refactoring, is this still relevant?