When searching for a subproject you don't see the parent project in the typeahead results:

With --keep-members parent, the child's members will be wiped out. If the child is becoming a milestone, nothing else happens. If the child is becoming a subproject, the parent's members are then copied to the child.

@nochum, can you explain what you're trying to do in more detail?

Would be nice to be able to skip --keep-members altogether and not move the members over at all. Thanks for the script!

Yes that should work for my use case - I've tested and verified this functionality. Thanks!

oh

Possibly related: T6469: Make it more clear which Workboard Column is 'default'

I request the same, though unrelated to the recent sorting change. I used move_beneath.php from T10350 to convert old milestone-projects into proper milestones of the parent project. Now they show up as the most recent milestones in /project/view/N/?hidden=true as well as in /project/subprojects/N/. I would like to move them manually to the right position. For that I would need to know: How is the sorting order determined currently? And is it possible to change that in any way? Since this affects just a few projects in my case, I would also accept altering the DB directly, if you advise me how to do it.

I was using the move_underneath.php script and noticed that now some tasks are assigned to several milestones in weird ways.

Quick summary here:

I also think the current per-service and per-device granular locking might be better off as a cluster.locked global configuration which prevents creating or editing anything touching a cluster service, so I may pursue that.

This just sounds a lot like "I ran rm -rf /var/repo/X/ and all the data for rX vanished" to me, which is completely expected and should be predictable.

None of the repository replication code is even written, though. What behavior do you expect today?

When we migrate our repository hosting to Phabricator, I plan to setup multiple repository hosts for sufficient redundancy. In this case, I would expect the new hosts to clone the repositories from a read-only slave.

Suppose you have a hosted, active repository and do this:

Just a word to confirm the issue is solved in the new stable release.

For easier onboarding of new users and better discoverability of anchor links in general, how about adding an extra character like "¶" at the end of a heading when hovering over it? This would make it very easy to copy an anchor. An example from the issue tracker Trac:

Thanks! The moving of the host was I think my main point that clarified it for me.

The steps to reproduce are quite simple:

Well, specifically what you were doing, and what issues were caused after. Like moving tiers.

Ok, if you feel this is a bug report, can you list the steps to reproduce the core issue in the description?

If the repository is hosted elsewhere then Phabricator isn't the canonical source, and the other system would be responsible for data anyway.

The problem here is that things will mysteriously stop working. Let's say that I refer to rXabcdef in a comment and then later mark rX as archived and replace my repository tier. Anyone who later clicks on the rXabcdef reference will hit an error.

That's what I mean by "I must be missing something". What data is lost if it's hosted elsewhere?

Even if that means data loss?

My expectation is "archive" means "mark as deleted" in Phabricator.

I disagree that this is the expected behavior, especially if this occurs on hosted repositories (which I can't confirm because I don't have any). If this occurs with hosted repositories, then archived repositories will be forever lost when replacing the repository hosting tier.

I'm missing something I think, this sounds like expected behavior with a reasonable workaround. What's the bug?

test:

• test script:
  test.php490 BDownload
• dumped POST:
  test.txt.gz9 KBDownload
• run:

php test.php 31 && tail test.txt
php test.php 30 && tail test.txt

In T10264#160688, @epriestley wrote:

Does changing window to 31 actually fix it for you?

Does changing window to 31 actually fix it for you?

Still hang...
dumping decompressed result shows input was truncated.

phabot is basically on it's way out (T6875), so you might not get much traction with any change to it.

Sláinte

Cheers

Workboards only. See T4213 for discussion of themes and skinning.

Is the background colours & gradients gonna be workboards only, or are you planning to roll it out across Phabricator over time?

Thanks for verifying the fix!

I can confirm it now works properly for me (5.6) at HEAD.

In the Phacility case, I can also just give these networks a "no one" edit policy, but still need to do the namespace locking.

@ProfFan My pleasure! :-) Thank you for the link - will take a look.

In T6609#160639, @ablekh wrote:

@ProfFan Great job! Thank you for your efforts. BTW, what is Celerity?

@ProfFan Great job! Thank you for your efforts. BTW, what is Celerity?

We ultimately want teams to choose different colors so they can know which workboard they're on at a quick glance.

Yes, I concur, that would be useful.

My understanding is the feature request would be to set a global color instead of white. If all workboards are red or blue or whatever, I don't think it provides any additional hints. I suspect the use case here is @rphl just really likes a specific color and wants them all that color. Which is cool, but we ultimately want teams to choose different colors so they can know which workboard they're on at a quick glance.

I suspect the goal could be to provide visual hints, in addition to the text, to recognize and disambiguate dashboards.

Just changed the code to utilize celerity and now the extension works on all pages and comments :)

From IRC, I think it sounded like this wasn't really a bug so much as a confusing UI (expecting to type one thing when the UI wants something different), exacerbated by the lack of "Browse" working. I'm just going to realign this to be "make browse work".