unable to set 0 bytes quota on an user via provisioning api

[michag86]

It's not set the quota of an user to 0 bytes.
0 oder 0B or 0MB are always converted to 0. This is reserved as "default".

We would like to assigne 0 bytes for read-only users.

Tested on ownCloud 8.1.1, but I think there are no changes in 8.1.3.

[PVince81]

@tomneedham @MTRichards @karlitschek might need API design change.

[nickvergessen]

Yeah, default should be -2 (-1 is none, so negative numbers are already used for special cases),
but it's used since 2014:
dc85c20#diff-d63ef796ade5860b68adcc00dc5639a6R163

[PVince81]

This will require a change of API... version 2 ? 😦 @DeepDiver1975

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[DeepDiver1975]

Turns out that when submitting 0 or 0MB via the provisioning api it will be used as 0 bytes. The quota will be set to 0. As far as I can tell this behavior exists since at least this change 15d1341

I propose to add magic values named default and none instead of any number magic.

@PVince81 objections?

[DeepDiver1975]

looks like it was working this way (as described in the ticket) back in oc8 - dc85c20#diff-d63ef796ade5860b68adcc00dc5639a6R163

[PVince81]

I'm fine to go with the "default" and "none" strings

[PVince81]

or instead of "none" make that "unlimited"

[DeepDiver1975]

actually 'none' should be used when no quota is to be set - so 0 and 'none' are synonyms ...

[DeepDiver1975]

or instead of "none" make that "unlimited"

none is in the code base for the very first day... let's stick to it

[PVince81]

fixed through #30755 (review)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.