Category Permission Control Question


  • Allow me for this basic question, but I really cannot find the solution so far.

    In this nodeBB forum, I see Announcements category prohibit users to create New Topic, and I would like to manage like this for my own BB.

    Looking at ACP, there's Category section, and I tweak Read/Write for Registered users, but the permission seems no change after all.
    I see Thread-Tools and I completely understood the feature, but category control is total mystery to me so far. What do I miss?

    Another question.

    I've implemented emailer, and email confirmation process is successfully done so far.
    However, I'm very uncomfortable with that Any users who register (or I would say just input info) without email-confirmation can create New Topic and post replies.
    How come the BB is designed like this??

    Is there any way to allow only email confirmed users can create Topic or post replies?

    Please let me know.
    Thanks.

  • GNU/Linux Admin

    Looking at ACP, there's Category section, and I tweak Read/Write for Registered users, but the permission seems no change after all.
    I see Thread-Tools and I completely understood the feature, but category control is total mystery to me so far. What do I miss?

    1. Admins are always able to post everywhere, perhaps that's why you don't see the change reflected?
    2. Read/Write was the permission system before, although it has been revamped to be more fine-grained. You'll have to update to the latest commits in the master branch in order to see them (or wait for v0.5.0 to land)

    However, I'm very uncomfortable with that Any users who register (or I would say just input info) without email-confirmation can create New Topic and post replies. How come the BB is designed like this?? Is there any way to allow only email confirmed users can create Topic or post replies?

    Email verification was added long before we had proper user groups, so I'll have to look into making "verified users" a group. By default, any registered user can post anywhere.


  • @julian

    Thanks for the detailed reply.
    I will try v0.5.0 or the pre-released master.

    I observe the most common BB systems around employ the level of users as below:

    1. administrator (and modifiers with some limited administration privileges )
    2. registered users (the registration is not complete until the user verifies their emails)
    3. guests (just can view contents)

    The concept of registered user(2) or registration with email verification is widely shared among SNS such as Twitter/Facebook/Google+.

    The problem of the current nodeBB system as the default I think is the forum is way too open without any email verification, and irregular/uncommon.

    Say, I have malicious intention, I can gain extra privileges with offering fake or random email addresses that actually does not exist.

    So, I suggest "verified users" as you say should be registered users, and "unverified users" should simply remain as guests.
    I see no points having registered-verified-guests users, and this idea would definitely confuse both administrators/developers (us) and users.

    What do you think?

    Regards.

  • GNU/Linux Admin

    No problem, gh#1592 🙂

    So, I suggest "verified users" as you say should be registered users, and "unverified users" should simply remain as guests.
    I see no points having registered-verified-guests users, and this idea would definitely confuse both administrators/developers (us) and users.

    I understand the sentiment, except NodeBB creates a user immediately upon registration. We don't keep any users "in limbo", and some forums don't have emailers installed, so we can't unilaterally kick out half of their users when they upgrade NodeBB 😄

    So we'd add another level of users... those who are "confirmed".. or "verified"... the terminology itself is flexible.

    julianlam created this issue in NodeBB/NodeBB

    closed Add a "verified users" group #1592


  • @julian said:

    No problem, gh#1592 🙂
    So we'd add another level of users... those who are "confirmed".. or "verified"... the terminology itself is flexible.

    Thanks for your prompt reaction. 🙂

    As you mentioned at GitHub-issues, some counter system against spamming is must-have, and actually the most common SNS or BB employes the email verification to register.

    I cloned the master edge and trying now, but Category Permissions is confusing I would suggest.

    I observe that
    checked = allow
    unchecked = disallow

    but, obviously, it does not work like this so far. In other words, the checking status does not reflect the permission status.
    As a default nothing is checked, but in fact guest is restricted in some way.
    When I start checking the Administrator, with logging out, the category disappear since guest has lost permission to view the contents even if their checking status is untouched.

    I know this is under heavy development, but just let you know, the current checking status does not reflect the permission at all.

    I wish I can help to code this section, but I'm new here, and wonder I can do right way.

    Thanks.

  • Admin NodeBB

    I agree with @Ken-OKABE the permissions dialog is confusing in that regard. For example if you want to prevent registered users from posting in a category you have to give posting rights to other groups. I think those checkboxes should start of checked and then the check mark will show their current permissions. That would simplify some of the null checks in the privilege system too.

  • GNU/Linux Admin

    @baris Yes and no -- I'm thinking greyed out checkmarks for the case where no permissions are checked. Ideally, that should make it much easier to understand what the assumed permissions are when none are checked.

  • Admin

    I think those checkboxes should start of checked

    I agree with this one, similar confusion with the previous system as well. Greyed out works too, but three states might confuse users as well, UX wise

Suggested Topics

  • 2
  • 4
  • 2
  • 3
  • 2
| |