Adrian-Stefan Mares

> I'm not so sure as to why there is the necessity of making the user and organization public before sending the notification email, but if so, this is something...

> IS doesn't allow for organizations to be nested, tried it real quick just to be sure and the following error occurs: > ` "message": "error:pkg/identityserver:nested_organizations (organizations can not be...

> This is only valid if the IDs applied to the field are from the `Collaborators` within the entity, if fetched from a general list then the introduction of cycles...

> 1. How do stack components retrieve the actual contact information ? > As mentioned above, this can be solved via extra RPCs - you give it `EntityIdentifiers` and it...

> And I would say that if a user decides to set themselves as admin/tech contact, other collaborators with read access can see that. The challenge is that a user...

> I'm wondering if this is a bit of overkill or not, because the scenario to make this a valid option has to assume that the admin has bad intentions...

> Use privacy settings (public, other collaborators, private) - to be created More specifically, for the collaborator entity, which currently only tracks the rights. > Console front-end flows regarding adding/removing...

> You mean "as admin/tech contacts" (where emphasized)? Yes. > Can we circumvent collaborator privacy flags by only allowing to set yourself as admin/tech contact, or let an admin do...

> Or make this IS configuration? Indeed, that's what I meant.

> Besides this I should write it in here what else shouldn't be NULL in the database. Could you take a look for this ? I can then check the...