Hi. First post. Old forum guy. Been playing with our new Discourse install for a month. I’m in love. Long story short: I’ve changed some tl0 / tl1 settings to suit our onboarding process. Everything appears to be working great, except new tl1 users are getting the “You are not permitted to view the requested resource” error when attempting to post their introductions in the appropriate forum. Possibly related? At one point, I renamed tl0 to “wallflowers”, as we’ve locked them down to read-only in a single category. We decided to rename this group back to “New Users”, but I’m still seeing “wallflowers” listed on new users (which then links to the New Users group settings). Searching customized text for “wallflowers” returns nothing. Maybe there’s a cache-thing going on? This is the onboarding experience we’re working on: tl0/new user – read/reply access to “the rules” – must enter 5 topics and read 5 topics and spend 3 minutes doing so tl1/onboarding – gains access to “the lobby” – must enter 1 topic and create 1 topic (introduction) and spend 5 minutes doing so Also worth mentioning, I had to give “wallflowers” read/reply access to these categories in order for new/test users to see them, even though the “new users” group already had access. Feels like I’ve been kid-in-a-candy-shop and created a conflict somewhere. A link to screenshots in the hopes they help. Thank you for your time and consideration. I am just smitten with Discourse and can’t wait to get the rest of my team in and building things out for our beta testers. We’re gonna go good stuff.

Hey Brian, welcome! I’m digging through the screenshots you’ve shared, and something caught my eye. On page 2, I noticed that you’re listed as an “owner” of trust_level_0. That shouldn’t be possible…the trust level groups are automatic, and thus do not have owners. Does that screenshot show all your groups, or just the first 8? At the moment, given that the wallflowers (TL0) group has create/reply/see permissions on the Lobby category, all users of the site have full permissions there. I understand that’s not what you’re going for, and is for testing, but that likely means something else is wrong if a TL1 user can’t post there. Also, note that trust levels are hierarchical - all members of TL4 are also members of TL3, TL2, TL1, and TL0. TL3 members are also members of TL2, TL1, TL0, etc. As such, if you add TL0 (wallflowers) to a category’s security settings, you don’t also have to add TL1, TL2, TL3, and TL4 unless you want them to have different permissions. The same goes with staff users. The staff group is an automatic group made up of all moderators and admins. As such, if you add the staff group to a category’s security settings, no need to also add admins and moderators. Can you please confirm the following: That the groups page screenshot shows all groups, and not just the first 8. Your Discourse version That you installed following our official install guide Is your test user trying to create a new topic, or reply to an existing topic? Remove admins, members, moderators, onboarding, TL3, and TL4 from the lobby permissions and try posting again.

[image] jomaxro: That the groups page screenshot shows all groups, and not just the first 8. Your Discourse version That you installed following our official install guide Is your test user trying to create a new topic, or reply to an existing topic? Remove admins, members, moderators, onboarding, TL3, and TL4 from the lobby permissions and try posting again. Removing all the other groups solved the issue. My test user was able to post a new topic. Wo0t! Still, the “owner” mention on “tl0” suggests I’ve indeed made a bit of a mess and should revert things back to stock until I’ve seen things working the way we intended. To provide the remainder of the requested details… Groups screenshot shows all groups. Correct. v2.4.0.beta2 +127 “You’re up to date!” We’re confident Jay at Literate Computing installed everything correctly. Test user was trying to create a new topic. (And now can, successfully.) Removing admins, et al., from the category seemed to do the trick. (Cleaned up other categories.) Something tells me I should go back through and revert any text I’ve customized to make sure I’m working with the right groups. Hopefully that will clear up the owned “tl0” and “wallflowers” label issue. This was super helpful. Grateful. :allthethings: EDIT | Curious: Is there a time delay or something for some changes to propagate across the environment or maybe a button I can click to speed that along? I notice (and love) how things will change almost immediately when edited, but am curious why I’ve just reverted all tl-related customizations, they are reflected on the groups view*, but category settings still show the old names. [52%20PM] EDIT2: Clicking on any of the groups above, then backing immediately out appears to change that check or “Private” to “Owner”. Not sure what’s going on there. (And refreshing the page reverts them all back to Member or Private.) [18%20PM]

