We need to separate out the privs for input formats for Book pages.

Currently, anyone who needs to put an image into a page has to be made into a doc team member, so that they can use the "Documentation" input format. But we also use the Documentation image format to "lock" pages so that only people whom we trust a bit more have permission to edit them.

What we decided at the Vancouver docs meeting is that we would like some changes to this structure:

a) Make a new input format called "With Images" or something like that, which would support the IMG tag. Make it so that everyone who has passed the one month mark as a member of drupal.org is granted a role that has permission to use this input format (newer members could also request this role if they needed it sooner for some reason, and it could be removed from a user who abused it). Another criterion could be that the user has posted a few items (nodes or comments) on d.o (maybe over a few different days, to avoid spamming issues), if that would be easier to implement.

b) Change the name of the current Documentation input format to "Locked Page", or something like that, and continue to require people who need permission to edit these locked pages to apply for this priv.

Once this is done, we can (by request) change pages that have been set to the Documentation input format just because they needed images to the new "With Images" format, but we don't want to do this automatically, because some of these pages were locked for a reason.

Comments

zzolo’s picture

zzolo CreditAttribution: zzolo commented

This is a great idea. The image thing is a huge barrier for lots of users and getting in better, more visual documentation. I also think this is a very good way of addressing this problem. I would even suggest maybe 6 months as the lead time, but thats a small detail.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Active » Needs work

Given the potential CSRF attacks and other mischief that can be executed via IMG tags, can we consider instead a format that allows attached images to be embedded rather than granting general permission to use the actual tag?

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Status: Needs work » Closed (duplicate)

Right, I think #950414: Provide an inline filter for placing attached images into text areas is a better and safer solution to this problem.

scor’s picture

scor CreditAttribution: scor commented
Status: Closed (duplicate) » Active

While #950414: Provide an inline filter for placing attached images into text areas caters for the image issue described in a), the renaming described in b) is still needed to differentiate the pages which were locked for a reason other than requiring images.

apaderno’s picture

apaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
CreditAttribution: apaderno commented
Component: Drupal.org module » Other
David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

One thing to keep in mind regarding (b) is that once drupal.org moves to D7, the "Locked Page" input format technique isn't really going to work. (Well, it will work to prevent random people from editing the node body, but assuming you also want to prevent them from editing other things, such as the node title, it won't do that anymore.) So at that point, maintaining this functionality would require either a real node access module or custom coding or something else.

I know the D7 upgrade won't be for a while, but thought it was worth mentioning here anyway.

Gerhard Killesreiter’s picture

Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commented

Thanks, David, for mentioning this. We sure do not want a real node access module. We might need some node edit access module.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Right, couldn't it just be a hook_menu_alter() in drupalorg.module to change the access callback on the node/%node/edit menu item?

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

Looking into the new D7 node access system, it seems like hook_node_access() could be used for that. It doesn't touch the {node_access} table, so doesn't have the performance hit. In fact, inside that hook I guess you could just continue checking the format to deny access to the whole node if you needed to.

So maybe it makes sense to just keep using a "Locked Page" type of format for now, and then switch to something like the above in D7 (to ease the transition).

gagarine’s picture

gagarine CreditAttribution: gagarine commented

#1118144: Everybody should have the right to upload and attach an image marked as a duplicate

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

Subscribing...

I try to help as much as I can with triaging issue queues and I also try dev versions -where available- of all modules I use, reporting issues as I test things. I often attach screenies to my posts, so my life would be a lot easier if I was allowed to use the img tag. +1

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Title: Input format privilege modifications » Docs format and Docs role - figure out what to do

OK, I'm reviving this issue.

We now have #528682: Allow inline images to be posted to Drupal.org project pages, docs pages, and comments without any special permissions done, so anyone logged in can use images in the regular Filtered HTML input format, and hence part of this issue is resolved.

So we need to figure out what to do with:
a) Pages that are currently in Doc format - probably most should be unlocked, but we need to figure out which.

b) People who currently have Docs permission - probably mostly so they could edit pages with images, except for the actual major docs contributors (some of which have even more privs). So we need to figure that out too.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Status: Active » Closed (duplicate)

Oh, webchick filed a new issue that is cleaner and has a summary to do this. So marking this issue as a duplicate of #1275424: Deal with documentation role and documentation input format