[Core] Group functions revisited

[Frans]

Placeholder issue to discus group functions.

- group quota
- media management between group members

[MC-arjen]

Let me first give a translated version of the orignal user story 'Quota' as is implemented at the moment:

User story Quota:
-----------------

Quota in MediaMosa is enforced for Applications, groups and users. The
quota's are maintainable in the admin interface.

Quota is enforced through an and-and model; all quota rules must be
complied to, otherwise the mediafile is not allowed to be uploaded (or
otherwise created). A quota of 0 is equal to unlimited quota.

A group

The diskspace used of a user is the total diskspace of all mediafiles
of that user.

The diskspace used of a group is the total diskspace of all mediafiles
which have that group_id. This is something else than the sum of all
mediafiles of the users who are member of that group (!). The group
quota can be used as an extra upload restriction.

We have application, group and user quota. Quota is settable, can be
used, and reported. Here is where:

|--------+----------+-----------------+-----------------|
| quota  | APP      | group           | user            |
|--------+----------+-----------------+-----------------|
| set    | MM-ADMIN | REST            | REST            |
| usage  | MM-ADMIN | APP             | APP             |
| report | MM-ADMIN | REST + MM-ADMIN | REST + MM-ADMIN |
|--------+----------+-----------------+-----------------|

Application quota is only settable, used and reported in the MediaMosa
admin interface, group and user quota is more application related, but
can be reported in the admin interface.

Quota is implemented with a 'soft-quota' restriction; the last action
that exceed the quota is still allowed. At the moment an
application/user/group is over quota, no further upload/transcode is
allowed.

In the early days of MediaMosa it was argumented that, being the backend that MediaMosa is, it should have not too many knowledge of users/groups. Only the basic information needed to solve the quota user story was needed. Therefore MediaMosa ended with a group-user being a 1:n relation.

Now in relation to the requests:

- "a user is in 0,1 or more groups."

This is a change. Mediafiles still have 1 owner/groupowner, so a file only counts towards 1 group regarding quota, regardless of in how many groups a user is.

- "Een asset heeft zowel een eigenaar (persoon) als een eigenaar (groep);"

already true in MediaMosa.

- "Een groep heeft een diskquotum, groepsassets komen ten laste van dat diskquotum;"

True in MediaMosa.

- "Groepsleden kunnen (afhankelijk van permissies die in SURFteams worden bijgehouden) bewerkingen uitvoeren op groepsassets waarvan ze geen eigenaar zijn."

Not True at the moment in MediaMosa. Only owners of a file can perform actions.

- "Collecties kunnen net zoals assets ook een groepseigenaar krijgen;" True

- "Groepsleden kunnen (afhankelijk van permissies die in SURFteams worden bijgehouden) collecties en hun assets bewerken (assets toevoegen / verwijderen / collectienamen)."

Only owners of a object can perform actions.

- "Bij het aanmaken van een asset moet aangegeven kunnen worden dat een asset niet alleen een owner_id heeft, maar ook bij een groep hoort. Dit lijkt reeds gerealiseerd door de /asset/create [post] call met parameters ‘user_id’ en ‘group_id’"

True.

-"Er moeten groepen aangemaakt kunnen worden, en bij een groep moet een quotum gezet kunnen worden. Dit lijkt reeds gerealiseerd door de /group/create [post] call met parameters ‘group_id’ en‘quotum’"

True.

- "Bij mutaties van mediafiles aan assets (uploaden, transcoden, delete) moet het ‘groepsquotum’ gechecked / geupdate worden als er een ‘group_id’ bij het asset gezet is of wordt. Hier kan natuurlijk een ‘out of quotum’ foutmelding komen (vergelijkbaar met
huidige user_over_quotum)."

True, only "groupsassets" in Surfmedia have a different meaning now...

-" Als het ‘group_id’ van een asset bewerkt wordt, dan verwachten we het volgende voor watbetreft de disk_usage:"

It works different now in MediaMosa...

[Frans]

Needs discussion (face-2-face).

[Michiel.Schok]

SURFmedia will implement it's own group-owner-logic as of SURFmedia 2.5.
Therefore, this requirement is no longer on its wish list.

It can be closed, or someone other can define requirements for their EGA.

For what it's worth: SURFmedia will assign an owner_id of 'TEAMS.<team identifier> to assets that belong to a team, and we will do the logic ourselves.

[Frans]

Won't have this one for SURFmedia

[Frans]

Promoted to should due to community requests.

[robert]

1. If group is not provided, then don't group quota, only user quota (like it is now).
2. If group is provided, check quota, make sure user is in group. The check if user is in group is currently not working(!).
3. Check quota first of user, then of optional given group.

@dennis;
So in short. You do not try to figure out the quota. The client app will provide the group for quota check, like it is now. Do not assume any group_id for quota check. This solution is very easy, as far as I see nothing changes (might need to change some queries to match your new link table usage).

The only thing left to do is the check if the user is in the group. You will need to find out where group_id is provided and make sure the user is in the group.

Also check all user and user_group REST calls. Look at /user/$user_id POST where group_id is still stored in the user table(!). So check each REST call for /user/* and /group/* if your new link table does not break stuff. Also check class mediamosa_user.

[robert]

Code released in 3.0.0.

[forgacs]

You can test this issue with /user/* and /group/* REST calls.