Feature #3100

user quota

Added by Nathalie Blocry almost 12 years ago. Updated over 10 years ago.

Needs more info
Nathalie Blocry
Start date:
Due date:
% Done:


Estimated time:


there is a possible problem with the user quota:
Students may be required to publish assignments, papers, ... in the dropbox by a certain deadline, but when a student has reached his repository-limit and can not create any more items, he will not be able to create and upload the document, right?
We should have a system that enables students to publish to the dropbox regardless of quota.



Updated by Sven Vanpoucke almost 12 years ago

Quota have been built for a reason and should not be dismissed for one specific use case. We should better invest time in a button to request more quota instead of avoiding quota for some use cases.


Updated by Nathalie Blocry almost 12 years ago

in our case a button to request more quota is not an option as we don't have people available 24/7 to grant those requests and students tend to upload their documents 5 minutes before the deadline.


Updated by Sven Vanpoucke almost 12 years ago

How can you make the difference when a document is created for the dropbox, or for something else when it is created in the repository instead of the dropbox. In any case, if you would allow people to use the dropbox to avoid there quota, people will abuse this logic to have more space available by submitting it to the dropbox and then use it in a different context. We could however provide some kind of stress quota request button in which a minor amount of additional quota is added (for example 10MB) to help those students out. Ofcourse this can only work when we limit this request in once a day or so...


Updated by Nathalie Blocry almost 12 years ago

allowing every user to add 10MB to their quotum once a day is not workable either and is just as vulnerable to abuse.
in the current system people can always add their documents to the dropbox.
we need something similar if we want to avoid students suing us (the institution using the platform) for failing classes because they could not turn in their assignment.

maybe some kind of "emergency" upload without the co appearing in the user's own repository. have it created in some kind of backup-admin-user's repository so they can just create and publish it in the dropbox once and not use it for anything else?


Updated by Sven Vanpoucke almost 12 years ago

Then i think we need a dropbox tool without the use of content objects.


Updated by Hans De Bisschop almost 12 years ago

Just my 2 cents:

  • Implementing an option to circumvent storage quota (there effictively no longer is a database quotum) is not a solution. It opens too many backdoors in terms of logic and "worst practices" and basically means the entire quota system (at least in the repository) is just overload and useless.
  • As much as we would like quota to be unlimited, they are not, because our storage is not. Allowing people to just upload whatever they want regardless of quotum, even if it's in just one tool, is asking for trouble. It leads to situations such as the one in 1.8 now where it becomes very difficult to get an overview of the amount of diskspace in use. E.g. group documents, student publications and dropbox are completely or partially "lawless" in terms of quotum. As a last resort one can always check the status of the actual storage, but that's hardly ideal, isn't it?
  • A user's repository is his own "property". People are expected to be responsible for their own property. If and when a user's quotum is almost used up it should be his or her responsibility to remedy that by requesting more space (in a timely fashion) and not the responsibility of the institution to provide it automatically as such.
  • Isn't this comparable to login credentials in a way? Isn't a student supposed to always know his login and or password? What happens if a student doesn't know his login ans password anymore, doesn't contact the helpdesk (or does so too late / outside business hours) and thus does not manage to upload an assignment? I don't know about other institutions, but at Erasmus that is just not a valid reason for any kind of complaint, it's even part of the student's contract. It's not up to us developers to allow people to upload anyway in case they don't have their login and password anymore.
  • Empowering the users with the ability to manage their own content (= a repository) comes with some responsibilities. These kinds of things should be taken into account on a management-level when introducing Chamilo 2 (or any kind of content based repository) into an institution. Especially when some things (like assignments) are time-sensitive.
  • On a technical level I do think the storage quotum should be more visible AND we should inform people(via mail, in-platform, ...) when things are getting alarming. If and when such notifications are sent out could / should be configurable. The "when" could be percentage or MB-based. Plenty of options. At the same time it might be a good idea to also include a visual, and unobtrusive, warning whenever that alarm level has been reached and possibly platform-wide.
Conclusion (IMO):
  • A user is responsible for his quotum in the same way he is responsible for his credentials
  • The platform is responsible to notify the user when things are getting alarming.

