Easy way to check permissions

[Wolfie]

Not IP.Board specific, but rather request for something that can be used for all apps (I'm thinking 4.0 here).

To make it simple, I'll give an example of what I'm thinking:
Let's say I want to see if someone has access to a certain gallery album or blog or download area or forum, etc. I'm thinking something like this would prove effective:

$access = $this->checkPermissions->forums('forum', '123');

$access = $this->checkPermissions->forums('topic', '456');

$access = $this->checkPermissions->gallery('image', '666');

$access = $this->checkPermissions->blog('blog', '867');

$access = $this->checkPermissions->nexus('package', '5309');

etc etc

$access would be 'false' for no access (so to that user, it doesn't exist). Otherwise, $access would be populated with some details. For a topic, list what they can do (read, reply, edit (topic vs posts), rate, report, etc). So something like, $access['canReply'] would be set if it's a topic that is open and they have access to, but if it's locked or in a forum they have no posting privileges in, it would be empty or false.

To take it a step further, if needing to check another member for some reason, include that member as the third parameter, as member_id or member_data. If 3rd is a number and 4th is true, then the 3rd value would be a member group ID instead of a user ID. If the second value is something like '*', then for certain things, it would return a nested array of data. So using it on 'forums', it would return a list of forums along with access details (if they don't have access, then it's not included at all). But to do the same thing on something like 'topics' or 'posts', it would return 'false', as in, it's not gonna even try, for obvious reasons.

I'm sure you can see the benefits to something like this. If it already exists, please don't shoot me, just tell me where the info is for it.

Oh and also, doing something like $this->checkPermissions() should return available/compatible apps.

Adding salt to the wound here... Second parameter, if an array, returns permissions for each item matching that value, ex. ( 'posts', array( 867, 5309 ) ) would return permissions for both of those posts, including which topics and which forums they come from.

On to pushing my luck... $this->getProperties->appname('item', 'value').. So like, $this->getProperties->forums('topic','666') would tell things about that topic, like who started it, when it was made, title, number of posts(replies), open/closed, number of queued/hidden posts, location (forum its in), etc etc.

Don't blog me to death, it's just an idea I had that I'm sure many developers would appreciate. I want to point out that neither idea allows changing a value, only 'reading' information. Reason is to prevent potential damage from misdesigned use to save/write data. Too easy to cause problems as it is, so just looking for a way to make data retrieval easier.

[Marcher Technologies]

http://community.invisionpower.com/resources/documentation/index.html/_/developer-resources/applications/permissions-r766
... umm, auto-load of the data really isn't sane, at least at 'default', with a flag defaulting to no perhaps, but is usually preferable to just pass it the array one already has.

[Cyrem]

Slightly offtopic, but I would like a preview mode where you can view your board as if you were a member of specific group. E.g Set yourself in a guest view mode so you can see what guests see or what they can access without logging out or changing your group.

[Rimi]

Slightly offtopic, but I would like a preview mode where you can view your board as if you were a member of specific group. E.g Set yourself in a guest view mode so you can see what guests see or what they can access without logging out or changing your group.

You can already log in to a member's account to do so. :)

[Cyrem]

You can already log in to a member's account to do so. :smile:

Yeah but... thats a tad lame. Not everyone is happy to log into people's accounts... especially when their friends think that they've logged on and it's really you. Then they contact the real person and say 'blah you ignored me at x time' and they say they weren't on. Then you get "MY ACCOUNT WAS HAX" messages... or worse, they know it's you and call out "privacy invasion".

Of course you could just make a dummy account... but... blah.

[Rimi]

Yeah but... thats a tad lame. Not everyone is happy to log into people's accounts... especially when their friends think that they've logged on and it's really you. Then they contact the real person and say 'blah you ignored me at x time' and they say they weren't on. Then you get "MY ACCOUNT WAS HAX" messages... or worse, they know it's you and call out "privacy invasion".

If you're just testing permissions though you can just use a test account...

[Cyrem]

If you're just testing permissions though you can just use a test account...

:rolleyes: see above.

[Rimi]

:rolleyes: see above.

Blah isn't much of an argument, so I'm glad you agree with me. :smile:

[m3rk0rd]

Having dummy accounts is not the ideal solution. They show up in your member lists and totals, you have to remember usernames and passwords, etc. I think the OP's request is a great idea.

[Rimi]

Having dummy accounts is not the ideal solution. They show up in your member lists and totals, you have to remember usernames and passwords, etc. I think the OP's request is a great idea.

I don't think one account will ruin any totals for you. The log in as member feature eliminates the need for usernames and passwords.

[m3rk0rd]

I don't think one account will ruin any totals for you.

If I have 10 user groups, do I want 10 dummy members? (No, I don't). And it's not just a matter of ruining totals. If you're trying to run a professional board, e.g. for a non-profit organization, it looks unprofessional to have members who are not real on your member list.

The log in as member feature eliminates the need for usernames and passwords.

Some board admins prefer not log in as their users, depending on what kind of privacy your users expect. I'm guessing you mean you could log in as your dummy account, but again see my reasoning above for why I don't want dummy accounts.

Anyway, why are you arguing? Here are two of us saying that we would value such a tool, even though we know the workarounds available to us at the moment. We want a straight-up permission-testing system.

Granted, I can see some reasons why it would be hard to implement. E.g. if I am testing the permission mask for my members, what happens when I try to submit a post? I don't know, maybe it submits the post under my admin account. Regardless, I would still like such a feature if it were possible.

[Rimi]

I'm not suggesting 10 accounts. I'm suggesting one account. You can change the user group to what you need.

I'm not trying to argue with you..I'm trying to tell you that the feature you request already exists in IPB, and in fact it exists in a much better form with more options than what you require as it allows you to see the full effect of permission changes across the entire suite.

[Wolfie]

Slightly offtopic, but I would like a preview mode where you can view your board as if you were a member of specific group. E.g Set yourself in a guest view mode so you can see what guests see or what they can access without logging out or changing your group.

I was thinking more from a development standpoint. Let's say that I want to create a hook that will generate a 'homepage' for members to use and have certain information displayed there from different apps. If I could do a very simple line of code to grab the information I want (for loading permissions that is), then I could parse that information to provide information to the visitor. I'm sure it would make things much easier within the main products too.

If I have 10 user groups, do I want 10 dummy members? (No, I don't). And it's not just a matter of ruining totals. If you're trying to run a professional board, e.g. for a non-profit organization, it looks unprofessional to have members who are not real on your member list.

Even professional boards are going to have a few 'spare' accounts used for various reasons. For example, IPS has an account used for posting news. It could also be used for checking a feature out to make sure something is working like it's supposed to, etc. So it's not unprofessional to have a reasonable number of dummy accounts, so long as it's not intended to bump up the number of members.

[Marcher Technologies]

I was thinking more from a development standpoint. Let's say that I want to create a hook that will generate a 'homepage' for members to use and have certain information displayed there from different apps. If I could do a very simple line of code to grab the information I want (for loading permissions that is), then I could parse that information to provide information to the visitor. I'm sure it would make things much easier within the main products too.

:hmm:

$whereperms = $this->registry->permissions->buildPermQuery('f');

$this->DB->build(array('from' => 'forums as f', 'where' => $whereperms));

Actually read the documentation linked please.

[Wolfie]

Actually read the documentation linked please.

Tried. Will have to take another look later. Mind is turning to mush (sleepy).

[Wolfie]

http://community.invisionpower.com/resources/documentation/index.html/_/developer-resources/applications/permissions-r766

... umm, auto-load of the data really isn't sane, at least at 'default', with a flag defaulting to no perhaps, but is usually preferable to just pass it the array one already has.

$whereperms = $this->registry->permissions->buildPermQuery('f');

$this->DB->build(array('from' => 'forums as f', 'where' => $whereperms));

Actually read the documentation linked please.

Okay looked at it and while it appears it can be useful, it doesn't quite cover what I was mentioning. Look at the first post and my examples again. Having a globalized function that would do the work would not only make it easier, but more reliable. For example, using it to check if someone has access to a particular topic, it could be used not only for displaying the topic but also for any actions being used against it. Nothing returned means a lack of access, where as something returned means the user has some sort of permissions and it would be loaded with the specific access the member has.

When you get down to it, if there are multiple locations that the same or similar code is used to accomplish the same task, specifically limiting access to a certain topic/post/blog/album/etc, then why not have it globalized in a way that only loads classes/functions as needed and follows a standardized structure?

Also, I'm thinking 4.0 here, versus the 3.x series. Let's say that IPS starts to develop a new app (IP.Games, just to make up something) and it's following this concept. You decide to develop a hook that notifies a member when their top score in a game has been beaten. Before notifying that member, make sure that they can still play that game (vs having been banned or lost access or whatever else). Hook in, use the function to check permissions and if it's false, continue on without doing anything more. Otherwise, do whatever. Better than typing in more code to determine the category the game is in and then loading in a class or two and then checking the permission. Let's say several people make hooks that each do the same thing (different functions but all loading classes and such). That's a lot of duplicate code that could be simplified.

Now let's also say that the class or one of its functions gets renamed or something else changes about it, making the code within the hooks incompatible. If it's calling on one global function that handles the task, then updating the apps won't break the hooks, unless the results are returned in a different way.

[Marcher Technologies]

There IS a reason I said it is unwise, or at minimum, SHOULD default off.
You keep thinking about 1 x item.
The last thing I would ever want is the permissions class going and getting data I already have, and in a loop no less.... sheer wastefulness, for what?

[Wolfie]

You keep thinking about 1 x item.

You obviously didn't read my first post, and what I quoted from you demonstrates it.

[Marcher Technologies]

You obviously didn't read my first post, and what I quoted from you demonstrates it.

I actually did, in full.
all of it is factually possible now, you are asking for a way to not have to know how to get said data, and much of it has 0 to do with permissions directly.
I am opposed to the idea for the simple reason that it would by very nature be used in such a manner that would be devastating to resource limits.
The permissions class does it's job quite well, but it was never meant to, nor should it ever, directly go and get data.

[MadMikeyB]

$access = $this->checkPermissions->forums('forum', '123');

$access = $this->checkPermissions->forums('topic', '456');

$access = $this->checkPermissions->gallery('image', '666');

$access = $this->checkPermissions->blog('blog', '867');

$access = $this->checkPermissions->nexus('package', '5309');

etc etc

Ahem, if I may:

http://nooooooooooooooo.com/

I admit, I've skimmed this topic, but I'm sure Marcher has pointed this out.

The way you're doing it there? You're doing a separate query per forum/content id. That's not good. Imagine those being hit over and over? Easy way to cause an SQL server crash.. :cat:

[Wolfie]

I actually did, in full.

If you had, you'd be in favor of this idea.

[color=#222222][font=Helvetica Neue', Arial, Verdana, sans-serif][size=4]The way you're doing it there? You're doing a separate query per forum/content id. That's not good. Imagine those being hit over and over? Easy way to cause an SQL server crash.. [/size][/font][/color]

You too haven't read the original post, if you had, you wouldn't have said that.

Seriously, with all due respect to the both of you, read it over carefully. If you're going to say that it requires multiple queries/etc, then read it again. Continue to read it until you see why I'm saying you haven't read it. Trust me, what you're both trying to complain about is actually covered in there. What was quoted were just EXAMPLES of using it for different apps or different ways for the same app. So obviously the list of examples are being looked at and then I'm being told "that's a lot of queries", but reading it completely, you'd know, "Oh those were just examples of different ways to use it."

[Marcher Technologies]

so we are going to go there... sigh
What valid reason is there to check all applications for a list of ones supporting permissions?
http://community.inv...ss__forums.html
http://community.inv...es__topics.html
http://community.inv...ry__albums.html
http://community.inv...ry__images.html
And WHY are you trying to stick app-specific data loaders into a globally available fully abstracted utility class?
Furthermore, why, oh why, would anyone expect or want to be able to check permissions without the data to know that already in hand?
I argue this because it completely and utterly goes against the point of abstraction in the first place to stick a lazy-loader in.... and that is what it ACTUALLY is, the idea in a nutshell, load the data so I don't have to.
While it seems a 'good' idea at first glance, it enables the coder to forget the load involved, and incur additional load without realizing it.
code example:

foreach($this->caches['rss_app_data'] as $k => $v)

{

if($this->registry->permissions->check('view', $v['group']) && is_array($v['data']) && count($v['data']))

{

....

..... last thing i need, or would EVER want, is queries being run in that loop when I have that data in a cache requiring NONE.
Using your example, a query would be run for EVERY iteration of the loop.
Say we pull the whole shebang? that's queries for data i have when I simply need to check they can x.
Your access('forums') with no id for view? is building class_forums->forum_by_id with strip_invisible=1
there is no reason for the permissions class to do this, no reason to have that data built there when it simply may never be used, and furthermore would be dangerously heavy to use the lightweight permissions class for what it would load up globally, you are frankly talking about loading in an apps data getters on-fly in a place that has no relation at all.

[Wolfie]

so we are going to go there... sigh

Yeah here we go again, you not fully reading something and insisting you did, but then something you say demonstrates that you didn't. I don't recall ever saying to use it in a loop, that's your doing, not mine. When I say that you didn't read what I've said, and to trust me on that, why can't you say, "Hmmm, if he keeps telling me that I'm saying things that show I didn't read it, then maybe I'm missing something?" I state again, trust me, you're missing something. It's like going to a sub shop, asking for a club, and then wondering why it has meat on it even though it clearly lists the ingredients right under the name and you say you've read the description

[Marcher Technologies]

you miss the *** point, it is a global class, it is not meant to load data for your laziness or lack of knowledge on how.
it IS abstracted by application, just like everything else, so if i may oh-so kindly ask, why you refuse to use the app-specific api or query for it?
Why are you asking the permissions class to do something completely ***ing unrelated to its purpose?
Self-censoring at this point for how annoyed i am here..... every line of code, every class, every method serves a purpose, and the permissions class *loading* data, is simply not it.
Every single item in your OP is already possible, as needed, with app-specific API, or/and checks with data already retrieved, with the notable exception of a list of all apps using permissions(actually, a query could nab that) but I fail to see the reason to bloat class_permissions with any of it, and it IS bloat.
The difference is that class is *global* and *always* loaded..... the phrase only get what you need, only load what you need ring a bell?

[Wolfie]

you miss the *** point, it is a global class, it is not meant to load data for your laziness or lack of knowledge on how.

it IS abstracted by application, just like everything else, so if i may oh-so kindly ask, why you refuse to use the app-specific api or query for it?

Dude, imagine my frustration when you continuously say things that tell me, without a doubt, that you didn't read the first post. Seriously, it's like a smack in the face because you think so low of my intelligence that you expect me to believe your word over your actions.