Alternative sign up pathways

Support

AI-generated summary

Alternative Sign-up Pathways Discussion Summary

The discussion revolves around creating separate sign-up experiences for different user groups, specifically for a private forum with public and private areas. Paul_King wants to allow public users to sign up and access limited content without exposing private forum content.

Several users, including ondrej, Don, and nathank, suggest using plugins like Custom Wizard, Discourse Authentication Validations, and Discourse Automation to achieve this. However, Paul_King expresses concern about the cost and complexity of these solutions.

Don provides a detailed explanation of how to use groups, categories, and custom user fields to separate users on sign-up. nathank suggests using the Custom Wizard plugin, but Paul_King encounters issues with installing and configuring the plugin.

The discussion also touches on trust levels, with Moin pointing out a potential bug, and Don explaining how to set up group permissions to restrict access to certain categories.

Tgustilo shares a similar use case and asks about the feasibility of using the Discourse Subscriptions plugin. nathank clarifies that the plugin only integrates with Stripe.

Ultimately, Paul_King finds a solution using the built-in Automations plugin and a dropdown custom user field. However, Paul_King and tgustilo express the need for a more streamlined application and approval process, allowing administrators to edit user applications before approval.

The discussion highlights the complexities of creating separate sign-up pathways and the need for flexible and customizable solutions.

1

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?

2

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.

3

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.

4

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

Thanks @Don - some great things to investigate!

6

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.

The image shows a screenshot of a webpage with a title, "Automation", and several fields for inputting information, likely for creating a new automation rule on a forum. (Captioned by AI)
The image shows a screenshot of a webpage with a title, "Automation", and several fields for inputting information, likely for creating a new automation rule on a forum. (Captioned by AI)1054×1524 56 KB

7

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.
8

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)

9

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

10

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

11

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?

The image depicts a screenshot of a forum page, featuring a text-based interface with a header and a table displaying various groups, with the "Leave" button prominently marked as active for the "Architects in house discussion" group. (Captioned by AI)
The image depicts a screenshot of a forum page, featuring a text-based interface with a header and a table displaying various groups, with the "Leave" button prominently marked as active for the "Architects in house discussion" group. (Captioned by AI)1883×1573 243 KB

12

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.

13

Thanks @Don !

14

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

15

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.

16

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.

17

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.

18

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.

19

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.

20

What about

if you could create a free subscription?

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