Allow committee admin personal info edit

[luisa-beerboom]

Closes #3702
Closes #3806

Needs OpenSlides/openslides-backend#2487

[Elblinator]

Meeting-admins:
If participant Ann is an admin in meeting A and B and participant Ben is a participant in only these two meetings then Ann should be able to change the personal information from Ben, but the personal information fields are currently disabled in this scenario.
If Ben is only in one of these meetings then Ann can change the personal information currently

Committee admin:
A committee admin can change the initial password but cannot see the password, the committee-admin should be able to change the password. The committee admin should also be able to see the password (tthis is an autoupdate-service issue see -> OpenSlides/openslides-autoupdate-service#965) (edited 12.07.24)

If the user edit page is open and the page is reloaded then the following Error is thrown in the console

ERROR TypeError: Cannot read properties of null (reading 'enable')
    at user-detail-view.component.ts:283:73

[Elblinator]

For a committee-admin>
Please change the visible options in the three dot menu:
Please remove-hide the merge accounts -option

[luisa-beerboom]

Meeting-admins:
If participant Ann is an admin in meeting A and B and participant Ben is a participant in only these two meetings then Ann should be able to change the personal information from Ben, but the personal information fields are currently disabled in this scenario.
If Ben is only in one of these meetings then Ann can change the personal information currently

That is indeed an inconsistency, however it was not part of the issue. If you want this changed, we'll have to discuss it with the appropriate people and define the requirements for both the backend and the client.
Regardless, I would suggest doing that separately after this issue is merged

[Elblinator]

Meeting-admins:
If participant Ann is an admin in meeting A and B and participant Ben is a participant in only these two meetings then Ann should be able to change the personal information from Ben, but the personal information fields are currently disabled in this scenario.
If Ben is only in one of these meetings then Ann can change the personal information currently

That is indeed an inconsistency, however it was not part of the issue. If you want this changed, we'll have to discuss it with the appropriate people and define the requirements for both the backend and the client. Regardless, I would suggest doing that separately after this issue is merged

that is part of the bug issue #3806
see nr 2 of wanted behaviour:

write permission: A meeting admin has write permission for personal information if they are an admin in ALL meetings in which a user is also a participant

[luisa-beerboom]

Meeting-admins:
If participant Ann is an admin in meeting A and B and participant Ben is a participant in only these two meetings then Ann should be able to change the personal information from Ben, but the personal information fields are currently disabled in this scenario.
If Ben is only in one of these meetings then Ann can change the personal information currently

That is indeed an inconsistency, however it was not part of the issue. If you want this changed, we'll have to discuss it with the appropriate people and define the requirements for both the backend and the client. Regardless, I would suggest doing that separately after this issue is merged

that is part of the bug issue #3806 see nr 2 of wanted behaviour:

write permission: A meeting admin has write permission for personal information if they are an admin in ALL meetings in which a user is also a participant

That has never been a requirement before. It is therefore a feature request.

[Elblinator]

I tested with the client and backend and it works fine

If the code is alright, then the prs can be merge imo.
-> I think these PRs can be merged without the autoupdate-service issue, but that issue should still be implemented soon