Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in Class-WebGet.php on line 184

Warning: file_get_contents(): Failed to enable crypto in Class-WebGet.php on line 184

Warning: file_get_contents(https://wedge.org/files/current-version.js?version=1.0-beta): failed to open stream: operation failed in Class-WebGet.php on line 184
Permissions UI, latest experiment - page 2
Permissions UI, latest experiment

xrunner

  • Posts: 192
Re: Permissions UI, latest experiment
« Reply #15, on May 15th, 2013, 02:19 AM »
Quote from spoogs on May 15th, 2013, 02:02 AM
Based on smf2 (i sure its the same in smf1 but i never usd it)

Allow grants the permission based on a membergroup
Disallow does not grant the permission
* If however  a user is in a group that allows the permission and also in a group that disallows the permission, the permission will be granted via the group that allows it.

If a permission is denied to a group the user is in the permission will be explicitly not granted even if the user is in another group that allows the permission
I'm not sure what exactly to say next ... :huh:

Thanks for your reply, and I read it several times before I was sure I understood it. I do understand what you are saying, but you also said "Based on smf2 ..."

I looked at the permissions (I've looked at them and set them for years but looked again) and I do not see "allow" "disallow" and "deny" in the permissions or any implication that they act like you are describing. All I see is a check box that is either checked or not checked for the permissions. Is there some underlying scheme I've never understood all these years that I need to be aware of, or are we just talking on two completely different levels (me being on the lowest level I'd guess :)).

Thanks.

spoogs

  • Posts: 417
Stick a fork in it SMF

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Permissions UI, latest experiment
« Reply #17, on May 15th, 2013, 02:24 AM »
For example you might set up a troublemakers group and use that to revoke all kinds of permissions regardless of other groups they are in (except admins), so you could use it to remove their ability to send PMs or even to remove their ability to post in specific boards by way of this permission.

I find it very interesting that people are considering this 'deny' power as a new thing because that's exactly why I wanted to change it. It's so inobvious how you find it or use it as it stands.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

xrunner

  • Posts: 192
Re: Permissions UI, latest experiment
« Reply #18, on May 15th, 2013, 02:25 AM »
Quote from spoogs on May 15th, 2013, 02:22 AM
In smf2 you have to enable deny permissions to see it.
Ah. I see it in the settings menu. I guess I never touched it because of this message -

Use with care, a denied permission will stay denied no matter what other membergroups the member is in.

Every time I see a software message that begins with "Use with care ..." it scares the shit out of me. :)

Thanks for the information though.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
The way it's meant to be

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Permissions UI, latest experiment
« Reply #20, on May 16th, 2013, 03:35 PM »
Given the feedback I've had here, that I've had on sm.org and the feedback I've had privately, I don't really see any point continuing with this, it's just proving to confuse people more than the messed up system we already had.

Though I have one change I won't be reverting, and that's to remove the option for deny permissions - as in they will always be enabled in future, so then it's just trying to salvage the wreckage of what we have.

spoogs

  • Posts: 417
Re: Permissions UI, latest experiment
« Reply #21, on May 16th, 2013, 04:03 PM »
I honestly do not see how it is confusing. I do get that no matter what someone will find a way to be confused, but I think explaining how it works is rather simple as well. All I see happening is something along the lines of:
Issue
I use to use SMF (or some other system) the permissions for Wedge is different to me, how does it work?

Resolve
To allow a group to have a certain permission check the box to allow the permission. Leaving the box unchecked will not grant the members of a group this permission. Do however note that if a user has multiple groups where at least one group allows the permission and at least one group disallows the permission, the permission will be granted via any group that allows it[1].

If you want to explicitly ensure that a group will not have a certain permission check the box to deny the permission. Denying the permission will ensure that users in this group will not have this permission even if it has been allowed by another group the user has[2].

Heck I think those explanations can even be plugged in next to Allow and Deny with the help icon. I'm also certain by assumption things like this will be documented anyway. I highly doubt there will be a solution that fits the bill as not being confusing to someone. I even strongly believe using the illustrated iteration will prove less confusing than reading it. I'm curious to see where the ideas go from here though.
 1. I dont think this is anymore confusing than even SMF already has to explain
 2. This is way less confusing than the explanation required in SMF, where one must first go and enable deny permission

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

spoogs

  • Posts: 417
Re: Permissions UI, latest experiment
« Reply #23, on May 16th, 2013, 04:14 PM »
Frankly I think that's just trumped up to I don't like change, albeit for the better. So whats the solution there, keep what SMF has?

Keeping the current illustration in mind the only thing I see simpler is as u stated the drop down a'la SD Allow/Disallow/Deny. I mean those are the 3 options just a matter of how its presented right.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Permissions UI, latest experiment
« Reply #24, on May 16th, 2013, 04:18 PM »
Oh, keeping what SMF has is not really an option in my mind. Just means I need to go back to the drawing board again.

The problem with SD type dropdowns is that there is not really any scope for deny permissions in there - in SD's case that was intentional (the code supported it but the UI never did because I never saw any *need* for it there and my take on it appeared to have been validated)

However I see deny permissions in the main forum as a necessity on some level, e.g. for a troublemakers group, and then it becomes a game of presentation.

spoogs

  • Posts: 417
Re: Permissions UI, latest experiment
« Reply #25, on May 16th, 2013, 04:42 PM »
As far as SD I just meant the style. Looking at SMF's A/X/D, i was of the assumption that could be presented 'somewhat easily' as a dropdown.

Still a little sleepy so we might be saying the same thing here and I'm just not noticing.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Permissions UI, latest experiment
« Reply #26, on May 16th, 2013, 04:52 PM »
Well, the A/X/D part could be, but one of the big things I did - and damn it was subtle - was flattening the way own/any permissions worked.

In SMF and Wedge, you can quite happily grant/revoke own/any permissions separately, though the cases should be fairly rare that you'd ever need to. In SD, though, the permission choice doesn't exist like that.

A normal permission in SD is 'allow/disallow', an own/any permission in SD is 'allow own/allow any/disallow either' without any option for denying, on the basis that if you have 'any', you implicitly have 'own' as well.

Now, history has shown that my call on that made sense for SD: because own/any in SD terms made sense, the permission model made it feasible and approachable to build inclusive setups without getting into a need for deny permissions. If everything is off by default for everyone you have to give them things.

SMF's more general permissions are a lot more inclusive by default, so there is a sort of need to make things more exclusive through deny permissions, plus of course cases like the aforementioned troublemaker group.

That said... I'd actually probably be more inclined to extend the warning system and do it *that* way rather than juggling permissions. After all... why do people normally create deny groups in the first place? What purpose do deny groups actually solve?

Well, they're for excluding people from doing things they would normally otherwise be able to do. So the question then becomes: why are they not allowed to do what they're otherwise able to do?

The logical answer to me about that is warnings/punishments/<insert terminology of choice>. So if you tie it into the warning system instead of the general permissions system, you don't actually *need* deny permissions, right?

Kindred

  • Posts: 166
Re: Permissions UI, latest experiment
« Reply #27, on May 16th, 2013, 05:11 PM »
I like this concept...

Actually, I find the deny group useful - and not just for trouble makers....

because of the "all members" group and the inclusive way that smf does permissions, I have some groups (especially post-count groups)set to DENY access to functionality.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Permissions UI, latest experiment
« Reply #28, on May 16th, 2013, 05:18 PM »
Wouldn't you instead grant that access by giving it just through the higher groups?

Or even just set a minimum and/or maximum post count for a given permission?

spoogs

  • Posts: 417
Re: Permissions UI, latest experiment
« Reply #29, on May 16th, 2013, 05:24 PM »
@Arantor

I get ya. In reference to your last point:

I do my level best to have the fewest amount of groups possible and very few member that end up in multiple groups (but it does happen). Most groups are requestable and each of these groups has their own board. What I did for my sanity was to create a permission profile for each group that has a board such that for Group1 there is a board permission called Group1. Each group decides which other groups they allow to access their board and what those users can do in that board. In some situations I have used deny permissions to ensure that a group cannot do something undesired on another group's board. Not necessarily a punishment.