Is the commit ID exactly the same each time, or does it change?

Here's approximately where I'm headed with this:

No problem, thanks for the followup!

Per T1460:

thank you for your compliance

Oh, no, it's 268 and 286. No guac!

Wow, exactly 1,000 apart.

T10268 is also vaguely related.

Presuming this is resolved now, let us know if you're still seeing issues.

My tentative plan for this is a separate view where all inlines are shown in threads, sorted by done-ness and activity.

I'm not particularly sold on putting context in the timeline, particularly because I think we've received about as much feedback about Differential having "too much stuff" as we have about this context being desirable.

I'm going to close this in favor of more specific followup subtasks:

I don't plan to pursue this outside of the context of T1460, T8250, etc. If we did, it would be in the far future and after those changes land.

Upshot: I think renderValue($string) on ModularTransactionType is totally reasonable. We can fiddle with how it looks later.

I intend to remove them from feed, but it might have just been on a diff somewhere and not made it to a task.

I think it's generally reasonable to show values with style instead of quotes in the web UI, although maybe a style other than bold would be best.

There is no way to unsubscribe from them.

We haven't gotten to this in two years and haven't really seen other interest. We already support ~8 providers.

Some additional work (the "Stack" tab) ended up overlapping with T4788 but I think this is resolved.

Workaround is to edit this URI:

Okay, but the docs don't actually describe or refer to an import button anywhere -- there's no text like "click the import button" that I missed when updating things?

so the UI should still look good given that edge-case.

Resolved by D16246, I suppose.

Oh, now that we gave posts the J monogram, we should probably also find a way to put that on the blog page somewhere (at least the internal one, and maybe the ApplicationSearch results page). Right now you have to know that you can fish the ID out of the URI. Let me see if I can poke at that a bit with my doc stuff.

Just the T6299 stuff, I think.

I'm leaning toward making it a "Relationships" box with "Task Graph", "Mocks" (with a thumbnail/gallery view instead of just titles), and "Commits/Revisions" (probably with a little more status information than we currently show).

Another issue is that when following the user docs, the docs still points towards having the import button on the creation of project.

I'm leaning toward just adding a big "Clippy" element to this UI:

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.

Here's what I see -- step 1:

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.

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.

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:

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.

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 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.

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.

Two-way.

There are several classes of transaction like this. One is that all actions are restricted:

(And thanks for providing access to an environment where the issue reproduces!)

@Mnkras, I think I've undone everything I did and terminated all sessions on the host. You can revoke my key at your convenience.

I can't reproduce this. Here's what I did: