If we put spaces on user accounts, how do I get into a Space you have permission to see so you can add me as a Manager on the payment account for phacility.phacility.com in Phortune using the typeahead?

Thanks for this - suggested solution works perfectly!

Spaces for user accounts?

#dropbox has also encountered this since upgrading from MySQL 5.5 to MySQL 5.7, and thus an InnoDB FTS backend.

We use (most of) the graph code for drawing the "Task Graph" and the "Revision Graph" so we need to keep it around in the upstream anyway.

This is fundamentally unfixable

doh! nice. I obviously need more coffee.

("Graph" button in upper right.)

https://secure.phabricator.com/source/phabricator/history/master/

I know just maintaining the hooks is more work but certainly less than what's involved in maintaining the graph code.

I think that's what D18131 did -- or do you mean something else?

Maybe provide some extension hook-points in diffusion so that the community can maintain the commit graph visualization as an extension?

This is fundamentally unfixable:

I think we're more-or-less at the point where the existing Nuance code is about as internally modernized as it's going to get, so there isn't a great deal of remaining obvious technical debt to pay down.

At HEAD of master:

This is "fixed" by the associated series of diffs, in the sense that the actual problem (being unable to delete web UI config) is fixed. This is remaining work:

@chad yes it is but I don’t want to disable it everywhere. It’s quite useful. Most websites just disable it selectively in places like search bars. I would also recommend disabling on form input like settings. Especially anywhere where phabricator autocompletes to some object like a project/user for access control etc. I hit this a lot while modifying many repositories visibility policies.

See T12874. Your account will be disabled if you continue creating tasks like this. Follow the instructions you were given.

See Support Resources

You can find tasks with no owner by searching for "No Owner", like this:

This is something that is needed every day, e.g. find tickets which are not yet assigned..

/config/edit/translation.override/ then add the string, and what you want it to say instead. That's the quickest path here. Merging into the other request.

Can you be more specific here? If you just want to rename "LDAP Login" you can already do that with the translation framework.

I believe that's a Safari feature that you can disable?

They already --prune when pulling:

We've run into this same problem, but in the phabricator daemons. They also, apparently, run commands like:

git branch --verbose --no-abbrev --contains <sha> --

For private reasons affecting the reporting install, this no longer has customer impact.

OOOFFFAAHHH

This might not be totally related but

1. I really love being able to see the filename while scrolling through files
2. It would be useful to have something similar to Diffusion's File Search on a Differential revision, to quickly jump to files based on name. The f sidebar helps a little but it's organized in a file-system layout which means the folder location needs to be known.

That sounds like a bug, but my guess is that the investigation would probably turn up "wow you are dumb at writing software" in about 3 minutes and not really get us much closer to a fix, which is probably "rewrite arc patch to fix 200 problems".

For (1), it's currently expected, yes. We don't create branches for dependencies in Git either, currently. I don't think this is terribly unreasonable, but I'm also not sure it's terribly useful (does it just help you keep track of which commits are part of the leaf?) and it makes cleanup more difficult by creating more total branch/bookmark artifacts in the local working copy.

Also, I've noticed that when applying dependent revisions like this, it seems that usually all of the commits will apply cleanly (without prompting) except for the last one, which will always fail to locate the commit to apply on and prompt whether to apply to current working copy state. Based on what I think arcanist is doing I would expect all patches to prompt whether to apply to working copy (since all patches will be given new commit IDs) -- it seems strange that all will apply cleanly except the last one. Does that sound like a bug or am I misunderstanding what's happening? I can try to investigate/debug if you think it might be a bug.

For (1), it is expected to not apply bookmarks to dependency changesets that are applied as part of the patch issued? When patched one-by-one they would each obtain their bookmark.

D18152 should improve this: we'll still select the item as the default item, but will now render the navigation normally so the user can click other items:

Specifically, the issue is that multiple different priorities used the same keywords ("low", "high").

Sorry, I should have led with a screenshot! I'm the biggest nitpicker, I know.

This looks like the update changed the behaviour, not sure if this is intended, but it broke configs, that worked before. I currently fixed this by chaning my config to:

{
  "100": {
    "name": "Unbreak Now!",
    "short": "Unbreak!",
    "color": "pink",
    "keywords": [
      "unbreak"
    ]
  },
  "90": {
    "name": "Needs Triage",
    "short": "Triage",
    "color": "violet",
    "keywords": [
      "triage"
    ]
  },
  "80": {
    "name": "High",
    "short": "High",
    "color": "red",
    "keywords": [
      "high"
    ]
  },
  "70": {
    "name": "Higher than normal",
    "short": "Higher than normal",
    "color": "orange",
    "keywords": [
      "high-than-normal"
    ]
  },
  "50": {
    "name": "Normal",
    "short": "Normal",
    "color": "yellow",
    "keywords": [
      "normal"
    ]
  },
  "25": {
    "name": "Lower than normal",
    "short": "Lower than normal",
    "color": "green",
    "keywords": [
      "lower-than-normal"
    ]
  },
  "1": {
    "name": "Low",
    "short": "Low",
    "color": "sky",
    "keywords": [
      "low"
    ]
  },
  "0": {
    "name": "Wishlist",
    "short": "Wishlist",
    "color": "skyblue",
    "keywords": [
      "wishlist"
    ]
  }
}

I think that these use to exist and were moved to a help document somewhere.

I was able to track this down: This is happening since {rP8008ade9af46d417aec187f4213118d220077b32}.

(That is, our behavior seems clearly incorrect.)

This just looks unambiguously wrong to me.

I'm going to modularize this, but not before the release cut.

Some of the (3), (2), (1) stuff is that we're trying to pick a single behavior which addresses most use cases reasonably well. For example, if we use "natural" bookmark names that will tend to make things much worse for users in bucket (3).

I can verify this fixes it! Thanks for this guys.