I was just looking in to removing the membergroups column in boards. One solution is to add another table. I was thinking instead of another table, a permission 'can_see' in board_permissions.
Another possible permission would be can_ignore.
At the same time, change permission to char(30) instead of a varchar(). A couple of more bytes in the database, but faster lookups.
I am interested to know what Wedge did.
I'm naturally a dick, why would I want to share what I've done with you? You've made it very clear, more importantly, that you're not really interested in what I've done, more whether it validates your ideas.
That said, I will sum up the salient points which could be found on wedge.org:
we did not go with a board permission, owing to the poor usability as discovered by http://custom.simplemachines.org/mods/index.php?mod=2309
we made it a separate table
ability to ignore a board is not a permission but it is a per-board option
changing the schema... well, there's ~400 rows in board_permissions and ~60 rows in the main permissions table
SELECT permission, LENGTH( permission ) , COUNT( * )
FROM [icode]smf_permissions[/icode]
GROUP BY permission
ORDER BY LENGTH( permission ) DESC
will tell you how long the permissions are and the number of instances... longest permission is 21 characters (27 in board permissions), shortest is 7, but there's a lot of 17 long (10-13 in board permissions), which means you're adding 12 bytes (17+1 for length -> 30 without extras for length = 12 bytes per row extra), multiplied by the number of instances (which is 1-3 in the regular permissions, but up to 16 in the board permissions, when you factor in groups x profiles).
I'd say that it's more than a couple of extra bytes, and to be honest you might find you do better simply caching it and being done with it instead... at higher end performance is typically I/O bound anyway.
What usability issues did you discover?
More importantly, why is it so hard for you to do a little work yourself?
Hint: I said there were usability issues when it was a mod, the link for which I even provided for you to save you having to spend time searching for it. I assumed you'd be smart enough to put 2 and 2 together to make 4 and read the comments in the mod's thread, but clearly I overrated your abilities. This is why I'm naturally a dick to you.
/me thinks this is a good thing to do.
I think doing that part makes sense as well
Add a privacy field instead!!! :D
(Note to devs: right now I'm in 'very narrow width' mode for this quick reply... I take it back: it doesn't just show up on new tabs, it shows up in regular browsing as well.)
Dunno, I'm not a big fan of "private topics" in "common" boards... I find it hard to always have the doubt if a topic is accessible to someone or not, etc...
Privacy is privacy (well, not that what we can provide in a php script can be called privacy anyway) and should stay in another place I think.
Privacy concerns are valid at Facebook for instance, but if you clearly indicate somewhere a list of users who can read your stuff, then it's really not a problem anymore... ^^
Yeah, but I hate when I send someone a link and he answers me: "oh I can't read it, can you sum it up or send me the content of it?".
It already happens with normal boards, only think that before do anything I should think (again) "will the one I'm sending the link to be able to open that link?" would be a pain...