I'm vaguely assuming this should work reading the code for PhrictionDocument.

See T4675#57776 for a local workaround for now.

In T3179#169180, @Kunda wrote:

Any MantisBT -> Phabricator migration scripts ?

Awesome! I appreciate the quick fixes!

• This constraint should be fixed at HEAD of master. We just missed the deploy so it won't go until the cluster until next week (around August 20). Let me know if I missed anything.
• Empty constraints should be fixed at HEAD of master (they now error instead of being ignored).
• buildablePHID vs objectPHID confusion and inconsistencies should be fixed in the future by harbormaster.buildable.search. If you want a skeletal version of this now to reduce API tweaks later, let me know and we can get one in pretty easily.
• Linking to pre-filled forms seems maybe not hugely useful in practice, with some small risk of social engineering attacks? Feel free to file a separate request if you have use cases I'm not thinking of or whatever.

Fix CORGI errors, check if that reveals any obvious indicators of instance information fetch issues.

READMEs are only rendered in the browse view:

Was rendering disabled altogether? https://secure.phabricator.com/diffusion/P/browse/master/README.md shows up as a mere textarea.

Slightly easier is:

I was able to reproduce this, possibly, by following these steps:

No disruption is expected and there was no maintenance or known disruption at those times. Nothing jumps out at me immediately in monitoring, either, and I can't reproduce this by casually cloning stuff.

D16396 should make us raise a narrow error for "ids": [], "phids": [], "whateverPHIDs": [], etc., instructing you to pass a nonempty list.

I think fixing "ids":[] is trivial; it just works like that because we use the same Conduit type ("PHIDList") both for constraints and other things which can accept an empty array (like setting subscribers to [] to remove all the subscribers on an object).

(@yelirekim, just a heads up since whatever comes of this might impact you somehow.)

Great! It looks like we're down from about 18K to 3K on repo001 too, so it appears that this pretty much works as expected.

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

In T11471#190079, @chad wrote:

I don't consider this to be a bug and any fix would likely lead to additional user confusion over "magic".

This has promoted to stable and doesn't seem like a contentious change so I don't currently anticipate any need to keep this open or revisit it.

Personal Herald rules do not run for disabled users, so disabling a user will disable all of their personal rules.

I also don't necessarily consider this a bug (I think a human explicitly @mention-ing a user definitely should add them again, and that quoting someone is pretty close to mentioning them, and that reasonable users could probably expect either behavior, and perhaps that the "add them again" behavior is more obvious or more expected) but T11035 discusses this and some other behaviors which have varying amounts of grey area.

The use case in that linked task is "using Remarkup to demonstrate the behavior of a different markup language", which isn't something we expect Remarkup to support.

The example is pretty descriptive, I'd say. Because of linking to the description of that exact part of the word.

Why do you want to link part of a word?

What specific steps can I follow to reproduce this issue? See Providing Reproduction Steps for help.

slightly related: there's some confusing naming in the result for harbormaster.querybuildables:

I don't consider this to be a bug and any fix would likely lead to additional user confusion over "magic".

I've used a mac for ~6 years now and still get annoyed that Finder won't list folders above files sorted by name. For me the folders work as a navigation control instead of content which is why I usually like them separate. My preference said, it doesn't really affect me in Diffusion.

See additional discussion in D9343.

secure.phabricator.com isn't in the Phacility cluster

Why do you mean by "this instance"?

I got code 500 as I checked out from this instance, was about 23:50 UTC, yesterday. Maybe related? After getting that code, I tried it again after about 10 seconds, then, everything was ok.

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

How difficult would this be for someone to implement / does upstream have an implementation timeline for this?

If commits will end up in a tab, are there any plans on changing the link format at the commit list in the details section? It can sometimes become poorly readable since the links consists of repo and revision data prior to the messages.

After merging with upstream, we were able to increase our taskmasters up to 32, and still not come anywhere close to the number of connections that were previously used. So far, so good on our end.

I have 7 panels for new Phacility Admin, trying to think of one last action panel..... .... .... memes?!? Good idea or great idea?

I would also maybe check webserver error logs, too. OS/Browser might help to know as well.

I can't reproduce this based on the steps provided. Have you been able to reproduce in a clean environment like a test instance on http://phacility.com ?

In my personal opinion adding a CC that cannot see the task is an error and like this should be treated, meaning ux should just report as error when try to save it. It is important that ux reports it since it can be overlooked by the person changing the task.

I added you to Community, granting you sweeping janitorial powers on this install.

It's not 100% reliable but we can use that to make a pretty good guess.

For those moving from MantisBT into Phabricator Maniphest I'm activily building a full import web based tool that will extract just about anything from mantis, allow editing/ touching up, then process the import into a Phab conduit.

This is resolved on my end.

We know if someone has set up arcanist, correct? They ran arc install-certificate?

Please close - I figured out how to change the username. Not sure why I missed it the first time :(

Yeah, my main concern here is it sounds like you're working around #reviewers by installing a different dashboard on everyone's homepage. In which case maybe moving #reviewers to a CC instead might be better. People will still retain awareness, but the reviews will be optional. Pinterest also has some sort of round robin thing built for not overloading a group of reviewers. https://engineering.pinterest.com/blog/shipping-faster-new-pr-processing-system

It's very likely that our workflow is suboptimal, to be honest I just learned about this #reviewers group so I'll definitely discuss this with other people here.

Is it a reasonable possibility at looking at being more surgical with how project reviewers are added? Our general MO here is reviews should programmatically get targeted to the minimum set of responsible individuals, and people who want to be included outside of that use tools like Herald to watch for diffs they are not included on. Things like setting up code ownership packages, or making different projects for different types of diffs might make reviewing much easier.

No worries, I just started reporting issues upstream and it takes a while for me to understand what are your expectations and where they differ from mine. :D

Thanks, this is super helpful. Sorry for the back and forth.

The current status:

Specifically, it sounds like you want to exclude diffs you're on as a project reviewer for? But only as a panel, you still want to be on those diffs overall?

I'm trying to set up a panel listing reviews where the current user has been explicitly tagged.

I'm sorry if I sound like proposing solutions instead of taking more time to think about the larger problem, it's just that I have two readily available tools (viewer() and exact()) that combined would do exactly what I needed right now, but I just cannot combine them.

Here's github's version of this, as an example.