Alternative sign up pathways

I run a small private forum for architects, but would like to add an area accessible to the public, that the architect users can monitor, where laypeople can ask questions or contribute their own perspectives to discussions that are made open to the public.

The idea is that members of the public see only public discussions, while architect users see both private and public discussions.

Members of the public should preferably have a different sign up experience, as there are a lot of custom fields for architect member sign ups that would not be relevant, and should have fewer options from their control panel settings (for example I don’t want to offer the public the same mail-list functionality available to architect members), and public users should not ever be be able to elevate their trust settings in such a way that private area content becomes exposed to them.

I don’t want to create two completely separate forums, as this would presumably trigger the need for two domains, double costs, and add the difficulty of keeping architect user memberships synchronised between forums as they come and go.

How best can I accomplish this?

3 Likes

I think you can do something like this using the Custom Wizard Plugin 🧙. Choose if you are an architect or not and it will give a different signup pathway. I had this plugin 3-4 years ago so I don’t really recall all the features that well.

2 Likes

Sadly, looks like that plugin would cost $US 50 per month to have any conditional functionality (which is what I would need, if I have understood correctly) - trebling the current cost of hosting the whole forum - which all comes out of my personal pocket.

1 Like

Hello :wave:

I think the most of these available with: groups, categories permission, custom user fields and automation.

To separate users on signup use Discourse Authentication Validations chaining user fields function. So you can show separate user fields depends on what they choose on the first option ( architect or laypeople. )

After this, with Discourse Automation you can automatically add these users to the expected group.

For example:

User Field Option Group
architect → architect
laypeople → laypeople

Finally set up the categories permissions for these groups.

  • architect group can see architect and laypeople categories
  • laypeople group can see laypeople categories

Something like this maybe can help and add some idea. :slight_smile:

5 Likes

Thanks @Don - some great things to investigate!

2 Likes

Looking at the Discourse Automation plugin, for some reason there seems to be nowhere to actually nominate which group affected new users are assigned to.

1 Like

You should be able to achieve what you want with the Custom Wizard Plugin 🧙 on the free tier. And your community will almost certainly qualify for the free community subscription if you do in fact need more advanced functionality.

I’d approach this by:

  1. Limiting the exposed UCFs to what you want to collect from casual members
  2. Use one question to identify those who should be full architect members
  3. This UCF can then gate a joining Wizard, which can be used to put them in a specified group and ask all of the other UCFs / data that you need.
2 Likes

Thanks @nathank !

I will take another look.

A trick in my case is there are something like 15 qualifying user characteristics (currently identified via multi-select custom user field) for access to the private forum area. For better or worse, my first thought, for simplicity, was to try and control access levels via this one multi-select field somehow.

Sadly the Discourse Automation plugin at least does not seem to distinguish anything beyond a simple populated vs unpopulated state for the field in custom user fields (essentially a tick box) - I presume the same may apply for the Custom Wizard plugin?

** EDIT ** for some reason I can’t even seem to install this particular plugin Discourse Custom Wizard Plugin install failed - Support - Pavilion - will report back here once resolved
** EDIT ** now installed (a wrong path used in nano)

1 Like

Here is the document how to set up: Adding users to groups through custom field automation

1 Like

Maybe this works for your sign up process: Discourse Authentication Validations

1 Like

Thanks @Don. Do other groups (like ‘Public’ in screenshot below) behave like the predefined trust_level groups, and if so, is there a way to prevent automatic progression to increased trust levels/permissions for users based on usage? Or is it only explicitly trust level groups that behave this way?

1 Like

You can set the Public group auto trust level.
/g/group_name/manage/membership

If you set it to e.g. 1, then the users in this group will be locked on Trust Level 1. It is useful if you add people automatically to this group when they signed up and they will automatically grant the TL1 (locked). Or if user already registered but under TL1 then they will also reach TL1 (locked) after add them to the group. So they cannot reach higher TLs.

But this process won’t work reverse so if you add a TL1 or higher user to the group they won’t be locked on TL1.


I don’t know about your site category structure but probably you can play with that too… Change trust level permissions to these added groups to ignore TL accessibilities.

1 Like

Thanks @Don !

1 Like

Are you sure they cannot reach higher TLs? I found a bug topic where the TL3 promotion was added when the trust level is locked by a group, so I would expect that it has worked for other TLs before

1 Like

Hmm, I’m not sure about that :thinking: Isn’t that only applies for TL3 promotions if the auto TL set to 2?

Edit: My bad, thanks @Moin for the clarification and sorry for the wrong info. My previous answer won’t keep users on the selected TL.

1 Like

This use‑case is of interest to me as well. Similar kind of community but system modelers not architects. Thanks @Paul_King for pushing this along.

2 Likes

Above all I need to ensure content is never visible to public forum users unless explicitly posted to the public forum topic category.

Also important is to ensure public users never gain a way to redefine their own topic categories access, even if trust levels do automatically increase.

1 Like

I would do this:

If you don’t add TL permission to a category, but add other group permission like I write above then the TL level doesn’t matter because not that will defines who can access the category but the added group.

1 Like

You seem to have gotten that sorted. Have you tried it for your use-case?

I don’t think that the CWP supports multi-select fields at the moment, so you might need to work around that.

I think that the term ‘Trust’ has been a red herring. You can manage this with a simple group for all those who should have access to most content (i.e. your architects), ensuring that this group (and not everyone) has access to the restricted categories.

Do be aware that you will lose some functionality with a hybrid forum. In particular, Oneboxing is not permitted with restricted categories (unless within that specific category).

This is an impressive looking (experimental) plugin - whilst it looks like a bit of a mind-bender to configure, I can see it being super helpful for several things.

What about

if you could create a free subscription?

I see it’s included with Standard and above for hosted Discourse.

1 Like