add new user type space owner

[butonic]

When accessing public shares in a project space (which has no owner, only managers) we need to be able to pass a userid through the system which permission checks can work with.

Another use case is when trying to index a space on behalf of the space owner.

In both cases the user id MUST be set to the space id to reflect which space is supposed to be indexed.

Signed-off-by: Jörn Friedrich Dreyer jfd@butonic.de

[micbar]

We are currently using USER_INVALID, why do we need an additional type?

[butonic]

@micbar you added it in https://github.com/cs3org/reva/blob/8f35682de6b785c96c215d6af5dea9508cfe3a9a/pkg/auth/manager/publicshares/publicshares.go#L132 and https://github.com/cs3org/reva/blob/8f35682de6b785c96c215d6af5dea9508cfe3a9a/pkg/storage/utils/decomposedfs/grants.go#L69

for non personal spaces in https://github.com/cs3org/reva/pull/3029 it seems

[labkode]

Hi guys, a space owner looks like an internal type of user. Let's take CERNBox as example, a space owner can be any of these:

USER_TYPE_PRIMARY = 1;
  // A secondary user for cases with multiple identities.
  USER_TYPE_SECONDARY = 2;
  // A user catering to specific services.
USER_TYPE_SERVICE = 3;

and maybe in the future other types will be guest or federated.

To have an internal type of user, the USER_TYPE_APPLICATION = 4; was created for that.

[micbar]

Not really. A space owner is not a real user on reva edge. It has no account in the IDP and will never be able to log in. Therefore it is important to have a dedicated user type. I was also happy with USER_INVALID but that makes it clearer.

[glpatcern]

Yet it is given privileges to do actions. I reckon that the USER_TYPE_APPLICATION would be a good fit here

[glpatcern]

@micbar @butonic do you use USER_TYPE_APPLICATION anywhere else, and would you need to make a distinction with this specific case? If not, for the sake of keeping the API clean I'd be in favour of using USER_TYPE_APPLICATION and reverting this change.