I think the settings thing got fixed, and we're probably (?) going to move away from widgets in the next iteration.

At least so far, this doesn't seem like an acute problem. I'm going to close it until we have specific feedback.

I'm just going to close this out for now, we'll clean up any remaining crud in the next iteration.

I think the script was removed around the time AphrontSite was written, because it was using a pretty hacky approach to figure out the right controller. You can now find the current controller in DarkConsole → Request → Controller:

That fix isn't retroactive, but I'll deploy it here now so future slowvotes benefit.

I think you should be good to go at HEAD now, let me know if I missed anything.

OH HA HA HA NO YOU CAN'T

Yeah, "Department A > Team Members" or "Department A > Other people who should have edit access even though they are not formally members of any subproject" both seem like reasonable approaches to that issue to me.

I think the external thing should be able to set policies correctly today, although maybe I'm misremembering something.

Alright. Some general thoughts, not sure if any of this is helpful:

Currently, no block elements (lists, tables, code blocks, interpreter blocks, etc) work inside table cells. They interpret their content as inline only. So this is the expected behavior.

What specific bad outcome are you concerned about if Department A can edit Department B's objects? That is, why is it important that these edits be prevented? For your organization, what's the worst case scenario if everything is just editable by "All Users"?

Do you not want Department A to see any of Department B's stuff?

Thanks for the report! D15274 should make this dialog more user-friendly once it lands.

T10358 discusses a case where we use (valid, spec-compliant) JSON for presentation, but could use an alternate form which is more human readable (specifically, when displaying unicode characters).

@kislinsk In cases like the one you describe (which I consider reasonable), what's your major concern with naming the subproject "ABC (Core)" to resolve the ambiguity of a task tagged with both "ABC > Core" and "XYZ > Core"?

Why do you want to subscribe to all subprojects of a parent project individually? Can you talk about your use case in greater detail?

You are out of date: update Phabricator to resolve this issue.

For example, here's a possible sequence of events which might be leading to this:

Do you know why users are adding "All Committers" as "Reviewers"? We haven't seen that on this install, but maybe your flow is different somehow?

I'm leaning toward this:

This task now has scripts to migrate points and move projects underneath other projects. Let me know if you run into issues.

I'll lump that into T10350.