user and group expiration dates do influence each-other

[kiranparajuli589]

Steps to reproduce

1. Enable shareapi_enforce_expire_date_group_share and shareapi_enforce_expire_date_user_share

sudo -u www-data ./occ config:app:set core shareapi_enforce_expire_date_user_share --value=true
sudo -u www-data ./occ config:app:set core shareapi_enforce_expire_date_group_share --value=true

2. Set different default expiration for user and groups

• shareapi_expire_after_n_days_group_share to say 10
• shareapi_expire_after_n_days_user_share to say 20

3. Create a user user0 and a group grp1, add the user to the group
4. Now try to create a collaborator share

Expected behaviour

Sharing using collaborator user0 should provide expiration days options 20 days beyond current day

Actual behaviour

Sharing using collaborator user0, expiration days options for only 10 days beyond current day

Note

• Sharing using group as collaborators works fine (expiry dates are enabled/disabled as per settings)
• Sharing using user as collaborators works fine (expiry dates are enabled/disabled as per settings) when editing the created share

Server configuration

latest phoenix master
latest core master

[lookacat]

We found while working on #5806 that the CollaboratorsEditOptions on both the New and EditShare component. On the new component initially the shareTypes are empty so its always taking the smaller value because it doesn't check the shareTypes that are present once edits are made.
To prevent this we need to watch which share types are present and find the smaller maxExpirationDate to prevent this bug.
Also we need to add integration tests for this case.

[kulmann]

Has been fixed in 926bc0b#diff-5ad2af1f8df798d6259a745bdf05f36c38e58167266762e91092319177ed793aR90