Calling PhabricatorProjectsMembershipIndexEngineExtension's rematerialize in move_to_root.php should automatically set hasSubprojects and hasMilestones

Maybe T6038.

Some of this is fixed; the rest of it doesn't have outstanding customer requests.

Subprojects do not currently appear on workboards as columns.

And keep this such way. Please take a look Comment with improvements to "Ability to reorder milestones on a project's workboard".

The funny thing is that event if I remove the file from Files, the coverage image in the Maniphest is still there. :)

Thanks @epriestley and @rfreebern - your scripts worked perfectly! Between them both (and tweaking that one "hasSubprojects" field in the database myself), I was able to move an entire project tree. Yay!

+1 to hide cover as an option on the board

I can't reproduce this, and I suspect it was fixed some time ago during changes related to T6027.

In T10308#158036, @epriestley wrote:

I think I could just build this as an extension? (I've never built one, so I'm a little interested in building one for practice)

Yes:

You can create your own link to tasks in a few seconds; the extension above will reduce this further. I don't plan to bring a global, hard-coded "Open Tasks" link to the upstream.

Probably should be two separate tasks. 1 is implementing some sort of "global" menuitem for projects. The other is adding group by queries to workboards, which I think is already covered in another task.

I can't reproduce this.

Oh, sorry! I added you to Community so you should now have edit power.

Could someone with superpowers please edit the task summary to describe the actual task content? Like
Bring back links to task lists on project pages; list name of assignee in workboard cards
? (Or who do I have to bribe to get such rights?) Thanks in advance.

@epriestley, sure, I was not (intentionally) trying to be against subproject columns per se. I think they are a good way forward for making subprojects more usable.

I do not plan to ever let you reorder milestones.

my current view is basically that the official subprojects implementation only makes this much more clunky and restricts some parts of it, rather than moves it forward. As it is, the current subproject implementation doesn't seem to do much else than make a couple of links appear, and restrict the usage of some features (tagging and project membership handling are changed/restricted, at least).

Ok, thanks for the explanation!

Broadly, I think the two above comments are expressing a mixture of two ideas:

The proposed behavior (no subproject columns) means that tasks could be in multiple different columns at different levels, since they'd be draggable normally on each workboard:

The feeling now is that by assigning a task to a subproject it "dissapears", since it cannot be tracked in the workboard with milestones of the parent project, and is two extra clicks away: Subprojects > Mac OS X.

As you described, the model would be very complex considering a task can be in more than one subprojects, or a milestone. Why is it needed to have separate columns for subprojects in a parent project's workboard?

I just wanted to pop in and comment on the UI for projects.

Well, it turns out I mis-typed the project name! It's just the error message not so friendly. I can reproduce the error with this:

./move_beneath.php --parent aaa --child bbb --keep-members both --subproject

OK, I got it worked for 2 other projects. So there must be something special with the 2 projects I tried previously.

Thanks, I will try to test more.

I can't reproduce any errors with the script against a new/clean install. Any ideas on what I can do differently to reproduce this?

Yes, It was some local encoding handling related and should not be related to the error. My code base is this:

@RuralHunter these aren't versions of Phabricator we produce. How have you modified your local install?

It seems the move_beneath.php doesn't work any more with the latest code.

Users are somewhat surprised that adding a project removes another project (Due to being sub/parent-project); Partly that's because there's no hint in the editor that this is about to happen, or that the 2 projects are related.

In T3670#178894, @bhush9 wrote:

I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?

I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?

This also reproduced with normal "Edit Projects", it wasn't specific to the bulk editor.

Confirm bug that is, no idea about SQL query.

I can confirm.

In T10349#160861, @chad wrote:

Maybe a config option to make your own regex for display?

For prioritization, I estimate we can complete this within 6 hours. It may all be straightforward and easier than that, but there are enough weird edge cases and UI implications that I don't want to commit to a best-case estimate.

In T10349#177108, @joshuaspence wrote:

I thought that there was already a ticket for this somewhere, but maybe not?)

Sure, let me split the subproject/workboard piece out and we can walk through it. (I may not get to this tonight because I have had a long day of Business Things.)

Would it be possible to prioritize part of this ticket? Specifically, the use case mentioned in T10627? We are also interested in the ability for members of a project being able to create subprojects without requiring global "Can Create" permissions for Projects (I thought that there was already a ticket for this somewhere, but maybe not?)

@sascha-egerer that would seem to be the main factor, and the reason this couldn't be duplicated initially. It isn't all milestones - it is specifically milestones for projects that have subprojects.

@CodeMouse92 yes the project has a subproject. But changing the policies as described above works around that issue.

I know this was linked against my question, but I wanted to check and see if it is the same thing...

Selecting Exact Projects: Searching for a superproject currently searches for objects tagged with that project or any subproject. We may introduce a function like exact(#superproject) in the future to search only for a superproject, exactly. However, it's not clear if this is really necessary or has any use cases.

D15942 restores the project tag transaction to the first mail about an object:

I guess this originally had several different parts. My thinking on the parts are:

or that

Better to do the header tags in the body text thing?

I think we're mostly unsure what we want to do here.

Is this task open to be Prioritized? Wikimedia is discussing the possibility to fund it at https://phabricator.wikimedia.org/T135327

I'm going to guess this is the same as T10779

Oh, one problem with that script: when you move all the subprojects or milestones out from under a parent, it doesn't set the parent's hasMilestones or hasSubprojects fields to 0 for you. That'll have to be done by hand in the database.

I'm in the position where I need to re-parent an existing hierarchy of projects, which isn't supported by @epriestley's move_beneath.php above. Rather than attempt to figure out everything involved in doing that (which I think is mostly messing with the various projects' path, pathKey, and depth fields, in case anyone wants to try) I threw this script together to move an existing subproject or milestone to root level, where it can then be moved using move_beneath.php.

Wooo! I think this completely covers my old request at T9520: Allow Workboards to show a thumbnail image within each card. :-)

haha, no, i don't like it either, but it is at least intentional. I just didn't have any better ideas (and I think we took two passes on it).

Now, I do agree with you this interaction is imperfect and could be improved, and your feedback is duly noted, but we're a team of 2 here with 1500 tasks open, so some things are just be imperfect until next time we're in the product.

'No points' or simply showing nothing is less information

@chad 'No points' or simply showing nothing is less information. An incomplete word isn't a deliberate choice to show less information, it's how it happened to land. Anyway, seems like you consider it a feature, so I'll leave it alo

I believe less information when the user has chosen to collapse the nav is aligned with expectations.

@chad If the verbosity is essential, perhaps it should be word-wrapped in the collapsed case, rather than truncated?

The language is that no tasks have points, 'no tasks' might solve a small edge case, but as soon as the first task appears with no points, the longer text is more correct. We tend to lean towards over explaining cases as to limit upstream support time.

From T10891:
When you have the side project profile panels collapsed, then go to create a new milestone, it will have no tasks. The profile panel then shows 'This milestone has no tasks yet', but brutally cut off to 'This mileston-' in the collapsed view.