<bikeshedding>

+    return pht('Can Create and Edit Identities');

Shouldn't Create and Edit be lowercase?
</bikeshedding>

It also might make sense to hide the actual list from the general public

I agree. Wouldn't it make sense to put it behind repository.identity.view?

It turns out that this is a duplicate:
T15443: Add Diffusion policy capability "Can Edit and View Identities"

No, your edit is not correct. The same happens in search, as I indicated in the description:

or craft a query for Diffusion commits, specifying X as author

So if after following my instructions you go to /diffusion/commit/query/all/, you see all of the commits with the author field correctly displayed. If, however, you proceed to editing a query and you select user X as author, you get the "old state".

I ran repository rebuild-identities --all-repositories --all-identities, but it didn't change anything.

But, they identities probably should be editable only for:

• people who can edit the repository (people who administer it)
• you, if the email matches yours (since you somehow pushed in the repository)

Done.

Ah, sorry. I'll create the ticket in a minute.

Just trying to convince you.
If the feature works, it adds functionality that can't be easily replicated. You can have a bunch of complex Herald rules and bypass them all just by declaring that ^temp/ refs are now non-permanent. If the feature doesn't work (or maybe doesn't exist, rather), you have to go to each Herald rule and explicitly exclude ^temp/ branches, which is a lot of work for something that (at least for me) looks like it should be simple.

Here, I assigned one of your identities to myself:

This is about Diffusion identity assignment feature. List of identities is here: https://we.phorge.it/diffusion/identity/
The simplest way to test it would be to make a test repository and proceed according to the instructions as above. I hope the process is laid out quite clearly.

Usually it's a fair point, but this is Herald, which is one big custom settings panel, essentially. But maybe enabling it by default shouldn't be too bad — I don't imagine that workflows that include pushing a lot of unknown commits to non-published branch and then changing a published ref to include those would be very common.

…only if that new ref contains commits which were not visible to Herald before, which shouldn't be too common. Also the Herald commit rule could have an option to enable or disable that behavior.

Technically, I think a commit may be pushed without being in any ref?

Thanks a lot!

You can do it using HTML tags and literal line breaks, like this:

But you probably already know that, given that the task you quoted was closed by committing this revision.
(<br> doesn't work here, but I think it should, even if it's ignored in plain Remarkup.)