Keep the user group called everyone, but disassociate it from guest

1st Official Post
    App
    WoltLab Suite Forum

    The everyone group is very helpful if you have a lot of user groups. You can basically set 1 group that sets all groups, but it loses it's usefulness and virtually becomes useless if like most sites you plan to limit guest. Because if you approve it in the everyone group, it currently will bypass whatever you have approved or disproved in the guest group

    So if I have 12 user groups, I want to be able to use the everyone group for simplicity. But I also want guest to be restricted, but the everyone group counts everyone. So now it's useless to me and I end up having to configure all 12 user groups independently, having disabling the everyone and also having to disable the guest.

    Edited once, last by Aslan (March 15, 2015 at 3:10 PM).

    Quote from Morik

    In this case you have the registered user group...

    There is no master "registered user group" that functions like the "everyone" group. The everyone groups can be useful if you have many groups, but it becomes useless if you limit guest.

    And I cannot find any reason not to disassociate it from guest unless you are one of the few who happen to let guest to post. In which case you're part of the minority. I know of few if any large site (5,000+ online) who allow guest to post.

    Sorry, don't check the exact names and only translated it myself^^
    There are 4 default groups in every wcf-installation.
    First one is the Everyone Group.
    Second one is the Guests Group.
    Third one Users Group. This one is the group where only registered Members are inside. So basically exact the group you wanted^^
    And Last group is the Administrators Group.

    Edited once, last by Morik (March 15, 2015 at 4:32 PM).

    Quote from Morik

    Sorry, don't check the exact names and only translated it myself^^
    There are 4 default groups in every wcf-installation.
    First one is the Everyone Group.
    Second one is the Guests Group.
    Third one Users Group. This one is the group where only registered Members are inside. So basically exact the group you wanted^^
    And Last group is the Administrators Group.

    The Users Group is bypassed by the Everyone Group, so you still end up having to disable everything in the everyone group, because you want something disabled in the guest group.

    • Official Post

    Let's sum it up, the best approach is too keep everything as it is, but with the exception that the Everyone groups goes without any permissions set by default. This way you still have a sledgehammer-group you can utilize to quickly set up things, but won't have to take the extra mile when you want to adjust some settings, e.g. for guests.

    Unfortunately the current system does not support setting permissions to an undefined state which would be required to achieve the aforementioned behavior.

    We'll probably change this somewhere in the far future. All I can say for now is, that this is most likely not taking place in the 2.x series.

    I can see you feel strongly about this topic, but was there really a need

    Quote from Alexander Ebert

    Let's sum it up, the best approach is too keep everything as it is, but with the exception that the Everyone groups goes without any permissions set by default. This way you still have a sledgehammer-group you can utilize to quickly set up things

    Good. We do need Everyone group to be able to override other groups if need be.

    Quote from Alexander Ebert

    Let's sum it up, the best approach is too keep everything as it is, but with the exception that the Everyone groups goes without any permissions set by default. This way you still have a sledgehammer-group you can utilize to quickly set up things, but won't have to take the extra mile when you want to adjust some settings, e.g. for guests.

    Unfortunately the current system does not support setting permissions to an undefined state which would be required to achieve the aforementioned behavior.

    We'll probably change this somewhere in the far future. All I can say for now is, that this is most likely not taking place in the 2.x series.

    I can tell you with confidence that Woltlab will not be the development of choice for a lot of things planned until this is addressed. :(

    The everyone group is well liked and the concept is sound (good), but its association with guest is a problem and even seen as a security concern by some of the people I've shown this too.

    Pros: It makes it very easy and convenient to administer a site with a lot of user groups. :thumbup:

    Cons: It is associated with the guest user group and bypassed the guest group, making it useless to use for the Pro listed above. :(

    • Official Post
    Quote from Adam Howard

    but its association with guest is a problem

    It's not a problem, instead one needs to be a bit more careful when setting up permissions.

    After all, if one got used with a differently working system, it always takes some time to get to know a differently working system. I can understand that it might be a bit harder for you to understand in first place, but this doesn't make it bad at all. You can achieve everything with our group system, all it takes is clearing up your mind and allow yourself to get around with it. Every software has it's own design choices and mechanics, in order to get used to them you must learn it.

    Also you should stop thinking that it bypasses any group, because this is wrong by any means. Permissions are calculated by taking all values set for each group a user is member of and then compile it together by preferring the highest value set for each permission. The Everyone group does not bypass anything. Period.


    On the other hand I can accept that it is not as easy as it could be and that is something we can work on.

    Discarding guests from the Everyone group isn't intuitive (wrong name) and you would end up by discarding the complete group.
    You have a Users Group which does exactly what you want in your pros listing...

    If you work with ACLs (like forum rights) it is much easier with the everyone group as it is, only group specific settings are sometimes less intuitive.

    One Question: Do you set up the Group Rights ore are you Setting up the Forum / Category Specific Rights ?
    The Global Group Rights have no real influence to the Forum / Category Specific Rights.
    So even if a guest is able to answer at all, if there is no forum where he could answer, he couldn't use this group right at all.

    Quote from Morik

    One Question: Do you set up the Group Rights ore are you Setting up the Forum / Category Specific Rights ?
    The Global Group Rights have no real influence to the Forum / Category Specific Rights.
    So even if a guest is able to answer at all, if there is no forum where he could answer, he couldn't use this group right at all.

    Let's step away from posting for a moment...

    The point of the everyone group is to make things simple, correct?

    There are many other options beyond just posting and you basically have to turn it off and treat the everyone group as a 2nd guest group in order to limit guest.

    • Official Post
    Quote from Adam Howard

    If I allow "everyone" to post, guess can post. The guest group has this turned off.

    This is because you assume that only one group at a time matters. This is not the case, because Guests are always member of the groups "Guests" and "Everyone", thus they inherit the permissions set for both groups.

    There is no such thing as forbidding something, instead you never grant the permission. If you do not grant the permission to create threads for "Guests" and "Everyone", then most likely nobody is able to create threads unless you grant it to the group(s) a regular user is member of (e.g. the "Users" group, all though it is granted by default).

    For clarification: Permissions are calculated by grabbing all values from the user groups someone is member of and then pick the best values, a short example:

    Group A: Can upload attachments up to 10 MB
    Group B: Cannot upload attachments at all
    Group C: Can upload attachments up to 50 MB

    If a user is member of group B, he won't be able to upload attachments. But as soon as you add this user to group A or C, he'll now be able to upload attachments, because being granted a permission is always better and thus overrules the lack of permission set for group B.
    If a user is member of group A and C, he'll be able to upload attachments up to 50 MB, because 50 MB is better than 10 MB.


    Long story short: You can always grant more permissions with each additional group, but cannot lower permissions this way.

    Quote from Alexander Ebert

    For clarification: Permissions are calculated by grabbing all values from the user groups someone is member of and then pick the best values, a short example:

    Group A: Can upload attachments up to 10 MB
    Group B: Cannot upload attachments at all
    Group C: Can upload attachments up to 50 MB

    If a user is member of group B, he won't be able to upload attachments. But as soon as you add this user to group A or C, he'll now be able to upload attachments, because being granted a permission is always better and thus overrules the lack of permission set for group B.
    If a user is member of group A and C, he'll be able to upload attachments up to 50 MB, because 50 MB is better than 10 MB.

    :thumbup:

    This is a great way of doing things and why I changed my mind (as did someone above me) that the everyone group can be very useful. The idea is this...

    • Everyone is the base group.
    • Next Group has more than everyone
    • Next Group has more than the previous group


    This is perfect. 1 problem... Guest is counted as everyone. But guest must be restricted. :(

    Quote from Alexander Ebert

    Long story short: You can always grant more permissions with each additional group, but cannot lower permissions this way.

    Dann wäre es vielleicht gut, wenn man einstellen könnte, das Plugins Permission nicht automatisch verteilen.
    Ich weiß, das dies von der Plugin Seite her möglich ist, aber die meisten tun dies um einigen Nutzern das ganze zu erleichtern, nur wäre es, meiner Ansicht nach, wünschenswert, das man dies, wenn man dies möchte, abstellen kann.

    • Official Post
    Quote from Adam Howard

    This is perfect. 1 problem... Guest is counted as everyone. But guest must be restricted. :(

    That was my initial point when I said that it would be better, if the Everyone group starts with a plain set of permissions (thus everything in undefined) which prevents the need to clear the permissions in first place. The Everyone group is actually powerful because it includes guests too, e.g. to revoke permissions for everyone for a specific forum and then grant them for the moderators group etc.

    "Everyone" - The name is meant literal for a reason.

    Quote from Alexander Ebert

    That was my initial point when I said that it would be better, if the Everyone group starts with a plain set of permissions (thus everything in undefined) which prevents the need to clear the permissions in first place. The Everyone group is actually powerful because it includes guests too, e.g. to revoke permissions for everyone for a specific forum and then grant them for the moderators group etc.
    "Everyone" - The name is meant literal for a reason.

    I agree, but it brings me back to this

    Keep the user group called everyone, but disassociate it from guest


    ^ This is how I imagine the "everyone group" working...

    • Everyone is the base group
    • The next group gets more then everyone
      The next group gets more than the previous group

    ect.. ect..

    You cannot use "everyone" as the base group ideally, if you plan on excluding guest. Because I would have to disable things in BOTH everyone and guest, but I want everyone else to have X feature without having to rush through the settings of 50 user groups.

    Imagine what Alexander said: If (maybe in an wcf version 3.0 ore so) the Everyone Group has no default Rights, than you could use your system by just change everyone to Users group and it would work perfectly fine ;)
    The current solution is not the best one, but it has benefits in many cases. Just the many default options are a problem because you have to remove them twice for guests^^

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login