Easy way to check permissions

[Marcher Technologies]

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.

$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.<-- again, why not use the api if you have the tids?

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.<-- see class_forums lord help me.

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.<-- I did..... use the API to load your data, heck they all have the ability to not load inaccessible items, whereby your wish is granted.

Oh and also, doing something like $this->checkPermissions() should return available/compatible apps.<--oh lord why why? Use Case Please? (the only way one could do this realistically is a happy group clause in a query, with an unlimited query row size, or by requiring every single coreExtensions file and checking for the class existing, either sound wise?)

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.<-- how is this different than actually grabbing the posts with the api anyway?

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. <-- loading data, app abstracted, in a global class, why?

how, if i may ask, is this global auto-loader any different than using the existing api, beyond a cripeton of code loading things up in places they are not used?
Please remember, I do pull data from *every* installed/enabled app in many apps, and let me tell you, that crap is heavy(I need said data, I cannot do anything about that, but it is confined to the app). Such a thing in a core global class is simply not a good idea.

[Wolfie]

http://community.inv...ermissions-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.

To address this one again, that doesn't do what I'm suggesting, so it's irrelevant.

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.

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?

I'm thinking multiple items. Look at what I quoted.

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

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

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

Those links aren't for 4.0. As for a valid reason to check, it may seem useless, but there are some things that seem useless to be but I don't worry over it because I know that it will likely be useful to someone else. Even if it never is, at least it was available. One example I can think of is if a hook is checking for compatibility from 3rd party apps (obviously the IPS apps would be compatible, but should still be included for consistency). I suppose you think that doing a loop to check each app (thus multiple DB calls and higher resource usage) would be better?

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

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.

So you're saying that you already have a copy of 4.0 and that what I've suggested is already possible within it? Where are the docs for it?

On the references of data overload and such, I never said to load the entire database into memory. The 'checkPermissions' would call on the requested app (loading a class if necessary) and that apps class would be responsible for returning the necessary information. That information would be a skeleton and not the whole enchilada. It's possible to grab multiple pieces of information using one DB call (which you don't seem to realize) and it would be a simplified method of getting what is needed.

Sheesh.

[Marcher Technologies]

I am saying much of what you ask is possible NOW, in 3.3, but glaze right over that for this need to have the permissions class do it, whatever.

[Wolfie]

I am saying much of what you ask is possible NOW, in 3.3, but glaze right over that for this need to have the permissions class do it, whatever.

Again, I'm talking 4.0. PLEASE READ THAT PART!

[Michael]

The current way to check permissions is already easy enough, I don't see what the benefit to this would really be. You'd have to redo the entire way we handle permissions in our apps for this, for what real gain? Say you did have access to something through this function, what it returns would be unique to that app. So why does it need to be a common function if it's going to return wildly different arrays?

Each app has to handle what members can do in it based on the permissions you set up, and those permissions and the way they are handled are unique to that app. So the way you look for specific permissions for that app should be unique.

Let's take a look at your basic assumption with this method:

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.

You want to check what access? Whether they can view it? 'View' access is likely a common enough access type to check which would be common across many apps, but that doesn't necessarily mean it is the root from which all other accesses derive. For example, how would you handle a setup where someone might want to make an app whereby a certain category was accessible through a direct URL, but not visible in the regular category list? You could have a different 'root' permission value which is the one that always has to be true for someone to do anything in that category, but that would be something each app would have to define that isn't defined today. And then you'd need to not only map whatever other permissions values from the permission matrix correspond to in the resulting $access array. Plus then you'd need to do the same for any other per-category permissions which are normally handled in the category manager. If you then ever decide to add new types of category permissions, you not only have to handle them in the normal category manager you had, but then also need to ensure they are mapped into this new $access array.

This system seems like it would be a lot of work to maintain across all of the different apps, and I don't see a need for it myself.

[Wolfie]

*bangs head on wall*

I swear that when it's thought out, it would be realized that this suggestion has real merit to it. I don't get why people are trying to introduce issues to it that wouldn't exist, outside of human error or misuse of it.

Please, if you don't understand where I'm coming from and why it wouldn't cause the problems that weren't there to begin with, then either try to understand or don't reply. Such a simple but powerful idea, and people are quick to pick at it like a pack of dogs on a three legged cat.

[MadMikeyB]

Please, if you don't understand where I'm coming from and why it wouldn't cause the problems that weren't there to begin with, then either try to understand or don't reply. Such a simple but powerful idea, and people are quick to pick at it like a pack of dogs on a three legged cat.

With all due respect, I think this is the problem. No one understands where you're coming from, or why.. I don't think people are trying to pick at you, or trying to be confrontational, people are simply trying to understand why.

Michael's explanation to me made a lot of sense as to what you're trying to achieve and also why there could be potential problems.

[Michael]

Such a simple but powerful idea, and people are quick to pick at it like a pack of dogs on a three legged cat.

Using this suggestion seems simple enough, it's the work that would go into changing every app to use a different way to check permissions and putting extra steps in to maintain this new system that would be a lot of work. You're looking at the issue from the perspective of it being in place for all apps and usable in third party stuff, but neglecting to understand what work would go into getting there. The benefit of having a few simpler checks you could make don't justify the effort that would go into getting there.

Look, to implement this, you'd have to rewrite every app's /extensions/coreExtensions.php file to change from the current permission mapping settings to something new that this technique of your would call. You'd then need to rewrite large chunks of the code for each app where it did permission checks and have it use this new technique instead. And then going forward, any time you'd want to do anything like adding a new setting for a forum, or member, or download category, or anything else that uses this system, you'd have to be sure to make sure it gets fed into this new $access array.

So once you've done all that, what have you gained? You can now check permissions with a single function across apps. Which is cool, but is nothing inherently new; you always could check these permissions before, just in a different way.

[Marcher Technologies]

Since I still seem to be unable to get you on IM... why, oh why, do you expect and even push for 4.0 to break every mod/app for features that exist(all of it, loading app x data, permissions checking... and so on)?
Your argument that the documentation linked is 'invalid' because you speak of 4.0..... :hmm:
class_forums will be just as present, 'if' that application is installed.
I see no gain to be had here, just a lot of breaking everyone's work for spite.

[Wolfie]

I see no gain to be had here, just a lot of breaking everyone's work for spite.

Just to comment on this little tidbit, I wouldn't want something like this just to spite someone or a group of people. Just wanted to get that out of the way. :smile:

$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

Okay so after explaining it to MT over IM, he saw what I was aiming for and pointed out that the way I was suggesting (the above) is, to put it simply, 'fail' and nothing but trouble. Instead of it being like this:

$this->checkPermissions->appname( function, id );

what I should have used as examples would have been this:

$this->checkPermissions( appname, function, id );

The overall suggestion being that the 'checkPermissions' function would be a gateway to load/call on other apps that would have a helper class that would provide access to the various functions. Since different apps make use of different information, the code calling on the 'gateway' would be expected to know how to handle/use the data passed back to it.

So, for something like forums, perhaps an array structure like this would be passed back:
array(
'forums' => array(
'topic' => array(
456 => array(
(permissions and a few details about the topic such as the forum ID the topic is located in, but no extensive information, except possibly whatever data is already available)
),
),
),
);

Admittedly though, it probably wouldn't really be necessary to include the 'forums' and 'topic' levels, but the topic number level would be necessary because if someone sends an array of topic ID's, it would remain consistent whether it's returning one topic or several topics, regardless of one topic being requested or multiple topics. (Or posts, blog entries, gallery images, etc, whatever is being requested in regards to permissions.)

Yeah I know, could just load whatever class (or classes) I'll need, but if anything changes, be it the name of the PHP file, location, name of the class, etc, then the 3rd party mod/app/hook becomes broken, where as if a gateway function handles it, not only could it handle the work of loading a class (if needed), but also catch and even prevent errors that might otherwise generate an error that might reveal pathnames (which in turn reveals the location of the ACP).

(Now hopefully people will endorse the idea instead of trying to kill it like it's a diseased zombie trying to eat people's brains.)