• Jay •

You guys are awesome at alienating people who used to be ardent supporters of the product and company. Kudos!

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. :)

It's a good suggestion, tack away. :smile: 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.

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.

What's with all the hostility, dude? Yeah, I'm asking you. You're the one that brought it up. 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) 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.

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:

Alternatively, you can use this mod and not have to wonder whether somebody read it but didn't click the button.

Such as?

Or you could simply remove the bit and do warnings from the member profile page.

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.

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.

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.

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.

Bah, IMG tags are borked.

Marcher Tech, if he's taking on projects. Ditto Michael, also a busy guy though.