Haha, Badges.

Very Nice!

Couple of other things:

Likewise if this only might cause confusion, but has not actually caused confusion yet, it's a hypothetical problem (see Hypotheticals). We don't accept requests to address hypothetical problems because they often never actually occur.

Is your Phabricator up to date?

Please read and follow the guidelines in Contributing Feature Requests and Describing Root Problems. These are required for any request. Specifically this request still omits a root problem and seems to be just a design / ux suggestion. Given we have thousands of tasks and 2 developers, we don't take feature requests that don't have a root problem, we'd never be able to prioritize them.

Thank you very much, I'll take a look :)

Sorry about that. I have added more details to the description.

This request doesn't describe a root problem (see Describing Root Problems), but we can only accept feature requests which completely describe root problems. See Contributing Feature Requests for more.

Where can I find the major features list, any document?

That setup is not supported, and we already raise a setup warning making it clear that major features will not work until the base URI is configured.

Actually, I want use Phabricator on intranet( IP address, https://192.168.1.10/) and internet(https://somedomain.corp...) with different URL, so I keep it empty.
If this is not a bug, can you add this to the section:Troubleshooting in diffusion_hosting.

Why did you choose to ignore the warning, considering that it says "major features will not work properly" until you configure it?

Yes, but I don't know it's related to ssh service.
This problem spend me about 4 hours, I checked everything ...

When phabriator.base-uri is not configured, you should receive this setup warning:

Thanks @epriestley for the reply. Seems like my mental model of "prototypes" along with the misleading wording of "future" threw me off.

@20after4, just a heads up:

As far as I understand, E66 acts as a prototyp (or template), providing defaults for when the individual instances are "materialized" later, when they are edited. Is that correct?

I also had the same problem and solved in the same way!...

Hi @epriestley, thank you for your explanation.

Looks like the JIRA's default door keeper worker. I guess it is automatically discovered when you run arc liberate command.

oh,I'm very sorry. I do a wrong job. manifest.search API can get tasks by milestone. the key phids in constraints support two methods to set. one way is to use project name(this doesn't work for milestone). other way is to use project phids(this work for milestone). I always use project name to set this key, so I can't get the right result. This task can be closed. I am sorry again.

e.g. this is a number1 milestone in Use to test object

Username

Terminate

If anyone else is looking for this, we have this extension in our local install P2019, which does custom things to a JIRA ticket based on Revisions.

E1218 seems to have worked properly after the patch, at least.

I'm pretty sure D16937 fixes this, thanks for the report! Let us know if you're still seeing issues after that.

I think this should be fixed in HEAD now, but you may want to wait a few days to update (e.g., until stable promotes on Friday) since a few bugs related to T11044 have been cropping up since it landed a couple days ago.

Thanks for the lightning response!

Yeah, looks like that reproduced it. Here are the caches:

After D16933, the behavior of arc browse <branch> on the experimental branch is:

Sorry, can't make it this time! I'll catch you guys next time for sure.

Sure, not a problem.

We now export a frequency.json, with string keys in a list. Since we haven't actually collected frequency data, the order is currently (roughly) random:

https://secure.phabricator.com/source/translatewiki/browse/master/projects/phabricator/maniphest/frequency.json;00108900457eda804c9c786dd76ff96620a05195

Hmm, can you try creating a test event on this install to see if you can reproduce it here? I played around with this a little bit locally but wasn't able to get it to break.

It's like before: Neither the orange thing appears nor am I listed as "busy" at my profile. I'm listed as available there.

We now export strings into projects/<project>/<group>/en.json, etc. For example, here are strings which appear ONLY in Maniphest:

Okay, I believe we already produce a format which is compatible with that definition:

1. Proto-english strings.
2. Nested English translations.
3. Variable types.
4. Usage frequency information ("this string has frequency 0.9 out of 1.0", or "this string is part of the 'most common 10% of strings' group").
5. Application groupings ("this string is part of Maniphest").
6. Places in the code where the string appears ("this string appears at x.php line 234").
7. Additional human-readable context information, like "qqq" (very rarely available).