Uh oh!
There was an error while loading. Please reload this page.
Check expiry enforcement for all share types - #40933
Conversation
bbc12c4 to
8ef3748Compare8ef3748 to
3f51b16Compare
come-nc
left a comment
There was a problem hiding this comment.
Enforcing now works for all three kind of shares.
But default seems broken for remote share it’s not applied?
nfebe
commented
Oct 16, 2023
2eda6db to
5840ca5Comparecome-nc
commented
Oct 19, 2023
Hum, forced default expiration date now works for all cases, but for default value it uses the normal share default value for all 3 cases, even email and remote share, which should use their own default. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
1fd800a to
420c0d9Comparecome-nc
commented
Oct 20, 2023
I had to run «npm run build» to fix the admin UI, so something is fishy in the commited dist. You will have to rebase on master and rebuild anyway. Also, there is a problem:
Please test thoroughly requesting for review again. |
come-nc
left a comment
There was a problem hiding this comment.
Enforcing is not working correctly (enforcing email enforces for local share, did not test other combinations)
Sorry @come-nc it appears, a merge conflict resolution overwrote some of the updates, during a rebase. |
About the It is now clear that this variable was poorly named. If we have |
420c0d9 to
e07d8e8Comparee07d8e8 to
d6ff703Compared6ff703 to
4548fdbCompare4548fdb to
a212ea9Comparenfebe
commented
Oct 22, 2023
/compile amend / |
We should check that a maximum expiry date has been enforced for all shares and NOT JUST FOR internal shares before enforcing a UI max date, like in commit 9757e68 Signed-off-by: fenn-cs <fenn25.fn@gmail.com>
Current expiration date errorneously assumes that `defaultExpirationDate` applies to all kinds of shares. But it only really applies to public shares despite its name. This commit, fixes that by paring expiration dates with the correct share types during new share initialization and simplifying the `hasExpirationDate` (check) property. Signed-off-by: fenn-cs <fenn25.fn@gmail.com>
a212ea9 to
2ca8561Comparenfebe
commented
Oct 22, 2023
/compile amend / |
2ca8561 to
eb0c923Compareeb0c923 to
2ca8561Comparenfebe
commented
Oct 22, 2023
/compile amend / |
`isDefaultExpireDateEnforced` and its corresponding `defaultExpirationDate` is currently treated as the enforcement fallback when share type enforcements are not set. However, `isDefaultExpireDateEnforced` and `defaultExpirationDate` are actually more like `isDefaultPublicExpireDateEnforced` and `defaultPublicExpirationDate` and therefore only applies to public shares. It might be ideal to rename this variables all the way from the backend config to the way we use them in the frontend code. Signed-off-by: fenn-cs <fenn25.fn@gmail.com> Signed-off-by: nextcloud-command <nextcloud-command@users.noreply.github.com>
2ca8561 to
8dfcf2eComparemarcelklehr
commented
Dec 13, 2023
Can we please backport this to stable27? |
susnux
commented
Dec 13, 2023
Looks like this is already on stable27? At least when I cherry pick it is empty. cc @fenn-cs |
nfebe
commented
Dec 13, 2023
marcelklehr
commented
Dec 13, 2023
@marcelklehr it has commits from both pr's. |
We should check that a maximum expiry date has been enforced for all shares and NOT JUST FOR internal shares before enforcing a UI max date, like in commit 9757e68
Resolves : no issue