👍 worked fine for me, thank you!

No, that was some stray debugging code. I updated the script.

Ah cool, I think that'll work, noticing this:

UPDATE `phabricator_maniphest`.`maniphest_task` SET points = 2 WHERE id = 4130;
UPDATE `phabricator_maniphest`.`maniphest_task` SET points = 2 WHERE id = 4129;
HAS POINTSHAS POINTSUPDATE `phabricator_maniphest`.`maniphest_task` SET points = 0 WHERE id = 4201;
HAS POINTSHAS POINTSHAS POINTSHAS POINTS

You may be able to just comment out that check, but I'm not sure how the extension stores its data. You'd have to check with the authors to be sure.

We're using the wikimedia sprint extension, which adds a isdc:sprint:storypoints field - upon running ./copy_points.php --field isdc:sprint:storypoints, we get

[2016-02-16 18:46:22] EXCEPTION: (PhutilArgumentUsageException) Field "isdc:sprint:storypoints" is not an "int" field, and can not be migrated. at [<phabricator>/copy_points.php:62]
arcanist(head=master, ref.master=fcc11b3a2781), phabricator(head=master, ref.master=608fcdd9dd70, custom=2), phutil(head=master, ref.master=f43291e99d36), sprint(head=master, ref.master=802afc636035)

New watch stuff should be live now.

I didn't immediately even know I was on a Milestone. I should probably put more thought into the tag UI.

Yeah, that's buggy. I think I that only got partially implemented. My plan is:

Should I be able to watch a Milestone? https://secure.phabricator.com/project/profile/1418/ clicking "Watch Project" just reloads the page with no changes.

In T10349#159385, @epriestley wrote:

@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"?

(I generally agree that we probably do need more default or optional disambiguation here, but want to make sure we're making the best tradeoffs we can as we move forward.)

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.

Just to clarify on your last question: I wanted to be able to do "Members of: Department A". I guess my idea of putting the members on a random subproject is the way to go for this (and I think that's what you are suggesting). Also, it's not strictly a matter of security, we use it for visibility purposes too (like when a user opens "Projects" we'd rather show them those that are relevant to their department by default and have him manually search for others).

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

It's mostly a control thing, I can't think of any real world dangers. Eventually we plan on having even more limited access groups (for external users, similar to this installation) where there would definitely be a concern, but that may not have anything to do with this task.

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

Typically the latter (Department A can see Department B's stuff but not edit).

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

When I say subscription I mean membership. We use projects as the top-level partition for all different "departments" that use Phabricator. So say Department A has a project B and project C in which the entire department should really be members, they now have to add the members to both project A and project B. Unless I am not understanding this fully. Ultimately we use project membership in permission/membership entries for tasks and other areas (like queries/dashboards) specific to each department.

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

My .02 fwiw: It would be nice if there could be members of a parent project (which will effectively mean that they are members of all subprojects) so that users don't have to subscribe to each subproject individually. Maybe just as a "default membership" list that copies to each subproject since membership of a parent project is now deemed to be a union of all subprojects...

My thoughts on the subproject UI concerns: We were really looking forward to subprojects especially to simplify organization of software components and their appearance in the UI. For example, we have multiple projects managed by the same Phabricator instance and software projects tend to have the same name for many software components like Core, UI, and so on.

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

Commenting to show my interest in such a script. I'd be completely fine if the migration script did what @jdforrester described and merged members of A to B.

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.

@epriestley I need to suggest a profile photo to @cburroughs

We have like 50 "Team X Sprint 123" projects that would be nice to turn into "actual" sprints. But they are all old sprints so that's just for my need to keep things looking tidy.

In T10350#159113, @epriestley wrote:

@jdforrester, in your situation, how would you want to handle members?

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.

Registering my interest for being able to move projects into being sub-projects. See https://phabricator.wikimedia.org/project/profile/483/ for an example of using faked sub-projects (with, collectively, thousands of tasks) which I'd love if possible to make "real" without making ten thousand bulk edits, modifying long-dead tasks and melting people's inboxes. Should I file a specific task?

This is now substantially complete.

This is now substantially complete.

This is now substantially complete.

I don't think we can guess right for stuff like "Version 6.5" or "Sprint 4/31" without doing a lot of work, since "add 1 to any numbers" won't work in those cases.

For now, I'm just going to do this:

I think this should all work properly and consistently now, let me know if anyone finds a way to break it.

I slightly prefer the one with the grey background, as it adds a visible container around the activities (and makes the whole page less white). But on the other hand, I also like the overlay-ish aspect of the description, milestones, members and watchers list on the white background.
So no really strong opinion; I like both of them.

What do you use it for? That is, what are you trying to do when you click it?

Instead, it now throws this exception.

In T10311#158135, @chad wrote:

Thanks for clarifying!

In implementing the new profile avatars, I stopped short of randomly assigning them based on UID. I might look into that again.

no workboards at all. Also not JIRA Agile, just "JIRA Clasic," I think.
I just like profile pictures.

You use workboards at all or JIRA Agile?

In T10308#158092, @chad wrote:

haha, It's on my mind to provide more incentive for people to set their photos.

Yeah, I think the end vision as in your mockup looks pretty nifty. Maybe part of the issue is that the photo thumbs feel kind of chunky in the workboard right now.

haha, It's on my mind to provide more incentive for people to set their photos. Profiles are a bit prettier now.

In T10308#158087, @chad wrote:

It's helpful if we understand the core issue you'd use names. That is, what are you looking for by seeing who is assigned?

It's helpful if we understand the core issue you'd use names. That is, what are you looking for by seeing who is assigned?

FWIW, the second issue listed here is biting me too a bit on my install.

Yeah, I'll probably add the extension when I get off work.

@hach-que there is an extension above to make transition easier.

In T10308#158023, @cburroughs wrote:

We removed the default task link because in many cases, the link to all tasks wasn't used, wasn't useful, or wasn't the best link (e.g., maybe several links or a link with different filters would be better). Particularly, the link was often redundant when projects use workboards.

I find myself clicking on a project to get to a list of tickets and then realizing that doesn't work often enough to notice. Maybe I am just used to the old way? For projects I use a lot adding dividers, urls, and motivational quotes has been nice. But customizing every single little "tag" project with a unique url doesn't feel super fun. Would you be open to a "search for open tickets in this project" PhabricatorProfilePanel?

The rest of this will roll up into other tasks which actually use it, etc.

This probably still isn't perfect, but: