>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #1966218. --> Reported by: [webchick](https://www.drupal.org/user/24967) >>> <p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/webmasters/issues/1863498" title="Status: Closed (fixed)">#1863498: Create Basis for ToS to allow organizations to share accounts</a></span> seems to strongly be leaning in the direction of implementing the concept of "organization" accounts, with a limited set of permissions.</p> <p>Quoting from there:</p> <ul> <li>Having an "organization node" owned by a shared organization account makes it easy for that node to be edited even if the original author leaves the organization</li> <li>Having a project node owned by an organization, similarly, let's that organization manage the project even if a developer hired to work on it leaves the organization</li> <li>Contributing translations to localize.drupal.org can be easier via a shared account when the translations are done on client sites</li> <li>Case studies can be authored by a shared organization account</li> <li>All other forms of interactions (creation of nodes, committing code) should not be done by multiple people using a single account.</li> <li>The organization is 100% responsible for the security and use of the account - if it is used inappropriately (e.g. spam, posting ads in the hosting forum) it will be blocked the same as any individual account will be blocked.</li> </ul> <p>In 2012, Holly Ross (DA Executive Director), Danese Cooper (DA Board Member), Peter Welsch (of Whitehouse.gov) and I had a call to bat around how we might implement this.</p> <p>One of Danese's primary concerns, based on her experience in numerous other open source projects, is locking down the permission to "commit" on organization users so that source code changes can only be committed by <em>individuals</em>. Because without this, we hit a slippery slope where organizations might try and sneakily commit code in order to hide who's working for them, and essentially wreck the whole fabric of open collaboration. Pre-emptively combatting this sort of abuse seems to be in harmony with the community-recommended guidelines, as well.</p> <p>While we could handle this on a reactive "ban troublemakers where we see them" basis as we have been historically, that gets tricky with straightening things out with Git, so we might want to be a bit thoughtful about how we roll this out. Our idea was:</p> <ol> <li><strong>A flag on user accounts to identify them as individuals vs. organizations.</strong> A field added to user accounts.</li> <li><strong>An "organization" user only gets permissions to post organization nodes, case studies, and projects only.</strong> All other permissions (commenting, posting forum/issues, and especially the "Git access" checkbox on the user profile) are removed. This will likely be a few hook_menu/form_alter() calls in a drupalorg sub-module, unless there's a module out there that does some kind of "role with <em>reduced</em> permissions compared to authenticated user" (actually, LoginToboggan did such a thing a long time ago iirc, not sure if it still does or if there are better alternatives).</li> <li><strong>To discourage organizations from skirting around the permission lock-down by not checking the "Organization" box in their profile, add a "carrot".</strong> One idea is making it so "Organization" nodes can only be owned by users in the "Organization" role (we'd need a transition period to sort this out), and at the same time adding more "oomph" to those pages; for example, an auto-generated list of recent contributions by their employees, etc. This way, it becomes a nice marketing tool for organizations, and incentivizes them to contribute more, because they can point prospective clients/employees at their organization's Drupal.org landing page. If they choose to uncheck the "organization" checkbox to try and sneakily commit code by multiple people, they lose access to this nice page.</li> </ol> <p>I don't think any of these are too onerous; just a few lines of custom code and a couple of new views. But it would both allow us to incentivize contribution by organizations, while at the same time protecting the interactions that cause the community to thrive.</p>