The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
#1
|
|||
|
|||
![]()
Feature Permissions and Hooks System
I am looking at implementing a generalized feature permission and hook system. (More on hooks later...) Feature permissions can be arbitrarily complex such as "Post rate requred" or "Required registration period". Feature Permissions would control access to:
(Developer note: The Feature Permissions and Hooks system itself would require only 3 or 4 small mod's, not counting the AdminCP interface and the new table: global.php, template fetcher, BBCode parser. The mod's would be small because they would consist primarily of calls to the vb_features_and_hook functions. Controlling access to non-vB pages would require admin's to use links to these pages that go through our permission checker -- a simple check and redirect script.) The permission system would allow for access control to most vBulletin features. The hook system would allow for the injection of PHP code or template code before and/or after installed scripts and templates. The hook system would accommodate many types of current mod's without any need to modify PHP scripts or templates. Access Permissions While many types of common permissions would be included, new permissions of arbitrary complexity can be defined by the Admin to grant or deny access to features. The default permissions (you can define others) that one can specify would include:
Assigning Permissions From your list of defined permissions (default or customs permissions), you can assign them to any script, script+action, template, or BB Code. Here's an example of how restricting access to the HTML BB Code might look (mockup): This example would restrict access to the HTML BBCode to the usergroups specified if their reputation is 100 or more. As mentioned earlier, you can also define your own permission tests and use them to restrict/grant access. For example you could restrict access to a feature such as "Can physically delete posts?" to only those passing your custom "Admin usergroup name" test. AdminCP mockup:
Hooks Hooks are a common technique of allowing administrators to run custom code/settings without having to modify the base system. No change is made to any vBulletin script, table, or template. Hooks might be run at the folllowing minimum number of points:
Problem: Restrict the use of custom avatars to usergroups 1, 8, and 9.The affect would be to turn off the custom avatar feature under certain conditions (i.e., for certain users) without having to modify vBulletin. Problem: For postbit_legacy, only show the avatar under certain conditions.That's About It... Imo, such a system will allow for many types of access control and customizations without having to modify scripts or templates. We can define new types of permissions and hooks, then post them here for others to use. I have not tried to be too detailed at this stage regarding the implementation details or the finer points of the AdminCP interface. Your feedback is welcome. C.C |
#2
|
|||
|
|||
![]()
To help explain the sorts of things one could do, I took a few minutes to search for questions regarding permissions/allowing/disallowing/showing/hiding Here are a few selected links to hacks, hack requests, or template customizations that could be done using only the AdminCP interface of the proposed system:
How to disallow all but ADMIN from seeing Tachy'ed posts? https://vborg.vbsupport.ru/showthread.php?t=64913 Limit Members to X posts in X hours https://vborg.vbsupport.ru/showthread.php?t=68084 Is it possible to have the user signatue to show up ONCE per page? http://www.vbulletin.com/forum/showthread.php?t=90108 Disallow guests to view threads, must register first https://vborg.vbsupport.ru/showthread.php?t=59859 Member Search turned on by usergroup https://vborg.vbsupport.ru/showthread.php?t=67178 Allow certain users to post HTML when forum has HTML off? https://vborg.vbsupport.ru/showpost....59&postcount=1 Allow Group to Read Titles / Not Content https://vborg.vbsupport.ru/showthread.php?t=60178 How do I hide certain forums on the forumhome page only? http://www.vbulletin.com/forum/showpost.php?p=646342 Disallow Mass Prune/Move for Super Mods https://vborg.vbsupport.ru/showthread.php?t=66312 |
#3
|
|||
|
|||
![]()
How would one control access to a hack that was just a mod to an existing vB script?
For example, Erwin's excellent little Microstats hack installs in function print_output in the file functions.php. It contains a hard-coded test for usergroup of 6. To change this default access, or update it later on, an administrator would have to modify functions.php. What would be easier to manage would be a Feature Permission associated with the hack. In such a case, the contributor could simply add a permission name so that administrators would only have to use the AdminCP to control access to the hack. In the case of Microstats, let's say that Erwin wanted to associate the permission name "Microstats" with the hack. His code would be delivered looking something like this: Code:
if (defined('FEATURE_PERMISSIONS')) // Feature permissions installed { require_once('./includes/functions_feature_permissions'); $grant_access = fp_access_allowed('Microstats'); } if (!isset($grant_access)) // Use default access check { $grant_access = ($bbuserinfo[usergroupid]==6) } To control access using feature permissions, the administrator would define the permissions before installing the hack. For example, here is a mockup of AdminCP values required to restrict the hack to usergroups 6-9 or supermoderators or userids 46 or 101: AdminCP:: Feature Permissions:: Define Permission Permission name: Microstats Usergroups: 6-9, supermoderators Userids: 46, 101 |
#4
|
|||
|
|||
![]()
I find it odd that this proposal was not worth commenting on whatsoever. Was is odd? Was it poorly written? Do you opine it has no merit?
There are ways to deal with the issue of customizing our boards without installing tens of hacks, code mod's, and template changes. Just mho. |
#5
|
|||
|
|||
![]()
kind of tired... breezed through the posts...
but it sounds like a great idea and it sounds like you have it pretty planned out how to do it access modifications for anything should be easy (I agree with you) I say go for it ![]() |
#6
|
|||
|
|||
![]()
How nice it would be to have the capability to run modified templates without actually modifying them.
![]() Right now, the template system has a few real drawbacks: #1 Tracking and re-mod'ing after upgrade a large headache. #2 Have to modify a template in many styles if you have styles. #3 Difficult to test a change on a live board. Using the "Template Hooks" system (described earlier in this thread), you would not actually modify templates to apply a change. No more length comparison of template code. No more revert and reinstall. The hooks are defined through AdminCP and saved in a separate table. No templates are actually modified. The proper template code is output when pages are built, but no change is made to the installed templates. I'll recap that discussion with the example I used: Code:
Problem: For postbit_legacy, only show the avatar under certain conditions. AdminCP mockup solution: Feature Permission Add Hook Hook type: Template Template name: postbit_legacy Styles: all Userid: 1 Type: before template Hook template code: if (your custom test here or a feature permission test here) { $show['avatar'] = false; } The key here is that you are not changing the base template. The modified template code is output only when the page is built. (This would require a small mod to the functions cache_templates and fetch_template, without worry of any noticeable performance penalty.) #2 problem solved: change is only used for a specific testing account. Notice in this example that I applied permissions. This makes it very easy for an admin to test a change. In this case, the change would be applied only if the running userid is '1'. You could set this to any testing user account. #3 problem solved: making change to many styles In this case, the change will be applied under all styles. One could also specify a list of one or more style id's to limit the change. Again, no change to any vB-delivered table actually takes place. Another Challenge For The System A limitation with the "Template Hook" system is that the hook can be applied only before and/or after a style. What about changes to template code in the middle of a template? Here's how that would look. In this case, we want to modify a template so that "Quote message in reply?" is checked by default when using Quick Reply. This request was raised in a recent thread here at vb.org. Code:
Problem: Apply a change within showthread_quickreply template AdminCP mockup solution: Feature Permission Add Hook Hook type: Template Template name: showthread_quickreply Styles: all Type: find/replace Find: tabindex="4" /> Change to: tabindex="4" checked="checked" /> In this case, the change applies to all styles and there are no permission limitations. Developing this template hook system would offer the admin more power and, perhaps more importantly, less maintenance work. Sure, after upgrading vB the admin would have to check that the underlying templates did not change incompatibly, but this would be a heckuva lot easier using this system than applying the changes by hand to templates. There will be cases when applying a hook would not be the right approach, but this proposal would cover the vast majority of simpler changes. Comments? |
#7
|
|||
|
|||
![]()
Sharing Hooks
To make the sharing of hooks very easy, the right approach would be to allow for one to copy and paste a hook. One could just post the text of the hook on a board, like so: Hook type: Template Template name: showthread_quickreply Styles: all Type: find/replace Find: tabindex="4" /> Change to: tabindex="4" checked="checked" /> then the reader could copy it and paste it into his Hooks AdminCP page that allows for the importing of such hook descriptions. He then clicks "Import" or whatever, and is taken to the same page he would be at if he had filled in the hook information by hand. Maybe that text is XML. Not important at this point in the discussion. An alternative would be to share XML files, but that would require many more steps for both the contributor (create file, upload to post, not visible to readers) and a few more steps for the importer/Admin. |
![]() |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
![]() |
|
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|