Plus, making the file editable by the author is the cure of T15814, so, moving that as parent task.

If we allow authors to destroy their images, we should also avoid 404 errors on them. So, the new subtask T16074.

In T15948#21505, @Cigaryno wrote:

In T15948#21503, @Cigaryno wrote:

There must be a function that allows Conduit methods to be used by logged-out users. It's just that there are hardly any methods using that function.

There must be a function that allows Conduit methods to be used by logged-out users. It's just that there are hardly any methods using that function.

Thanks. I see, from this page is not possible:

Also, I'm OK with the change also because of GDPR's principle of minimization. I mean, Phorge avoids to collect unnecessary data, and this is nice.

As a side note, it's possible that somebody in the world was using the Phone number feature in a way that was then integrated with their custom management system, accessing this information via plain SQL.

Also, this mashes up Diffusion and Repositories to add confusion

I don't get the code.
src/applications/diffusion/controller/DiffusionIdentityViewController.php (note the View in its name) includes stuff like
$edit_uri = $this->getApplicationURI("identity/edit/{$id}/") defining ->setName(pht('Edit Identity')) (note the Edit here).
Also, this mashes up Diffusion and Repositories to add confusion (DiffusionIdentityEditController calls PhabricatorRepositoryIdentityEditEngine?).
I think I give up.

It's important to restrict the ability to create Diffusion IDs.

Patch in P13 is incomplete, policy does not cover going to /diffusion/identity/edit/1/ and setting Assigned To to another user but should.

In T15443#9918, @avivey wrote:

It also might make sense to hide the actual list from the general public (it's a mapping of emails to users).

The "Create Identity" button on /diffusion/identity/ should be guarded by this new policy access, though currently that form is not functional - see T15453

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"

Would it make sense to put creating identities behind the existing Edit policy of the repository?

Would it make sense to put creating identities behind the existing Edit policy of the repository?

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)

As an approach this seems good to me. Would it make sense to put creating identities behind the existing Edit policy of the repository?

Cannot properly test locally (too many exceptions on PHP8.2 trying to create a local Git repo and commits to be indexed in Diffusion) how much this change would actually affect both editing and creating (or not) so I dumped an untested patch into P13

I wonder if this is related to not being able to use the Diffusion repository file auto-complete when not logged in even though the repo is publicly accessible.

Hi @Cigaryno thanks for this bug report. Please attach more details than feel free to reopen