feat(frontend): various improvements around invitations

[usu]

Various improvements from this epic: #1238

More specifically:

• Bei Einladung "Login" -> redirect zurück zu Einladung (OK) ; Daten werden aber nicht neu geladen -> Einladung wird nicht korrekt angezeigt
• store module to have a reactive user property to check if a user is logged in (and if so which one)
• --> this allowed to remove NavigationAuth and replace by NavigationDefault. Didn't verify/fix the mobile view, as this would interfere a lot with Make new navigation prototype #2576
• fix error when resending an invitation to a CampCollaboration, where invitee is an existing user and not just an unknown email address

Open questions

Invitation endpoint, property userDisplayName

Should be: "The display name of the user that is invited. May be null in case the user does not already have an account."
By mistake: returns DisplayName of the currently authenticated user
This was used in Invitation.vue to display the currently logged in user.
Do we need/want this property at all or shall we remove from the endpoint?

Decision: Can be removed

Invitation endpoint, property userAlreadyInCamp

Indicates whether the logged in user is already collaborating in the camp, and can therefore not accept the invitation.
This is also true if a CampCollaboration exists but is set to inactive.
User receives a message "You are already participating in this camp" with an "Open camp" link. Open the camp doesn't work though, because the user is inactive.
What should be the intended user experience? We could provide a message like "You're set to inactive. Ask a camp manager to set your status to active" or similar. However, this is a bit odd because the user apparently has a valid inviteKey and could theoretically accept the invitation as another user, but not with this one.

Decision:

• Invitations on existing users belong to this user --> cannot be taken over
• Invitations on email addresses --> on accepting with an inactive user, the responsibility is merged with the existing one

[BacLuc]

Thank you.

[BacLuc]

This was here on purpose to welcome the user by his name (if logged in).
Before this was the possibility used to check if the user was logged in or not.

Also from the background that the recipient of an invitation may use another account to accept the invitation.

Now you see your name in the navigation, so we can remove userDisplayName if we want to use this way.

[BacLuc]

I would remove the
here.

[BacLuc]

minor:
i would use a multi line comment for multi line texts.
This makes copy/paste easier.

[BacLuc]

Invitation endpoint, property userAlreadyInCamp

Indicates whether the logged in user is already collaborating in the camp, and can therefore not accept the invitation.
This is also true if a CampCollaboration exists but is set to inactive.
User receives a message "You are already participating in this camp" with an "Open camp" link. Open the camp doesn't work >though, because the user is inactive.
What should be the intended user experience? We could provide a message like "You're set to inactive. Ask a camp manager to >set your status to active" or similar. However, this is a bit odd because the user apparently has a valid inviteKey and could >theoretically accept the invitation as another user, but not with this one.

This happens if you set the user to inactive after inviting the user?

I would say the invite link of an inactive user should not exist anymore.
-> if we set the user to inactive, we remove the inviteKeyHash.

Another way would be to check the status, but then we still have the inconsistent state in the db.

[usu]

This happens if you set the user to inactive after inviting the user?

No not exactly. I tested the following use case:

1. I have a valid user account on ecamp ([email protected])
2. I was member of a camp X, but then someone deactivates my collaboration in the camp (status inactive)
3. I recognize that I don't have access to to the camp anymore, so I ask someone to send me an invitation
4. Someone sends me an invitation to [email protected] (non-existing user in ecamp), instead of reactivating my existing collaboration
5. I grab the invitation link & login with my existing user ([email protected])
6. eCamp tells me, that I'm already part of the camp (userAlreadyInCamp: true). I cannot accept the invitation, but I can also not open the camp.