[image] TGP: I’ve just reverted all tl-related customizations, they are reflected on the groups view*, but category settings still show the old names. Can you give an example of something that hasn’t updated? TLs and categories aren’t really related so I’m wondering if there is a misunderstanding here.

Hey @HAWK. Thanks for asking. I might be using the wrong words. If you look at the last two screen shots, that’s what I’m asking about. Edit a category, click the security tab. Those are groups, right? Even if only automatic, tl-based groups? I can’t find “wallflowers” or “onboarding” anywhere in custom text or settings. I’ve reverted any changes to trust level names, labels, and/or user titles I’d made. So if my tl1 is “trust-level-1”, why isn’t it available on that category settings list? Could it be that I can’t remove it if there’s one user it there with that label? There only other place I’ve seen “wallflower” is on over of my test users.

Totally my fault, I missed that last screenshot. That is indeed a listing of groups in the category security modal! If you’ve renamed the group it should be reflected in that dropdown. Have you hard refreshed? (I’m grasping at straws here.)

In the browser? Yes. Any chance this old bug from 2016 might be in play? Seems like the behavior I’m seeing. Viewing this new user, for example, I see he’s in automatic group “wallflowers”. [54%20PM] When I click on that link, it takes me here (note URL): [45%20PM] But these are the only groups at this time (note: URL): [52%20PM] Maybe I’ve just really pissed off the database or something.

Sounds similar to this https://meta.discourse.org/t/can-not-add-category-security-for-new-group/126808/3 cc/@sam

[image] HAWK: Sounds similar to this Can not add Category Security for New Group That does sound like what might be going on. Overnight, things “magically” came into alignment. Groups w/ URL: [28%20AM] Group “trust_level_0”, which had been using “wallflowers” last night now has the right URL: [43%20AM] User who had “wallflowers” as automatic group now shows “trust_level_0” in profile admin: [00%20AM] Category security settings no longer show “wallflowers” or “onboarding” groups in drop-down: [19%20AM] So it looks like something is in place to delay certain changes within the DB? Thanks for the help with everything. This is awesome.

[image] TGP: So it looks like something is in place to delay certain changes within the DB? That looks very much like the delay in updating the User Directory. New users don’t show until one of the scheduled daily routines runs… and presto! They finally show up.

[image] JimPas: That looks very much to the delay in updating the User Directory. New users don’t show until on of the scheduled daily routines runs… and presto! They finally show up. Would that mean automatic promotion from one tl to another wouldn’t happen immediately? (I feel like it’s supposed to happen immediately.) The issue here has kind of evolved. My new users are now seeing only the one category as planned, but they still don’t appear to be getting tl1 access according to how I’ve configured the rules. new user signs up, == tl0 – gets access to only one category: the rules – must enter 5 topics – must spend 3 minutes reading user should be promoted to tl1 – gets access to second category: the lobby – must enter 1 topic – must post 1 topic – must spend 5 minutes reading I invited a test user, who received access to the rules as designed, but even though said user has met the criteria, user remains tl0. Second category (lobby) is configured with trust_level_1 group having create/reply/see permission, but new user does not see this. If there’s a chron job or something like that taking place overnight, I can dig that, but I need to know if that’s how it’s supposed to work so I can revise our onboarding plans to accommodate. Can anyone confirm that, please? TIA.

Tl0 > tl1: post error "You are not permitted to view the requested resource"

Product Support

riking (Kane York) August 28, 2019, 2:57am 13

Every forum gets its own shuffling of the scheduled jobs around the clock, and then that shuffling is kept stable for a while!

TL0-1 runs every uhhhhh 15 minutes or something? 1-2 and 2-3 (and 3-2) run daily.

Topic		Replies	Views
Is it possible to limit TL0 to posting in one category? Feature	18	676	May 7, 2026
Simpler and faster Category Settings page UX category-groups	23	628	March 27, 2025
How to deal with constant misuse of categories as a normal powerless user? Community Building	6	1081	October 20, 2020
Trust Level Permissions Reference Using Discourse trust-levels , reference	31	28675	August 27, 2025
Changes coming to settings for giving access to features (from trust levels to groups) Announcements trust-levels	30	6535	March 2, 2025

Tl0 > tl1: post error "You are not permitted to view the requested resource"

Related topics