# Feature request: Category unlocking based on data
**URL:** https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305
**Category:** Feature
**Created:** [18 Ottobre 2017, 1:19am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305 "2017-10-18T01:19:48Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@Seth\_Godin](https://meta.discourse.org/u/Seth_Godin)
#### Post date: [18 Ottobre 2017, 1:19am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/1 "2017-10-18T01:19:49Z")
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!
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [18 Ottobre 2017, 1:22am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/2 "2017-10-18T01:22:24Z")
> [@Seth\_Godin](#):
>
> 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).
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.
---
### Author:  [@Seth\_Godin](https://meta.discourse.org/u/Seth_Godin)
#### Post date: [18 Ottobre 2017, 1:50am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/3 "2017-10-18T01:50:17Z")
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…
---
### Author:  [@outofthebox](https://meta.discourse.org/u/outofthebox)
#### Post date: [18 Ottobre 2017, 2:09am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/4 "2017-10-18T02:09:39Z")
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.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [18 Ottobre 2017, 3:28am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/5 "2017-10-18T03:28:57Z")
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
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [18 Ottobre 2017, 7:09am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/6 "2017-10-18T07:09:49Z")
No, this would duplicate the existing trust system.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [18 Ottobre 2017, 7:10am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/7 "2017-10-18T07:10:49Z")
> [@Seth\_Godin](#):
>
> 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.
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.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [18 Ottobre 2017, 12:23pm UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/8 "2017-10-18T12:23:03Z")
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.
---
### Author:  [@downey](https://meta.discourse.org/u/downey)
#### Post date: [18 Ottobre 2017, 12:32pm UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/9 "2017-10-18T12:32:49Z")
> [@codinghorror](#):
>
> Oh cool, this is a very interesting and thoughtful request.
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.
---
### Author:  [@alxpck](https://meta.discourse.org/u/alxpck)
#### Post date: [18 Ottobre 2017, 1:10pm UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/10 "2017-10-18T13:10:34Z")
> [@codinghorror](#):
>
> 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).
@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.
---
### Author:  [@alxpck](https://meta.discourse.org/u/alxpck)
#### Post date: [18 Ottobre 2017, 1:11pm UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/11 "2017-10-18T13:11:47Z")
> [@pfaffman](#):
>
> 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.
@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?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [19 Ottobre 2017, 12:02am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/12 "2017-10-19T00:02:43Z")
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?
---
### Author:  [@alxpck](https://meta.discourse.org/u/alxpck)
#### Post date: [19 Ottobre 2017, 12:39pm UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/13 "2017-10-19T12:39:22Z")
Oh, interesting…We didn’t realize that you could set view permissions based on groups.
> [@pfaffman](#):
>
> 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.
That would work really nicely. Great thinking Jay!
---
### Author:  [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [17 Luglio 2018, 6:10am UTC](https://meta.discourse.org/t/feature-request-category-unlocking-based-on-data/72305/15 "2018-07-17T06:10:05Z")
Continued here:
> [@What if badges could optionally synchronize group membership?](https://meta.discourse.org/t/what-if-badges-could-optionally-synchronize-group-membership/92232?u=erlend_sh):
>
> I was looking at this topic today: Thinking through the problem one area Discourse is a bit weak is around defining “dynamic” groups of users. Give me a group of users that signed up more than 1 month ago Give me a group of users that posted at least 10 times And so on. Badges on the other hand have very rich support for this “dynamic” nature once the fancy SQL is enabled. Having an “extra” tick box on badges to bridge a badge to a group would add a lot of power. We have no way of a…