Wedge

The difficulty I'm having explaining this to SMF veterans is staggering ;)

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.

It's been a few days since I posted in here with something I'm 'definitely' doing rather than asking input on. (Though this is also a WIP)

So, the plan is to offer a list of who can see and edit a given field rather than the current options. I have a few things to work out in the design but it's getting there ;)

No, we can't check that. You should report it to SMF and see about one of the developers fixing it, or reporting it on their Github account (https://github.com/SimpleMachines/SMF2.1 see the Issues tab)

(FWIW the installer has common code with Wedge's, but WAP2 is GONE in Wedge.)

That is in essence what SMF tried to do in 2.0 - by making deny permissions an optional extra, and by essentially making everything a binary choice by default. I'd argue that's even more confusing that having the three way switch just available by default.Except it was never really binary in the first place, nor was it 'disallow' being taken out of the picture. Previously the choice was allow/disallow (binary) or allow/disallow/deny (tertiary), Essentially what I'm suggesting is *still* a tertiary system, but one that, with some UI hinting, should suggest the actual behaviour involved. Tick allow to allow it, tick deny to deny it from everywhere (aka never) and neither to do nothing with it.

Question: if you can tick both allow and deny, which would logically take precedence? What would you expect it to do if you selected both?

What I will note is that I looked around a bunch of systems and this seems the least unintuitive to me - as in there's no 'best' approach but only a series of 'less worse than...' approaches and this seems to me to be the least worst. The only variation I can think of is to present each permission as a dropdown (been there, done that, you'd be surprised how quickly that gets old)...

Mind you, there is one validity to dropdowns, and that's what I did in SimpleDesk, which was to align own/any in a dropdown, so a permission choice was No, Yes - Own, Yes - Any. Mind you in SD's case I didn't have any UI for denied.To a point that depends on your expectation. See attached. It's the exact same mechanism, albeit tweaked slightly for other things and without the prior set of having to press Edit to actually configure it. (There is a sort of hierarchy involved. I expect to bring some of that in too.)

Mind you, just consider that it could have been so much worse than this. ;)



Just to clarify: if there are enough objections, I won't push forward with this. I'm aware that this is an important thing to get right and that what I have is still essentially experimental. It may be that it actually needs to be tried in a real environment to get a feel for how well it would really work.

No, that's the point. What's in SMF is radio buttons. This is firmly NOT radio buttons (because you need to be able to represent both unticked = disallow which can't be done with radio buttons)

I'm not sure it will because remember that a bunch of the checkboxes will be unticked for most permissions for most users out of the box.