I know item nr. 1 requires some mentality and "official" changes, but I really do think it's the best way to go. Feedback is of course appreciated.


Updated by Nathalie Blocry almost 12 years ago

I agree that messing with the repository quota and programming exceptions to the system is not a good idea.

I do like the idea with the "soft" and "hard" limits, where you get informed and warned (constantly) once you have crossed the soft limit (like 90% of the actual hard quotum) but for us it just isn't enough. e.g: when a user has a 100MB quotum and has spent 85% of that he will not have crossed the soft limit and will not be aware of any problem (yes, in an ideal world users should take responsibility for their own repository but reality is that they just don't do that). Now he has a 20MB paper he has to upload, which he will not be able to do because that will cross the hard limit. Most users are not aware of how big files are and whether 20MB is a lot or not. The user will now have to start unpublish and remove other things from his repository to be able to hand in his paper.

This brings us to the second problem with the current dropbox. Students are still the owners of the items published to the dropbox. they can unpublish and delete them, change them after the publish/due-date, ...
When people hand in papers, assignements, ... in the "real" world the "ownership" passes from the student to the teacher. once a paper is handed in the teacher has full control over what happens to him. On the platform the paper stays under the student's control and the teacher is granted temporally rights to view it.
We think this requires a mentality-shift with our users that just will not happen overnight. We forsee too much problems with this system, so I do think the only solution for us is indeed to create a dropbox tool that doesn't use content-objects and the repository but is similar to the dropbox in our current system (including all the problems, we are fully aware of that).


Updated by Hans De Bisschop almost 12 years ago

Actually, the unpublishing and deleting is rather easily fixable. If people want to edit the content object linked to the publication they are free to do so, it does get registered in the system. The dropbox (or whatever you call it) could automatically compare dates and highlight iffy publications. So, while technically possible, all the user ends up doing, is expose the fraud he tried to commit. I remember discussing something similar with Eduard related to surveys ... and we even worked out some kind of (partial?) solution for that. It's somewhere in my notes over at Erasmus, I'll look it up on monday.

I agree mentality shifts don't happen overnight, which is probably one of the reasons student contracts and educational regulations have grown considerably in length. I still believe we can find some kind of solution to this problem though that actually works for everyone and in most (all = utopia) cases.

Limits go part of the way, but I'm not sure (yet) about the other part.


Updated by Sven Vanpoucke almost 12 years ago

It's quite simple, what nathalie means is actually the description of an assignment tool, not the dropbox tool. But as we all know in dokeos the dropbox tool was abused for this in the past. With the assignment tool that one of our internships is creating, the ownership of a document is handed over to the teacher. We could however discuss how we could solve the issue of the limit.


Updated by Nathalie Blocry almost 12 years ago

You are probably right Sven. the name of the tool is not that important, I just keep calling it "dropbox" because that's what our users currently use.
Having a separate assignment tool is probably a much better idea.

but just having the content object created in the teacher's repository is actually worse since they also have a limit and a student not being able to hand in an assignment because the teacher's repository was full is even a bigger legal nightmare.
so the same "problem" exists there and we are full circle back at the beginning: the user quota being a problem sometimes.


Updated by Stefaan Vanbillemont almost 12 years ago

  • Project changed from Chamilo LCMS Connect to Repository
  • Category deleted (4)

Updated by Stefaan Vanbillemont almost 12 years ago

  • Target version set to 2.1.0

Updated by Stefaan Vanbillemont over 11 years ago

  • Target version changed from 2.1.0 to 55

Updated by Stefaan Vanbillemont over 11 years ago

  • Target version changed from 55 to Backlog (default)

Updated by Stefaan Vanbillemont over 10 years ago

  • Status changed from New to Needs more info
  • Assignee set to Nathalie Blocry
  • Target version changed from Backlog (default) to LCMS 3


Is your question still valid with the new quota manager?

Kind Regards,



Updated by Stefaan Vanbillemont over 10 years ago

  • Target version changed from LCMS 3 to Backlog (default)

Also available in: Atom PDF