https://secure.phabricator.com/source/phabricator/browse/master/src/infrastructure/markup/PhabricatorMarkupEngine.php;4c7d464f8bf2627ef7455596fde2ae5667e67a57$356

Macros are disabled in Phame posts, via markup engine. This originated in D2202.

I think the way the view gets built is a little odd and I didn't get the logic quite right. Definitely a bug, thanks.

The general headers/sections are mostly scripted now so they should be fairly consistent, but I'm still editing the actual markup at the end of the day.

I think we currently get about equal amounts of "your changelogs should be more detailed" and "your changelogs have too much irrelevant stuff" feedback so I'll take that feedback under consideration but don't plan to make changes unless the overall balance of feedback shifts substantially in one direction.

We support viewerprojects() elsewhere but it isn't currently a component of the "Auditors" datasource. See also T9362#207080. I'll file a version of T9362 for the "Auditors" field.

I'm going to merge this into T5029. This is an extremely low priority for this upstream because this workflow is virtually unheard of among full-time software development professionals (see "Target Audience" in Contributing Feature Requests) because it is inherently error-prone.

How do you make guarantee that unrelated, simultaneous, uncommitted changes in the same working copy do not interfere with each other?

I haven't been able to reproduce this locally by artificially making services unavailable or connections fail. Debugging this in production will require momentary service interruptions on admin until I can narrow things down so I'm going to wait until off-peak to poke at it.

There isn't enough information here for us to reproduce this, or even begin.

You can adjust the validation here:

I think that's right, yes.

Users do count, but I thiiiiiink user mentions are a special kind of mention because they have more complicated rules and you can't read them with edge.search today. T4654 discusses better rules around "notify me when I'm mentioned"; there are some related Conpherence-specific tasks too.

Sometimes, Apache is configured with a rule which prevents any access to any URL which contains /..

courageous 🎆

I dropped the cache, looks like they're working.

Specifically, I suspect it won't affect repo because db restarts separately, so the database won't be unavailable when daemons on repo restart.

It looks like this might be an issue with MySQL not being available yet when the daemons start. The deployment script restarts MySQL, then immediately restarts the daemons, and a bunch of this stuff is ending up in the log in the 1-2 seconds after the restart:

I believe that's unavoidable with offset-based paging (the solution is to switch to cursor-based paging, but I think we can't do that for fulltext).

🍞 🐦

fancy 👑

I think bin/cache purge --purge-user will do it (but for every user). There's no way to do it for just one user, I don't think.

I've implemented a new edge.search API method. This method generally works similarly to other *.search API methods:

This should now be fixed in HEAD of master. Thanks for the report!

Here's the intended behavior from the source:

The build system should be able to call Phabricator via Conduit and ask for revision status today if you want a short-term fix.

Hrrm, it looks like my reply to your email bounced. Short answer is that we don't offer anything special for academic or open source right now. We'd like to in the future, but are focusing on building our core business first.

(That is, the expected failure mode of this query when it fails to scale is "silently return an incomplete result set", not "be really slow".)

To start with here, let's identify exactly what's slow? It's not clear to me from the downstream task unless I'm just misreading, and not evident to me from reasoning about the behavior of this query. This query strategy is fundamentally not scalable, but I would not expect it to be slow unless the ElasticSearch query is slow.

The results are ordered by "match strength", but this is computed at runtime and isn't unique to each result: we can't start with the 100th result and use it to build any sort of clause like WHERE rank > 12345 that starts on the 101st result.

Sorry, this isn't a feature request we can accept. See Support Resources for help understanding what kind of support is available, and Contributing Feature Requests for help with feature requests.

See T10109. I'm going to merge this into T2543.

You've personally observed a build trigger as the result of a user choosing "Plan Changes"?

The document contains "bash". This behavior seems correct to me.

This should be resolved at HEAD of master, thanks for the report!

Something like:

We've implemented a basic version of this, roughly along the lines of the recommendation above. Here's how it works:

(I think I've used this workflow fewer than 5 times outside of testing, and although similar workflows like "Award Badge" and "Add Project Members" have the same issue, I think they're similarly rare.)

This is also nontrivial: when we display a dialog, we already attempt to focus the first input. But the first input here is a tokenizer, not a real input, and naively focusing it fails because it hasn't activated or rendered yet.

D17452 marks this as resolved and makes these changes:

A basic version of this is now available in HEAD of master. Here's a walkthrough of what we've implemented and a discussion of some areas where we'd like feedback.

Closing this since there doesn't seem to be any thing left that's actionable for us.

That's the default behavior, and you can achieve it by deleting "Name":

You can set history.immutable to true in your repository to prevent arc from performing mutation operations (amends, squash-merges).

(And, if our behavior is "confusing fatal", that could prevent new installs from getting far enough to even see the setup warning saying "install gd".)

I think all the other requirements are usually builtin (we "require" them only because it's possible to remove them, and some distros occasionally do for kind-of-maybe-questionable reasons) but I think it's basically like requiring your car to have tires.

This runs into T5873, which is a large task. The very short version is:

I think the NUX case is fairly tricky. I need to look at the code, but I'm thinking something like:

Cool, sounds good.

In my experience, it is very unusual for organizations to have multiple distinct internal groups with different identity providers. Normally, organizations which value SSO and identity management consolidate identities under a single provider, because that avoids problems like this, greatly simplifies identity management, and doesn't require other pieces of software to support multiple providers.

Why are you sharing an instance between two separate groups with separate identity providers?