http://www.gyro-php.org/documentation/contributions/group__Unidecode.html seems relevant.

Now that I think about this for a bit more there is a security concern here: In given two-factor authentication context, an attacker could MITM the connection between the verifier and prover, obtain the authentication credentials & a single OTP value, and then log in with these credentials within the current time step. This would allow for a second authenticated login, in sudo mode. I initially didn't think of this concern since the attacker can race, but in this case the new connection is created silently.

I filed this as a correctness bug, not as a security bug. There are some attacks that could be performed on such MFA schemes but that are not applicable in phabricator's security model.

A somewhat generic way to do this is to create the notion of a variable such as is_in_deployment and allow Herald rules to check to see if this is set/true/a specific value. If the API to expose the variable is exposed to conduit then also allows for far more interesting workflows (especially when combined with relying on other Herald rules).

Ah, that's how to do it. Create a saved query and then have the dashboard pick it up. Thanks for the info. I was unaware of how dashboards interacted with the rest of the searching infrastructure.

I meant, in the dashboard view: https://www.dropbox.com/s/ud2vy3nfvjd20n4/Screenshot%202015-08-08%2013.24.58.png?dl=0

@chad it isn't possible to search for 'my active authored pastes' which is what we'd like to show in the dashboard. Is this intentional?

This looks identical to T731 except that it refers to audits, not revisions.

@chad: sure. I was just pointing out the dashboard part specifically. There are other places where it makes sense to query for pastes too :-)

It would be nice to be able to query only for active pastes in the pastes dashboard panel:
https://www.dropbox.com/s/seb2l2u5teg5h48/Screenshot%202015-08-05%2020.43.18.png?dl=0
https://www.dropbox.com/s/9kytt9jlqpi82dd/Screenshot%202015-08-05%2020.43.28.png?dl=0
there is no option to limit it to only active pastes.

Its likely safe to detect the existence of .git/svn/.metadata to determine if it really is a git-svn repo or not.

I think Are they both clear, it's just easy to forget when filing tasks? sums it up the best: I am primarily used to other projects and other trackers. Another issue is that sometimes I'll "fast forward" my thoughts: have a problem, think through the solution, and then forget to describe the problem.

I updated the task description hopefully better describing the problem

A few pieces of feedback:

• It would be really nice to be able to split "being able to award this badge" and "being able to edit this badge". You've already said that this isn't something that you're likely to consider but I wanted to mention it here
• Another use case: in certain cases badges directly map to projects ("member of admin team" ~= "phacility high command" or "trusted contribute" ~= "trusted contributor" project)
• It would be nice to be able to "bind badges to external things": for example: we've already had requests for "submitted the most diffs" or "closed the most tasks"
• There is no way to go from a user's pokemon center to the list of other users with the badge. Clicking on it just flips it over.
• The mini-badges don't show up when posting inline comments only or when updating a diff: see this for example: https://www.dropbox.com/s/zu97klycfzb7jtf/Screenshot%202015-07-25%2013.13.36.png?dl=0

Can I get one? Would love one.

there are other use cases that we'd like to use it for. For example

FWIW I'd find this generally useful: allow Herald to add comments to any object. One use case I'd really love to use it for is to "welcome and inform" new users on their first diff letting them know that someone will look at it, common issues, etc.

That isn't a great solution - it should be possible to set a max ram used, rather than max percent free: http://blogs.msdn.com/b/oldnewthing/archive/2012/01/18/10257834.aspx

@jdloft
My point is that just preventing a project from being set to joinable by itself is insufficient. There are other ways to effectively set a project to "joinable by no one" without using the no one policy.

FreeBSD has very strong interest in this sort of API call. It would permit us to integrate better with certain systems that are not part of phabricator. It also makes writing a migration script entirely against conduit feasable.

It is very difficult, if not impossible, to determine if a policy actually means 'no one'. Other ways for this to happen is to set 'joinable by' only to disabled users, to set two projects to be joinable by each other, etc.