That's expected, and not a bug. "Blocking" is currently a top-level status. When a reviewer becomes "Rejecting", they are no longer "Blocking". This doesn't matter in terms of the workflow, because both "Rejecting" and "Blocking" prevent a revision from transitioning to "Accepted".

In T12516#218475, @rabahmeradi wrote:

Is this really the new 'Needs review' icon or I have problem with fonts?

Is this really the new 'Needs review' icon or I have problem with fonts?

↑ I second @rros, commenting line line 71 of the PhabricatorRepositoryRefEngine class fixed it for me. Don't know about possible secondary effect but I have the feeling it was not working as intended anyway.

Happy to accept a patch for these!

If you have questions about Phabricator, please use Conpherence General Chat or Ponder.

I've repeated this again, taking some screen dumps. This time I did it on a Phacility hosted instance, instead of on our self-hosted instance.

Feel free to submit patches for these!

That's OK.

See T12515 for followup guidance.

I'm going to merge this into T11314, but I don't want to hard-code rules around specific names used by GitHub/GitLab. We can provide more tools to manage these refs, but I don't think the right tool is a bunch of hard-coded rules. These refs are real refs which exist in the repository, and Diffusion should be able to represent them. A driving use case for the original change was a desire to expose Gerrit refs.

Just tested, works great. Thanks for the quick fix!

I think things should work now, let me know if you're still seeing issues. Thanks for the report!

Argh! I broke it while doing last-minute fixes to improve rendering, fix in a moment.

No prob! If it helps:

Thanks, that definitely looks like a bug.

Not sure if this is a known bug / missing feature, but FYI just in case...

@avivey I was hanging my head in RTFM shame, TBH.

No. You should list the (actual, real, day-to-day, not theoretical) things you want to be able to do that you currently can not, or which you do at significant time or complexity cost through cumbersome workarounds. Optionally, you might also say "in other cases, we currently use Wikimedia templates to solve these". Suggesting a solution is the least important part of a feature request.

I gave a trivial example as that is better than a complicated one.

I gave a trivial example as that is better than a complicated one. In a huge wiki, like Wikipedia templates are used for all kinds of things besides making links simpler.

(That said, the hash cost may become very relevant when we eventually ship "Phabricator Valuable Golden Coin Money", our blockchain-based virtual currency.)

See T12511#218328.

There is basically zero chance we're going to implement parameterized templates which can call one another (easily dozens of hours of work) if the only real use case is making RFC5555 autolink (works today with InlineRule, takes a few minutes to make work).

T12511 is about a very different problem and use case. This request is about adding a feature that "will allow users to quickly create a wiki page with some specific base content.". T12511 is about adding a feature that lets users create a bit or markup that acts as a macro/function/template that generates a few lines of markup within a page.

I do not think this is a duplicate. T3963 is about creating template Wiki pages that start off ready populated with some basic data. This request is about creating a Macro like tag (which is part of the Templates feature in WikiMedia markup) not about creating pre-canned pages.

I get these rough per-hash costs locally (Macbook Pro), with a 64-byte key:

Piece of info (you guys might already be aware of it) which might be of interest when implementing this; SHA512 is often faster then SHA256 on x64. See for example: https://crypto.stackexchange.com/questions/26336/sha512-faster-than-sha256

I'm having trouble reproducing this, but maybe I'm not fully understanding what you're running into?

Some guidance about "configure captchas if you're a public-facing, password-login install" would be good here too, but maybe we should just raise it as a setup issue if you have password auth enabled, and let users ignore it if they're VPN'd.

T12511 discusses some possible use cases, but they are all in the form of {{name|123}} expanding to [[ something.com/123 | 123 ]] (external bug trackers, RFCs, etc).

In the future, please report security issues via HackerOne: https://hackerone.com/phabricator -- notably, this allows us to award you a security bounty if you discover an issue.

yeah, sorry, in retrospect this is a real underwhelming test

am disappoint

I'm maybe going to try to do this in the short term:

I deployed that and created this masterpiece:

Almost certainly fallout from the increased strictness in D17616, thanks.

I'm going to call this resolved; T9979 is the survivor for Files and the Maniphest case is probably more involved (T6721).

Just dropping this here since it's the first hit for "SAML" and makes it easier for me to contextualize things when I quote $50K for it, which I'm starting to think is too low:

The HackerOne issue for this is here:

The security part of this is fixed by D17625, but I'm planning to write a support script like bin/files integrity or similar to do things like "compute hashes for existing files" and "check that a file or set of files match their integrity hashes".

This appears to be resolved for me, now. Handling Range: bytes=123- and Range: bytes=0- (plus the fixes for the broader issues in T8266 and T12079) seemed to be the key issues.