Wedge

Some of these seem to apply to software writing too.

http://www.brainpickings.org/index.php/2012/09/28/neil-gaiman-8-rules-of-writing/

I know I've reported the first before but this is to remind me to dig into it.

A call of add_plugin_css_file('Arantor:PiePolls', 'piepolls', true); will grab $plugindir/piepolls.css which is fine. (I seem to remember the last parameter being reversed, i.e. the default being to include the CSS file in the header, rather than having to explicitly indicate such)

The problem is that it generates:

Now I know why this happens, add_plugin_css_file wasn't kept in step with add_css_file, but I'm not sure I want to touch add_plugin_css_file to bring it in line with add_css_file (since there's a *lot* of code for that by the looks of things)


Secondly, plugins can't use inline block. I'm sure I've brought this up before, but it just doesn't work. My file contains:


The definition of inline-block is simply not pulled in because the plugin loader never pulls in anything other than the plugin. I'm aware this has always been the case - but until inline-block was a virtual class, it was never a problem. When inline-block was made a virtual class, I mentioned it then, and I mentioned it again about two-columns not being extensible in a plugin (since I wanted to make a three-columns class based on two-columns just with the width changed) but that's also not possible either.

Virtual classes and mixins are great but if plugins can't use them, I need to figure out something else entirely for them.

So, I've been noodling around with this, and nothing I'm happy enough with to provide screenshots of yet, but let me explain where I'm going and see what you think.

There are a great many issues with the permissions UI and structure.

First up, regular group permissions. I'm still working with what I proposed in http://wedge.org/pub/feats/7662/permissions-ui/ - namely a single big table with all the groups along the top, the permissions down the side, and all the permissions shown there.

There are several bits I'm not entirely sure about, like exactly how you set the permissions. I don't really want to present a minefield of buttons to the user, nor do I want to present a minefield of <state> <button to change> Maybe I'll have it click to change the permissions for a given group <-> permission, but that could get clunky if there's a lot of changes you want to make. Maybe it should be a dropdown for each one to select the state.

This makes me wonder other things. I'm not averse to exposing 'deny' permissions generally. However, what I am concerned about is the mentality. A/D/X is confusing. Elsewhere (board access) we use Yes/No/Never to represent that states, and we need to get a bit more consistent - I'd be happy dragging Yes/No/Never over to permissions too.

Another system I'm liking has two checkboxes, rather than radio buttons - one for allow, one for deny.[1] I'm not sure what I'm going to do yet, would appreciate thoughts.

Note that I'm looking to remove the 'default profile' being shown underneath the general permissions, but the whole nature of that I'll get to in a minute. I would also be tempted to remove some of the other stuff in the admin pages, like 'setting permissions for one group like another' - basically if you go to the permissions page, you get the list of groups, then some stuff below those groups for things you can apply to the groups; setting 1+ groups like a template, setting a single permission on each of the ticked groups. Seems to me that a single big ol' list would negate the need for that. Permission copying would be reasonably simple too.

There was a concern previously about fitting it all in - while this is not a huge deal for the most part (inherited groups wouldn't be shown either, to save space), I'm also looking at using http://fixedheadertable.com/ - you'd keep the group names and the permissions in view at all times and scroll across to fit.

I don't think there was any real objection, but I think now I'm looking at it again, I'm having second thoughts on the idea - but I also know I don't have anything better to solve the problems I want to solve. I don't want to get into huge scale re-engineering if the idea doesn't feel sound, and right now this doesn't.


Board permissions. Ah, yes, I couldn't forget this, could I? I've been looking at what SMF 1 did versus SMF 2, unique board permissions vs profiles and I think I might have a better solution but this is sort of off the cuff. If I said it came to me while I was sat on the toilet[2] you'll hopefully understand.

So, let's recap, first of all.

SMF 1, for those who never used it, had the notion of global versus local board permissions. You'd set the permissions for each group generally, and if you had a board whose permissions were different, you could indicate as such and get unique permissions for that board.

Conceptually that's fine, until you have two or more boards that need the same-as-each-other but unique-compared-to-everything-else permissions. Incidentally, sm.org has this very setup, there are boards that have different permissions to any other (namely showcase, but some of the internal boards have that going on too)

Meanwhile, SMF 2 has the idea of profiles. You have some template profiles (but one you can actually change despite the system telling you that you can't, which I'm still not sure isn't a bug in disguise), and you create new profiles to apply them to the relevant boards. Great for managing boards with a few tiers of boards where you only have a few sets of 'permissions'.

Then we have SimpleDesk. This did something a little bit different: permissions were expressly not tied to groups. You create roles, which are essentially groups of permissions, then you say 'these groups, have these permissions, in these boards'. For example you'd create a staff role, which had a bunch of permissions, and all the time they were in those boards, they had those permissions. It was a bit ropey in places because I abused the concept in two interesting ways.[3]


Two options present themselves, ultimately.

Firstly, I can take the SD route. The UI can be nicer this time because I don't need to pull stunts around 'non board permissions', I can safely have the UI abstract that stuff away. But I'm not sure how well the 'groups != roles' concept will get across and I'd hate to lumber us with 'how do I set this permission up' crap.


Secondly, and perhaps more confusingly in a way. I can sort of regress back to SMF 1 permissions. I'd envisage it being split between permissions and the board configuration area, or at least... mirrored that way.

See, what I'd envisage doing is giving a list of the board type permissions, and the groups again - like above. Only this time, with an extra dimension to it. For each permission, you'd select the list of groups who have it/don't have it, but there's an extra option: apply to all boards. If you say 'apply to all boards', all the boards the users can see would be able to have/not have that permission. For example, posting replies would typically be yes to any group who can see the board in question. So you'd just have that as 'all boards', and just set it to the groups who reply.

If you decided you didn't want it as all boards, I'm thinking that the list of boards could fold out underneath to indicate that permission for that board/group combination. I think it could be thoroughly ugly, but I think it would be more intuitive than the current permissions setup.

Then you could go into a given board and see how it is in that given board, and configure it that way too. It would be back to local vs global permissions but easier to configure for simple changes. Of course if you have a lot of boards, changing things is going to suck very, very quickly, which is where profiles win.

More importantly, newbie factor. Setting up roles is not the most obvious thing, especially if you want people to be able to dive in and just set up a forum quickly, though I guess if sane roles were defined out of the box, that might not be a bad thing and it would probably clue most of them in on how to do it. But seeing the confluence of boards/groups/permissions should be marginally easier to follow - and still more compact than the current reporting methodology (which could also go bye-bye in the process)




Note that all the things I have in mind down the road about other content types can slot into what we have here with little change on a purely technical level, so this is almost entirely a UI problem. UI says it must be so, everything else will be kicked into line.

I don't know. I honestly don't know what's best out of all this. I just know that I don't like how SMF does it and by extension how we do it. I've been wary for some time of making big changes because I've been frightened of creating a worse mess than we already have. But I'm also not sure it can be *that* much worse. So, over to you. I'd love some thoughts on this, even if it's only to tell me whether you like or dislike it. Remember: you're the people who are ultimately going to be *using* it.

Of course, I'm open to other ideas. If there's any other system you've seen that you like the look of, tell me and I'll see what I can do to find out about it, including figuring out what's good about it. I'm not averse to drawing on any system out there - if the system works, I want to see it :)

1.	If allow is ticked, it's A, if deny is ticked, it's D, if neither are ticked it's X, letters for our current parlance. Oh, and you can't have both ticked at once. It actually works rather well on Windows for file permissions.
2.	And how much thinking really gets done there, eh?
3.	Firstly, I created non-board permissions using the same concept, except for 'board 0' being the board in question. Secondly, there are implicit permissions embedded into the roles, for accessing the helpdesk, being staff and being a helpdesk admin, they were ingrained into the role 'templates' that you had to build from. Kludgy but it worked, in fact in hindsight I think it worked better than I guessed.

Been thinking about this a bit lately. We have a very lovely popup that we can put things in but right now all it's used for is modal popups of things and a few subsidiary information things.

It occurs to me we could use it for more, scenario depending - for example, the login button needn't necessarily take us to a full new page, we could show the login form with the popup. Or even sending PMs directly from the display view.

At least, that's the theory. Before I tackle this, I want to get a feel for whether it's worth the effort - since there's quite a bit to unravel to make this work.

Amongst other things, the event handling on the popup would need fixing (@Nao, this might be a job for you rather than me if we go down this road - right now, forms injected into #helf aren't actually accessible amongst other things), and some of the layout would need revisiting - for example the login page would need to not output its <we:cat> header if called AJAXively but it should output it if not called AJAXively, and stuff like that. Don't even get me started how messed up the send PM thing is!

We'd also have to make sure that these pages didn't themselves have a reqWin call, of course (popup of a popup == badness in a can)

I've attached a mash-up of what it might look like.[1]

1.	The missing header issue is not just on Opera, it's all browsers. Something about the way we:cat is styled is broken but I don't know what it is off hand. But it wouldn't look right even if it weren't transparent.

https://developer.mozilla.org/en-US/docs/Security/CSP/Using_Content_Security_Policy

I already implemented X-Frame-Options for security, but CSP is much more hardcore.

The idea is that you restrict the acceptable sources for content that can be included. You can limit where scripts can be included from (e.g. forcing the scripts to run only from the main site/subdomains, or accepted third parties), plus you can limit where images can be included from.

I love the idea, but I'm wary of implementing this in core because we have acceptable third party sources. In our case, we typically want to allow main includes from the main domain, images from anywhere, movies and so on from acceptable domains (e.g. auto embedding), scripts from the main domain and specific CDNs.

This is all doable, but it makes the potential header very large (though that's possible to mitigate by being careful about what's included where, e.g. not worrying about auto-embed in places where we don't handle bbc parsing where movies would be meaningful, e.g. news) which is a per-page thing :/

But it is a useful method for mitigating injections from unexpected sources and can limit clickjacking and so on.

I did start posting this stuff in New Revs as and when it happened, but in the meantime, here's some things I've been working on.

The first is a collection of two things in the show posts/show topics area. Firstly, likes are now shown for the posts there. I may add this to other areas too, but one step at a time.

Secondly, and perhaps more interestingly, I've set it up now so that you can always see your own posts. This is a small thing but potentially important - there are a ton of posts on sm.org I can't see any more. Even though they're mine, I can't see them - because I don't have access in the relevant boards to see my own posts. So I've modified the permissions checking - if the person viewing posts is a true admin, or it's the user looking at their own posts, the gloves are off - no checking at all is performed on permissions. There's no need for it -  I see no reason why you shouldn't be able to see your own posts at all times, after all, you wrote them!

What I have done though is tweaked it - if the board is no longer visible to you, the title is not linked. Topic privacy... there's no sane way I can do that in profile view, so that will remain linked, but we'll see how big a deal that turns out to be in practice, I'm not convinced it will be a huge issue.


The second picture is much simpler; leveraging the ignore user facility, except with a handy-dandy link for it. Couldn't think of better icons so reused the thumb-up/thumb-down motif, like in Ancient Rome. Thumbs down for good bye!


I'm not yet ready to commit this, there's other stuff I want to do first, but I thought I'd share in the meantime.

For example, http://wedge.org/pub/feats/7698/calendar/ - the active members plugin has a 'more' link.

This ultimately turns into the following deferred event:

Which generates:So the weUrl part is fine, but something about the way it's passed to reqWin causes jQuery to get very upset. Since the plugin and - as far as I know, reqWin in general - hasn't changed in how it's accessed, I see no reason why this should be a problem...