Closed (fixed)
Project:
Drupal.org infrastructure
Component:
Other
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
1 Jun 2012 at 19:10 UTC
Updated:
18 Jun 2012 at 20:41 UTC
Splitting this off from #1613280: Upgrade permissions of dawehner ...
Now that #1275424: Deal with documentation role and documentation input format is done, only the uber 'administrator' and quasi-uber 'site maintainer' roles can access the Full HTML input filter at all.
(BTW, we've currently got 150 users in the 'site maintainer' role, although I suspect maybe only 1/2 of them are actually active as site maintainers in any meaningful sense. Reviewing that list and culling the stale 'maintainers' is probably a job for another issue.)
Yes, anyone we trust with Full HTML could do malicious things, but it'd be nice not to make it trivially easy for them to go clicking around in /admin/* if they don't have to. I'm more worried about the possibility of accidents than actual malice.
Can we just add a new role specifically for this so we can resolve issues like #1613280 without just making everyone a 'site maintainer'?
Comments
Comment #1
gregglesMakes sense to me.
+1.
Comment #2
dwwShould we call a spade a spade and name the role "Full HTML user"? Any further thoughts/objections?
Thanks,
-Derek
Comment #3
gerhard killesreiter commentedI am not worried about malice either, but couldn't we rather work on making such roles unnessary? ie providing safe means to add such widgets from a pre-approved list?
Comment #4
greggles@gerhard, so we need
1. someone to write a filter widget that turns [chipin:Get views in core:26a234b8f93e9d8c] into the right html
2. someone to test it, especially for performance
3. someone to maintain it, since no other site on earth would really want it
Seems like more work than appropriate. We have http://drupal.org/project/chipin but it's pretty dead and doesn't seem to have this feature.
Comment #5
gerhard killesreiter commentedI don't think that performance would be an issue since filters are cached. ;)
I do think however, that we really want to have those widgets on d.o pages. (I recall there is an issue for those). While I am ok with letthing dawehner edit html on d.o, I am not ok with any maintainer doing that. And we should't special-case one maintainer over others. Not in theory, at least.
Comment #6
lisarex commented+1 to having a "full html" role ... or maybe creating a new filter that is similar to documentation filter but results a lot less potential damage.
Use case: in order to restrict editing important pages (About, Accessibility etc) we have to use Full HTML. This means that trusted folks (who aren't necessarily site maintainers) can't edit. It's not a huge deal, but I've run into the issue with folks a few times.
Comment #7
dwwYeah, while I think long term we want to have a better solution to let anyone inject a chipin into their project page, a) that's a ways off and b) we have other uses for Full HTML that aren't just chipins. So, I still think we should move forward with this short term, and hash out chipins in general over at #148673: Using a ChipIn widget for Drupal donations. I agree we shouldn't special case maintainers, but until we have a generic solution, I'd rather special-case a few folks instead of just saying they're screwed.
So, can I move this forward or not?
Thanks,
-Derek
Comment #8
gerhard killesreiter commentedsure, go ahead.
Comment #9
dwwGreat, done. Added the 'Full HTML user' role, and gave it permission to use the Full HTML input filter.
Comment #10
jhodgdonFYI - #1275424: Deal with documentation role and documentation input format isn't quite done really. We were going to make a community docs moderator role, but so far only one person has really stepped up to volunteer as a moderator who is actually attempting to do the work, so I haven't gone anywhere with creating the role or having it granted to people.
Comment #11
gregglesThe last core release begs to differ: CVE-2012-1588 ;)