This is a thread to track discussions for MDL-56258.
Essence of the issue and topic of the discussion
Currently it is not possible to allow write access for guests. This is due to a Moodle policy of never allowing guests write access to prevent spam and to minimize attacking vectors (eg. possibility of XSS by anonymous users, etc.).
I understand the concerns about allowing guests write access but I think there are valid use cases to do so regardless.
This brings me to the proposal of adding an option to enable write access for guests regardless to the security concerns. I state explicit that this should not be enabled by default. For all I care, we could "hide" this settings under the security section of the site administration and add warnings about the risks.
The capability and role system we have is almost good considered. But it should be possible to use its complete power by allowing an admin to configure it completely to fit their needs. And not to restrict it. An admin should know what he is doing.
Additionally to prevent misunderstandings, as long as this setting is not enabled the corresponding capabilities should not be displayed while editing the guest role (more specifically a role based on the guest archetype or the role that is selected for the "Role of visitors").
And additionally, maybe to initiate another (related) discussion
The proposed workarounds of using the "No authentication" authentication method or using a dedicated user with public login credentials did not solve the problem completely.
This users will of course also get the role defined with the "Default role for all users" setting (by default this is the authenticated user role). But due to the algorithm of checking capabilities (calculate the combination of capability settings of all roles the user has in a specific context) it is not possible to give this dedicated user less capabilities than a normal user in system context but override this to explicit allow some specific things in a lower context. The prevent setting works just for overrides within the same role and prohibit setting can't be overridden (for a good reason). See the Override permissions wiki page for details. Maybe an additional setting "between" prevent and prohibit would be useful. But this needs another tracker issue.