I'd like to gather some opinions on that.
At the moment an user has several ways to pick and avatar:
from the gallery
from an url
uploading it
gravatar
Each of these (or most of these) have a permission: allow upload, allow pick from gallery, allow... etc.
From my support experience I have seen these permissions only misused in order not to allow a member to select.
I'm not sure why these are permissions to begin with, though I think something different may give a better user experience, and here it is the description of my idea.
Only one permission: "allow to select an avatar", then in the avatar section, an area where the admin can enable or disable different ways to pick an avatar.
Rationale: it's rather unusual that a group is allowed to select an avatar from the gallery, but not from an url. The usual need (AFAIU) is to decide what is the "allowed" method to select an avatar because, for example, there is the need to limit the space occupied on the host (even though nowadays it's rather difficult the avatar can be a space problem) for example disabling the "upload avatar" function. Or maybe the owner of the forum doesn't want gravatars. So it seems to me that it should really be more oriented to enable/disable what is wanted/not wanted rather than disallow a certain group to use a certain method.
This proposed method would also allow to easily attach a set of permissions, if really needed, that overrides the enabled/disabled feature based on permissions restoring the previous behaviour.
And last (but not least) it would allow a cleaner way to achieve the "I admin don't want you to select your own avatar" disabling completely the function for a certain group based on a single permission.
This makes sense to me, and seems the most simple for everyone to understand and use. Its seems silly to have to disable via permissions (which seems the primary use of those permissions) .
Is it too much for 1.0.2?
Due to the bug on avatar size, I'm really tempted to prepare this for the next micro...
/me whistles innocently
Go for it (I've already had to update a couple of lib files which I did not want to do for a micro, but bugs is bugs)
Yup. Go for it.
I go with Spuds! :)
Can I say this? :o
Yeah, I know the feeling, but now that I'm working on it, I think it's much better do it now than wait.
The upgrade is a bit of a pain, because take in consideration all the options is a pain.
For example, in the conversion between permission to setting, I can't do anything else than take a decision and set the method on or off, because the laternative would be to go and fetch all the groups and permissions and check for each of them if the option was enabled or not, and decide based on that if enable or disable, but then in edge cases I'd have to take a decision anyway, so... I'll just set them to "install default" and I'll try to put a warning around about it.
Here is it the pull request:
https://github.com/elkarte/Elkarte/pull/1883
it's bigger than I hoped it to be...
hmm... one doubt: if the GD resize doesn't work (for example for the same reason it was not working here), it may be useful to force anyway the css resize?
Yeah that makes some sense. I can see GD failing or iMagic as well, and then you are left with a bit-o-mess ... so the css is a good backup.