Apply heuristics when updating the quota of existing users

Bug #796029 reported by Dominique-Alain JAN
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mahara
Triaged
Wishlist
Unassigned

Bug Description

Following François' request, I ask my question and give a proposal about quota here.

In the master branch you add new quota policy for groups and institutions. The help text says that the new quota enter here will affect only new group's member or new institution's member; previous group/institution's member will see their quota remained the same as before.

This is pretty good if the previous quota is higher than the new policy but what happens if the quota decided by the group ou institution admin is higher ?

Normaly Mahara should then update the quota to the higher number.

If it is not the way Mahara behaves it should. If it is already the case, the help section has to be updated to explain that if previous quota for already enrolled users will remain the same or upgraded if the new setting is higher than before.

Regards,
-dajan

Tags: quota
Revision history for this message
François Marier (fmarier) wrote :

Subscribing Kristina who might have an opinion as to what the right thing to do is...

Changed in mahara:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Hugh Davenport (hugh-davenport) wrote :

Hi dajan,

I was the developer that implemented this feature.

The old user/group quota is left exactly the same even if the new quota
is higher/lower. This I believe is the case when you set a new default
quota for users (the only default quota you could set before).

The reason for this is that you may set a user/group quota to something
that is not the default, so they are then a special case. It is
difficult to then change the quota and decide which of the old
user/groups should get changed to the new quota, as you may not want to
change all of them.

As I said before, I believe this to be the original functionality of the
old quota system, which I have tried to keep the new system quite close to.

Any other questions, let me know.

Cheers,

Hugh

 assignee hugh-catalyst

On 12/06/11 08:01, Dominique-Alain JAN wrote:
> Public bug reported:
>
> Following François' request, I ask my question and give a proposal about
> quota here.
>
> In the master branch you add new quota policy for groups and
> institutions. The help text says that the new quota enter here will
> affect only new group's member or new institution's member; previous
> group/institution's member will see their quota remained the same as
> before.
>
> This is pretty good if the previous quota is higher than the new policy
> but what happens if the quota decided by the group ou institution admin
> is higher ?
>
> Normaly Mahara should then update the quota to the higher number.
>
> If it is not the way Mahara behaves it should. If it is already the
> case, the help section has to be updated to explain that if previous
> quota for already enrolled users will remain the same or upgraded if the
> new setting is higher than before.
>
> Regards,
> -dajan
>
> ** Affects: mahara
> Importance: Undecided
> Status: New
>

Changed in mahara:
assignee: nobody → Hugh Davenport (hugh-catalyst)
Revision history for this message
Kristina Hoeppner (kris-hoeppner) wrote :

Hello dajan,

Hugh and I had talked about your suggestion earlier. He already posted his response. Updating existing quota is tricky as there is currently no way to see in a big list which quotas are allocated to users (unless you have database access). Therefore, updating the existing quotas across the board may not be beneficial, if e.g. 50 users have 1 GB and now have 2 GB, but 10 people already have 10 GB of space. The latter would be reduced to 2 GB.

One possibility could be to provide the admin with a checkbox "Do you want to update existing quotas? Please be aware that all quotas set for individuals (higher and lower than the new quota) will be overwritten."

Most likely, 90%+ this will be fine as institutions probably give the same quota to everybody, but we should alert the admin to the possibility that there may be other quotas as well. As these are the default quotas, a site admin (or institution admin if allowed) can still manually update individuals.

Cheers
Kristina

Revision history for this message
Iñaki Arenaza (iarenaza) wrote :

Hi Kristina,

you could use some heuristics to help with the changes: e.g you only change the quota for those users/groups whose current quota equals the old institution quota.

In case the current quota is not the same as the old quota, you could keep the higher of the current user quota and the new institution quota (if the current user quota was higher than the old institution quota), or the lower of the current user quota and new institution quota (if the current user quota was lower than the old institution quota).

The rationale is that people with quotas higher that institution quota should get an "enhanced service" always, and people with lower quotas than institution quotas should get a "reduced service" always.

Saludos.
Iñaki.

Revision history for this message
Kristina Hoeppner (kris-hoeppner) wrote :

Hello Iñaki,

Thank you for this suggestion. That sounds good. Hugh: That would be something for further improvement.

Cheers
Kristina

Changed in mahara:
importance: Medium → Wishlist
assignee: Hugh Davenport (hugh-catalyst) → nobody
tags: added: quota
summary: - New quota limit policy
+ Updating the quota of existing users
Revision history for this message
Kristina Hoeppner (kris-hoeppner) wrote :

I changed the feature wish title to reflect what could be done. It is possible to update the file quota for existing users and groups. But that is currently an all or nothing no matter what quotas have been set individually. Thus, if the system should be more discerning, Iñaki's suggestion from #4 could be a start.

summary: - Updating the quota of existing users
+ Apply heuristics when updating the quota of existing users
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.