Phabricator by default doesn't include localization/translations.

SSH keys only got half-upgraded to modern stuff in T10917, but we could finish that at some point and let you tag them with projects -- roughly the same as renaming them, but a little more formal.

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

We are also able to reproduce this on our installation.
Currently we are using Version 05699388804fc6ae1df5a17559917d218c4ec26d of phabricator.

Your answer is right here:

yeah doesn't import ssh from what I see and they just say to use the command-line importer if you can't use the web tool

Here's what I see -- step 1:

I get this screen:

GitHub's import doesn't seem to work with any repositories that require credentials?

Oh, I was looking at this:

GitHub make this reasonably obvious.

People keep getting stuck on this, so we should look at fixing the UI so we don't have to post the documentation over and over.

Thanks.

https://secure.phabricator.com/book/phabricator/article/diffusion_uris/

After further investigation, we might just be able to tell users to set the "Name" field of the key that they want to use for production bastion access. I hadn't previously realised that this field was editable by clicking on the key in the "SSH Public Keys" pane.

A possible alternate approach would be to attachRepository() as a side-effect of validating the transaction instead of while applying the transaction, but then if something throws between the "validate" and "apply" steps we could end up with a URI in a weird state. That probably never actually matters, but feels a little more awkward to me than ordering the transactions.

ok, that makes sense.

It's impossible to create a URI without a repository transaction (it doesn't make sense, since URI objects can't just exist), and we already give you an appropriate error when you try:

That kinda feels like a band-aid... Shouldn't we be able to not-crash for any input? Like if a user will only provide a uri transaction?

One problem with updating this is that recurring events currently work like this:

My initial thought is that we should just reorder these transactions. We should use a stable sort, but that's relatively easy now that we have msortv(). There are probably a handful of other transactions with similar properties in other object types.

if it helps anyone, the workaround "fix" is to place the following code in the file "src/applications/conduit/parametertype/ConduitBoolParameterType.php "

Thanks for the report! I believe this should now be resolved in HEAD of master.

T9854 is also vaguely related, but fairly separate.

I'm just going to close this in favor of the specific ICS (T10747) and Google Calendar (T2334) tasks, which are the only systems we plan to target for now and don't have much in common.

I think this is in reasonable shape, now.

Yes, commit/revision and commit/task relationships can now be managed manually from the web UI.

I'm pretty sure this is fixed now with the Edit Related Objects menu awesomeness! Thanks.

I'm going to merge this into T11269, which I believe describes the same problem.

Thanks for the report! I think this should be fixed at HEAD of master. Let us know if you're still seeing issues after updating.

I'm having the same issue since I updated from week 21 to week 27, it happens on empty repositories.

In T4721#140545, @joshuaspence wrote:

In T4721#53743, @epriestley wrote:

And we should possibly consider splitting the permissions more granularly:

• View
• Show Secret
• Edit

+1

The support cost for the current behavior is very small. The behavior of the system is obvious. Users can file precise tasks like this one which clearly describe the problem (or find this task):

This behavior is intentional; it allows users to use a credential to configure other applications without actually having access to the plaintext.

Great! I think the Herald rule is also reasonable to build down the line if some future user arrives here via search and has a different use case for it in the future.