The original poster, OnceWas, wants to create a Discourse profile for an organization that can’t create posts, but can be linked to by the organization’s representative when needed.
OnceWas considered deactivating the account, but was concerned that this wouldn’t allow the representative to modify the organization’s profile. cpradio suggested that if the representative is a staff member or admin, they would be able to modify the profile even if the account is deactivated.
OnceWas prefers a technical restriction to prevent posting, rather than relying on a policy, to prevent accidental posting when the representative is logged in as the organization. cpradio suggests deactivating the account and having a staff member or admin make any necessary changes to the profile.
OnceWas is considering creating a custom trust level group that doesn’t allow posting, and Ahmed_Gagan suggests using the “Custom Trust Level” plugin, which allows revoking posting permissions for certain trust levels.
I know this seems like an odd request - but bear with me. I would like to create a user that can’t create posts. I want to be able to create a Discourse profile for an organization, separate from the person responsible for that organization.
An example would be YoyoDyne Inc., as a separate entity from the YoyoDyne CEO. I would like the CEO to be able to create topics and posts, but I would not want YoyoDyne Inc. to be able to post. The CEO would want to link to their company profile when they wanted to highlight the company, instead of linking to their own profile and posting history.
Got it, thanks for clearing that up. I can see the CEO forgetting that they are logged in as the corporate role when they updated the company profile, and then posting all over the place before they realize that they haven’t been posting as themselves…
I’d be open to developing a plugin that prevents members of a specific group from posting, unless there’s an easier way to do this.
So if you deactivate the account, make the policy: Any changes to that account’s profile must be submitted to X (who has Staff/Admin rights). That person then makes the necessary changes.
You are kind of imagineering a problem here, though. You’re imagining it will be a problem without any proof that it is. This is a dangerous way to design software in my experience.
I agree that we’re a bit of an edge case, feature-wise, but we’re definitely mainstream, behavior-wise.
I would love to know that our users would understand - and always remember - that they are logged in with one account vs another. But absent-mindedness is deeply ingrained. Typing into the wrong chat window, texting the wrong person, replying to all, or forgetting which account you’re logged into, are fairly common occurrences.
Policies are great, but they don’t fix human behavior.
I am currently looking at creating a custom trust level group, or equivalent functionality, which would not allow posting. A more open-ended approach would be to create a trust level group with admin-definable or admin-settable custom privileges.
