JChrono and I had a nice discussion on this (chat link might still work in comments above), I've taken the opportunity to write up our chat, findings and proposed solution.
Firstly, we discussed the requirement to set the access permissions against a user. There are many many (lets say X number of) departments and each department has its own channel. We discovered that we will need a "member management" role that would grant other members access / posting permissions in the channels they manage. members can be assigned to more than one department, and there will be in excess of 1000 members.
After some discussion we concured that as member fields lack any sort of value|label options that suit, we could leverage Zoo Visitor. Zoo Visitor essentually creates a members channel, with an entry for each user and also links all this up in the CP. With this we also leverage the power of any EE field, and as such a group of checkboxes with values and labels. So now we can save a members access priviledges easily and they are easier for the moderator group to manage.
The next step discussed was applying these permissions. Here some discussion of what areas we are protecting saved us quite a lot of time. We quickly identified we will need to code an extension to hook into various publishing events in order to apply proper server side control.
We determined that the Admin CP was out of scope for this project, this itself saved ALOT of hook planning (see Control Panel Hooks). For both members and moderators all entry posting would be don via the Channel Entry Form (Saef) on the front end. Moderators will have CP access ONLY to manage members, and will have no access to the Publishing options in the CP.
With this knowledge we discussed the implimentation of the SAEF form. We can query the member object before displaying the form, this will tell us what channels or departments the user can post too, populate the channel selector (if applicable) and also hide the form if the user has no posting priviledges.
Lastly we discussed creating an exteension that hooks the entry_submission_start event. Here we can re-run the 'has access' logic just in case someone was trying to force a POST to a different channel.
There you have it, having the CP out of scope gave us a much more consise definition of what was needed, We covered how to set permissions safely (Use the CP to stop any injection of priviledge), we covered how to present the publish/edit form allowing membes only the posting options they need and finally we covered how to safeguard the posted SAEF form, in case someone was trying the good old post injection.
I certainly look forward to hearing how JChrono gets on and I'm sure he'll let us know!
Quote of the chat :
it's like pulling teeth from an already buried horse...
:D
