Deploy fasttoggle to drupal.org for user blocking and node unpublishing

We want to keep a "paper trail" for all block actions does this module provide this? (I guess it doesn't)

We should have a way to auto--create a webmaster issue for each blocked used.

Otherwise there isn't much gain in simplicity in this.

Cool! Then we need to find a volunteer. :)

Would the hook be implemented in Drupal.org customizations?

It would, yes.

If the code to add is simply the implementation of a hook that makes a call to watchdog(), I can try to make a patch for drupalorg.module.

No, I don't think a watchdog entry is sufficient.

It should redirect the user to node/add/project-issue and set the appropriate parameters for such an issue.

I still don't understand why a user administrator would be allowed to block a user without an issue report being automatically created, and a site maintainer could not block a user without the automatically created issue.
The issue report can also be automatically created, but then needs to be edited, and the user would need to then click on the submission button. If a user cannot be trusted about blocking a user, then he should not be trusted about deleting posts.

Correct me if I am wrong, but the way the feature is proposed to be implemented would just have the effect to have site maintainers asking to be granted the role of user administrators, which is what happens now without Fasttoggle. The only site maintainers who would not ask such role are who block users very rarely.

I can work on the action when a user is blocked to file a webmasters issue. I actually have most of it implemented in custom code.

I understand the reason of deploying fasttoggle.module on Drupal.org, and I understand that is preferable to use that module, rather than giving a role; what I was wondering is:

• Users with the role of site maintainers can change the content of a comment, or a post, change the ownership of a project, add a user as co-maintainer of a project; users with that role are trusted for doing that, but they would not be trusted enough to block a user (the automatic created issue seems to me done because they are not trusted enough, but of course that is what I feel like about that).
• None of the operations I reported creates an issue report.
• Users with role of users administer can block a user without to create a report. I have seen many times a report about spam that has not been marked as fixed, when the user was already blocked; I take that who blocked the user didn't care of creating an issue report about that, or he would have noticed that there was a report about that user, or that post.
  I personally create a report when I block a user, and a spam report was not already created by somebody else; I don't see why site maintainers should be forced to create such reports.
• There is a custom module that creates a log for the activity of a user (http://drupal.org/admin/reports/role_activity), which shows also the activity of a single user (http://drupal.org/admin/reports/role_activity/user/55077); if the purpose of the issue report should be to know who blocked a user, then that should be added to the activities logged from that custom module; site maintainers should be said to create an issue report when they block a user, in the same way a user administrator should do.

investigating

FWIW: I've found FastToggle on the user profile page to be problematic in the past, as it only takes a single click for an administrator to block themselves.

For the most part I've experienced this on sites where the user is brought to their own profile page on login, so it's less likely to be a problem on d.o, but even so it's something that I'd be very wary of unless FastToggle has advanced to the point where it's not possible to block oneself unintentionally...

After re-reading this: I think the paper-trail idea still has merit but is not related to fasttoggle. We don#t have a paper trail for simply user blocks atm.

I guess this is good to go if somebody does the legwork.

Once deployed I propose we configure the module to:
* Allow user administrators to block/unblock users
* Allow node admins to publish/unpublish nodes on full node view and on teasers

I just updated our vendor branch and merged the code to d.o. It just needs deployment to d.o.

Deployed.

(untag)