Feature request: Category unlocking based on data

feature
1

We’re trying to create a drip-campaign style experience, where a new user sees only one category when they join and then every few days another category is unlocked.

We currently use category security to hide future lessons from students by setting those categories to admin-only access, and then, as the days pass, manually changing the security setting to allow everyone access on the day of the lesson/discussion. But this only works for everyone in our Discourse at the same time.

One thing that would save us time and ensure quality is if there was some sort of chron job we could associate with changing the status of a category. Allowing us to set up and create a drip.

But what we really want to do, and what we think might have somewhat broad appeal without creating technical debt, is to create the following:

Ue the time delta/difference between now and an individual user’s “created date” (created_at or created_at_age) to determine which categories they can and can’t view (e.g. If it’s been 7 days since they joined, then show category X).

There are two ways I can envision this working:

  1. A setting in the admin for a category that says, “open this category for users that have been enrolled more than X days.”
  2. Using the existing user level structure (guest, basic, moderator, admin, owner) which already can be used to determine category access, we could create basic1 through basic999 and ratchet users through the levels using created_at_age as the variable.

So, to recap: a way to algorithmically determine when the any category opens for user interaction, either by calendar date or by user experience age.

I think it opens Discourse to a host of really powerful uses, because keeping the community in sync (or cohorts within in sync) is an essential element.

Thanks for considering this!

14 Likes
2

Oh cool, this is a very interesting and thoughtful request.

It is almost satisfied by setting security on a category to be trust level 1; that is not purely time based though, it requires the user to read a few topics and a few replies with a minimum total time spent reading.

4 Likes
3

thanks @codinghorror

Here’s a simple use case: Imagine a discussion board around a TV series like Billions. A new category could be set to launch every time a new episode is set to air. Or there could be a discussion board with a new category set for “this week’s news” to drip weekly.

In the case we’re seeking, imagine any learning setting where you want, say, new employees to get a new category unlocked every day for 14 days, but you could do it on a rolling basis, so if someone joined four days after you began, they wouldn’t see all four categories, just one each day, in sync with anyone else who joined the day they joined.

When they got to a category, it would already have topics in it, but they’d be joining in with other fresh recruits…

5 Likes
4

A great idea that makes it much easier to envision Discourse as an LMS.

Set up the Category>Subcategory structure with all the course content.
Set the timers up to open new subcategories each week
Add a cohort of students and they’re good to go.

Secondary feature: allow a category to be a template that can be easily duplicated (already possible?). Once the category is duplicated, change the timer dates and launch a new course.

Basing the timer on students or schedule might vary based on the use case?

For a traditional class: If 90% of students are added on August 1 and 10% on August 2, then those who are a day behind might get frustrated. Simply allowing subcategories to be unlocked on a defined schedule would allow for planning ahead in delivering a traditional class.

For providing a new employee on-boarding process, where all employees are going through the same learning process, but based on their hire date, and you want them to see how other employees engaged with the content, then basing the timer on user join date would be necessary.

4 Likes
5

A practical implementation will be to add a new metric: User Grade with predefined levels (say, 0-10).

Then new system groups grade_0 to grade_10.

New users start at grade_0 (site setting).

Users move up grades via a number of possible mechanisms:

Automatic

  1. Time since joining (uniform, or different site settings for each grade)
  2. Time spent reading or time on-line
  3. Trust level maps directly to certain grades
  4. Predefined date/time schedule

Manual

  1. Manual promotion – e.g. after finishing intro course, move up to grade 1 to start Course 101
6

No, this would duplicate the existing trust system.

1 Like
7

This is already possible with a topic timer; simply create the topic in a private staff category, then set a timer to change the category to a public topic at the specified time.

The only requirement is that the empty category be created ahead of time.

2 Likes
8

The way I would do this is to create a set of groups (one week, two weeks, etc) and add members to those groups as time goes by.

You could do it with a cron job and a couple api calls, or, if you wanted, with a plugin.

The feature that you really want is an add-to-group feature like the sql badge system.

2 Likes
9

I’ve had a request from someone about using Discourse as a group “therapy” (discussion) program that takes place over 1+ years, where new content topics would be opened up on a weekly or monthly basis, and new “cohorts” of users would have access to past conversations and could continue them. (Along with the previous cohorts of users.)

So a feature like this would be very useful for that use case.

2 Likes
10

@codinghorror, When @Seth_Godin and I first looked at getting this to work, we tried using trust levels, but with 70 different categories that we want to unlock sequentially, it was just too much for the trust level system to manage.

I saw created_at and created_at_age in the API and thought that since it’s already something that’s tracked for each user it would be the cleanest way to accomplish what we’re going for.

1 Like
11

@pfaffman Tell me more. In addition to the “if the user joined more than 7 days ago, then show this category” behavior, we’re also thinking of implementing groups for everyone who joins on a given day.

I was using the API to create one new group each day and then pulling a list of all the users who joined on that day and adding them to the group. Is that similar to what you had in mind?

1 Like
12

My vision is that you’d have groups called “Week 1”, “Week 2”, and so on. You’d have categories with permissions such that the Week 1 category would be the stuff that the “Week 1” group should read, and so on.

Then, you’d just need to make API calls that would see if a user had joined more than a week ago, add them to week 1, and so on for each week.

Then, when someone had been a member for a whole week, they’d be added to the Week 1 group, which would give them access to the Week 1 category.

Does that make sense?

9 Likes
13

Oh, interesting…We didn’t realize that you could set view permissions based on groups.

That would work really nicely. Great thinking Jay!

3 Likes
15

Continued here: