Compartmentalized Admin CP, Please

[• Jay •]

Since the different IPS applications are going to be treated as separate entities, I hope that behavior carries through to the Admin CP.

IP.Blogs, Gallery, and Nexus should have all settings, hooks, themes, permissions... everything related to that application under its respective heading instead of scattered throughout the IP.Board Admin CP.

As it is, for example, we had to give a blog admin access to our hooks, and add-ons area, which includes board files unrelated to blogs, and members area for the ability to edit groups which can affect more than just blog permissions.

Arguments about "Don't give anybody access to the Admin CP you don't trust" would be irrelevant, because this isn't about trust, it's about assigned duties and effective access.

[Aiwa]

I'm sure some of that can be done, but taking the group specific settings out of the group settings and moving them somewhere else would require extra overhead for permissions fetching...

Instead of moving settings around, may be request more granular control over restrictions so we can allow admins to edit member groups, but they can only edit the 'Blog' permissions of the member group...

[Lewis P]

IP.Blogs, Gallery, and Nexus should have all settings, hooks, themes, permissions... everything related to that application under its respective heading instead of scattered throughout the IP.Board Admin CP.

If that means skins, then please no. Just creates more work for skinners - and frankly, you're not just gonna skin one section, surely?

Otherwise, I agree. The problem is, of course, is that people now expect things to be more centralised. Take a look at iOS for example - all settings in the same app, not scattered between the apps.

[• Jay •]

I'm sure some of that can be done, but taking the group specific settings out of the group settings and moving them somewhere else would require extra overhead for permissions fetching...

Instead of moving settings around, may be request more granular control over restrictions so we can allow admins to edit member groups, but they can only edit the 'Blog' permissions of the member group...

For member groups, that would be nice. Or on the same note, allow them to edit the member group, but prevent access to the Blog permissions (for board admins that we wouldn't want fiddling around in blog sections).

But what about hooks and add-ons? The way they are now, they're all jumbled together in a disorganized mess that you have to scroll through to find the one you're looking for.

If they were listed under their respective application's header, it would be much more efficient.

Speaking of header, I hope this means that the other IPS applications will no longer be relegated to a drop down menu listing and are given equal prominence to IP.Board, so the admin cp is less of a single product back end.

[• Jay •]

If that means skins, then please no. Just creates more work for skinners - and frankly, you're not just gonna skin one section, surely?

Themes means themes. There are blog sites just like there are forum sites.

Otherwise, I agree. The problem is, of course, is that people now expect things to be more centralised. Take a look at iOS for example - all settings in the same app, not scattered between the apps.

I'm not asking for a different back end for each application, so the settings would still be centralized - in the same admin cp. Just under their own respective headers within that admin cp for organizational purposes.

[Ryan H.]

But hooks and add-ons aren't necessarily related to one specific application. For that matter, neither are settings. Or templates.

[Dmacleo]

this could be useful.

those mods that are not specific to one app could be done as is but ones that are specific could be under the app.

really is something that should at least be looked at.

[• Jay •]

But hooks and add-ons aren't necessarily related to one specific application. For that matter, neither are settings. Or templates.

Under the old "everything is a bastard child of our board software" doctrine, that is true. However, if all of the applications are supposed to be able to be used independent of IP.Board in the next major rewrite, that should include the hooks & add-ons.

That's not to say that a blog add-on should not interact with the board software (such as listing featured blogs on the board index), but recognize the simple fact that, although it does interact with IP.Board, it is a blog add-on because that's the application for which it was designed.

[Marcher Technologies]

Under the old "everything is a bastard child of our board software" doctrine, that is true. However, if all of the applications are supposed to be able to be used independent of IP.Board in the next major rewrite, that should include the hooks & add-ons.

That's not to say that a blog add-on should not interact with the board software (such as listing featured blogs on the board index), but recognize the simple fact that, although it does interact with IP.Board, it is a blog add-on because that's the application for which it was designed.

and a hook that affects every app designed for all?

where would you put that in your grand scheme of compartmentalizing global core functionality down to the application? :unsure:

[• Jay •]

and a hook that affects every app designed for all?

Such as?

[Dmacleo]

and a hook that affects every app designed for all?

those mods that are not specific to one app could be done as is but ones that are specific could be under the app.

not sure its even possible but that what you are meaning?

[bfarber]

Regarding the suggestion, personally I find value in having everything centralized AND being able to access everything related to an app from within the app. Certain things I don't think are necessary (why access a hook from within an app? It's rarely every useful, as you primarily want to enable/disable multiple hooks or reorder them, not just work on a single hook for a single app), but settings, group options, etc. can be useful.

Themes means themes. There are blog sites just like there are forum sites.

I'm not asking for a different back end for each application, so the settings would still be centralized - in the same admin cp. Just under their own respective headers within that admin cp for organizational purposes.

As of 3.4, you can rearrange the tabs in whatever order you want - apps are no longer necessary relegated to the other apps menu anymore.

[• Jay •]

(why access a hook from within an app? It's rarely every useful, as you primarily want to enable/disable multiple hooks or reorder them, not just work on a single hook for a single app)

To address this question, it's to allow an administrator for one application to have control over the hooks related to that application without giving them carte blanche over all hooks/add-ons.

Why should a blog admin have access to gallery add-ons?

Why should a gallery admin have access to IP.Content add-ons?

and so on...

By listing the hooks/apps in their respective sections, you could restrict permissions to those hooks/apps to the admins that are responsible for that area (and of course, to admins with no restrictions).

I can understand wanting one big master list of hooks and add-ons that you can throw a switch to turn them all off and on, but without a way to set permissions for hook types, it limits the capabilities of administrators who are only responsible for taking care of certain aspects of the community without giving them a lot more access than they need.

Thanks for considering my suggestion. :smile:

[Aiwa]

Can you give a real world example of where an admin would need access to the hooks section? What can you do there? Just edit hook points...

[Marcher Technologies]

Such as?

You are not actually asking me this, are you? :hmm: Should I make a list of the type of hook you seem to think does not exist?

Top of head immediate:

So what application would you group such hooks under?

And why would you expect the developer to fly around the applications just to manage and make hooks?

[• Jay •]

You are not actually asking me this, are you? :hmm:

What's with all the hostility, dude? Yeah, I'm asking you. You're the one that brought it up.

Should I make a list of the type of hook you seem to think does not exist?

Either quote where I said they didn't exist or stop being a confrontational ass. I asked out of curiosity.


Now to address your questions:


(MT33)Reputation Protected Applications 1.0.2 - Core Hooks, for add-ons such as you described above.
(MT)Synch Me! 1.0.3 - Under the current setup, IP.Board Hooks, since that's where the settings are located. Although that does bring up another topic, such as where notification settings should be, since IP.Board will be an optional application starting with 4.x
Sign in through Google 1.0.5.4 - Going to go out on a limb here and guess that signing in will be handled by the core in the community suite, so the Core Hooks.
Toggle Visibility [3.3/3.2 & 3.1] 1.0.3 - IP.Board Hooks, because that's what it's written for.

(Mind you, these are just suggestions, feel free to contradict/correct, but please be productive. kthx)

If you want them all on the same page, keep them all on the same page. Minutia that people use to crap on an idea is irrelevant. Look at how it can be beneficial and you might figure it out. If you think about your own questions for a second, you can probably sort an answer faster than I can, and a better one at that.

The issue is effective access not just for the switching on/off, but also for the settings of those hooks that require it.

Stop looking at the community suite as IP.Board & Co. for a second. Imagine, if you will, a site with Blogs, Gallery, IP.Content, and IP.Nexus (even IP.Downloads!), but no forums. Now let's say you wanted to assign an admin over each application, and retain root (core) admin privileges for yourself only.

Core Admin - You (no restrictions)
Blog Admin - Sam
Gallery Admin - Rachel
Content Admin - David
Nexus/Downloads Admin - Tony

Now, each of these administrators would need full access to the hooks that pertain to their respective applications. None of them need access to core hooks. So, place all the hooks on the same page, but on different tabs based on the application they support so access can be restricted to the appropriate administrator(s), and the "holy crap, turn all hooks off" switch reserved for the core admin (no restrictions)

And why would you expect the developer to fly around the applications just to manage and make hooks?

I don't really think switching tabs on a Hooks page is an arduous journey, but I'm sure you could come up with a more graceful way of handling things if you cared to.

[Marcher Technologies]

Was not trying to be hateful in any way, I actually fully misunderstood your q regarding hooks in re-reading(I honestly thought you meant an application page seperate one would have to visit).

Not at all against tabbing the hooks pane up by app, even 'Core' admin being allowed to move a hook from tab to tab(maybe add one?).... god knows my list is miles long.... my agreement is not really made or broken by the admin perms.. just my *list of doom* I have to deal with daily though.

Oh, not to tack on to your suggestion, but searching on the hooks page for x hook would be nice as well... same reasons lol.

[HeadStand]

I get the reasoning behind settings, but I'm not sure I see the logic in hooks. There isn't really anything a non-developer can do with a hook other than turn it on or off.

[• Jay •]

Can you give a real world example of where an admin would need access to the hooks section? What can you do there? Just edit hook points...

Not true at all. Many hooks have configuration settings.

Also, the administrator for an application should be able to disable hooks that start malfunctioning if the root admin isn't around.

[Marcher Technologies]

I get the reasoning behind settings, but I'm not sure I see the logic in hooks. There isn't really anything a non-developer can do with a hook other than turn it on or off.

How long is your list Headstand?

I'm into the several hundred range.

I agree personally for no more reason than it is a right royal pain to find x hook from that list, sensible grouping would go a long way in time savings.

Ctrl+f only goes so far, rarely actually helps in a list that long.

Course I have the same grief with blocks, which exceed that number, but is not relevant to the discussion at hand beyond the mention.

[• Jay •]

Oh, not to tack on to your suggestion, but searching on the hooks page for x hook would be nice as well... same reasons lol.

It's a good suggestion, tack away. :smile:

Was not trying to be hateful in any way, I actually fully misunderstood your q regarding hooks in re-reading(I honestly thought you meant an application page seperate one would have to visit).

Honestly, that was my initial thinking when I first posted the thread because I just saw a problem and wanted to suggest a fix. The talk about having to hunt down hooks made sense, so I modified my suggestion to address that issue.

[Aiwa]

You don't access the hook settings via the hook. They are wherever the developer put them in the settings. The only thing you can do in the hooks section is change the hook point or enable / disable the hook.

I get your point, and it would make things easier to find. I just don't see the need permissions wise.

[• Jay •]

You don't access the hook settings via the hook. They are wherever the developer put them in the settings. The only thing you can do in the hooks section is change the hook point or enable / disable the hook.

I get your point, and it would make things easier to find. I just don't see the need permissions wise.

You might if you were limited to administrating the blogs section and a hook was malfunctioning, causing problems for your section and the site owner was away, leaving you without a way to disable it.

Anywho, thanks for the discourse folks. :)