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.

If so, how do I assign something to a member (or whomever) who doesn't yet/right now have a shown task?

That is, this is a valid column:

There's some argument for showing more headers than the actual assignees, so you can assign a task to someone with no tasks currently assigned.

Haha. I really do think "suggest a profile picture" might turn out to be pretty fun. Maybe I'll kick out that and {button} if I want to take a break before doing callsigns.

@kaldari Most of this ticket is asking for "save priority as the default order" and/or "save 'open tasks' as the default filter" or something similar. Those were implemented by D15260, and are now supported. You can see them in action on this install, and D15260 has a couple of screenshots of the feature.

I suppose that typing Points between [2] and [3.9999999999] is probably an acceptable workaround for expressing the range [2, 4) if anyone does come up with a use case that requires exclusive ranges.

Thanks, that's helpful. That's pretty much what I figured, and it's reassuring that no one has come up with "exactly 3, 5, or 11 points" use cases, or use cases that require a mixture of inclusive and exclusive ranges, at least so far.

My tentative plan here is to write a script that does it and make it available in this task. I want to do this a bit on this install too, mostly so we can have better direct exposure to these features ourselves.

Yeah, why don't you file a separate task for the importer thing. I saw https://phabricator.wikimedia.org/T123078 on WMF recently, too. I think there will probably be enough demand for this to bring something formal upstream, but maybe only a few installs care (or everyone has different weird requirements) and we can just throw a script up somewhere and not have to maintain it.

At HEAD: