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.

Copying in some context from elsewhere:

I think nowadays the biggest issue (as it is the most work to manually correct afterwards) is two folks editing a task description at the same time and silently overwriting.

Oh, thanks. I can reproduce this variant of things. I thought I remembered seeing this...

There is no trickery involved in our repository edit field, it might as well be a datasource field.

See also T5118.

I think T10116 may have fixed the "actions ignored" issue -- does it still reproduce for you after that?

Right. This was a feature request to have "ctrl+enter" (or cmd enter on osx) to work in all fields (in addition to enter in the fields where it makes sense), so that there's 1 key that always works to submit the current form.

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

In T10004#151960, @joshuaspence wrote:

OK, I managed to reproduce it on this install, see T10083. Specifically see T10083#151963 in which I attempted to close the task as resolved.

OK, I managed to reproduce it on this install, see T10083. Specifically see T10083#151963 in which I attempted to close the task as resolved.

Actually, I am seeing still seeing this issue on our install on tasks which aren't affected by any Herald rule (that I know of).