balupton wrote:

Yabba does dirty stuff like this in his plugins.

Lol, I prefer to call it imaginative coding ;)

¥

Ok then yabba, how would you imaginative coding mind go about this?

I know how to do it all off by heart except for the error if the user doesn't have valid permissions? Is their a event that i could hook in and return false that is fired of edit?

You should be able to hook into 'AdminBeforeItemEditUpdate'

¥

Ta. Will see what i can do now.

Okay so I figured out a plugin method to stop bloggers who are not the creator from actually editing a post. It won't stop them from seeing the edit button, and it won't stop them from trying to edit, but it will stop the edit from happening. Here's what I know, but it's not enough and I think it never will be given the hooks we have available.

First figure out if it's an edit or a new post with AdminDisplayItemFormFieldset. Very simply, ask it for a post_id to see if you get 0 back:

	$get_post_id = $_GET['post'];
if( $get_post_id != 0 ) {
$this->set_param( 'this_is_an_edit', 1 );
} else {
$this->set_param( 'this_is_an_edit', 0 );
}

I don't know why this is worth doing, but it's what I ended up figuring out so here it is. A smart person will probably totally ignore this bit. I wouldn't. I'd think it was important.

In AdminBeforeItemEditUpdate get the post id and the current User ID with

global $current_User;
	$post_id = $_POST['post_ID'];
	$curr_user_id = $current_User->get('ID');

Now get the creator ID (and the ID of someone the post is assigned to?) with a query to the database that returns "in the evo_posts table what is the creator_ID where the ID is post_id" as $the_creator_id. For my stupid little plugin I pulled the actual creator's ID from a table my plugin creates, so a smart person would have to figure that one out on their own.

At this point it's a no brainer to say

if( $this_is_an_edit ) {
if( $curr_user_id != $the_creator_id ) {
$this->msg( 'Your login ID does not match the ID of the creator of this post.  Therefore you die!', 'error' );
}
}

I suppose it'd be better to remember the post_id from AdminDisplayItemFormFieldset and either compare it to what you have after you try to post, or just use it as the logical question, but whatever. Trial and error is my friend, and this tried without failing. Sort of.

Obviously one would want to create an exception to the error message for The Admin or users of a certain group or users of a certain level. That too is a no-brainer, but it's all for naught if the malicious user could simply delete someone else's posts. AFAIK there is no hook for DoSomethingBeforeDeletePost. See the problem? If we're talking about bad users we need to close all doors. That means editing and deleting, and the option to 'publish now' - which I just thought of while typing.

Anyway I got as far as realizing, by accident, that I could stop a user from editing another user's post (the error message) for a plugin I'm failing miserably to produce. I began tinkering with this as a spin-off plugin, but once I realized I can't find a way to stop deleting from happening I gave up. And went back to failing miserably to create a stupid plugin I want to have. Plus it's more rewarding to get nowhere on something I want than to figure out something I don't need. I'm selfish that way eh?

No matter how hard I try to grok this plugin thing I keep bashing up against walls I can't see a way around. I miss the days when you had no choice but to hack the core :(

EdB wrote:

AFAIK there is no hook for DoSomethingBeforeDeletePost. See the problem?

There is a way to acheive this if you "bend" the rules a tad. Basically you trap the request before it gets to the "delete me" stage and turn it into an error message and kill the action.

EdB wrote:

No matter how hard I try to grok this plugin thing I keep bashing up against walls I can't see a way around. I miss the days when you had no choice but to hack the core :(

Once you get your head into plugins you'll find they're fun. What's the problems that you're having?

¥

Hey EdB, look like your having a fun fiddle.

It won't stop them from seeing the edit button, and it won't stop them from trying to edit, but it will stop the edit from happening.

That is where javascript comes in, or a dirty php trick but javascript would be better imho.

So before i go do this plugin right now, which is what i was intending to do, might as well as wether or not one of you are doing it as well? No point in two or even three of us working on the same thing.

¥åßßå wrote:

Once you get your head into plugins you'll find they're fun. What's the problems that you're having?

¥

That'd be a forum all it's own :(

Back on track, I kinda figured it's possible to get where people want to go after realizing I accidentally 'fixed' the issue where other users can edit your posts. For my purpose it's a contest plugin for a hang gliding (aka lemming) club. You pick a site and enter your distance and airtime, then the plugin does the rest. One piece of that, to me, is to make sure Billy can't alter Bobby's data. My plugin stores in a table "who, where, how far, how long", so asking my plugin "who wrote this post that's being edited" was easy. It's the delete thing (and potentially the publish_now thing) that got me stumped when I thought about the spin-off. Also for my purposes I don't have to worry about if the post is assigned to someone or not since there will be no assigning anything.

You're right though: plugins are fun to work with. Cracking open a few is what got me started through most of the 'basic' stuff on my contest thing. It's hammering out details that bogs me down in muck for hours on end. And figuring out how to do something I can't see a sample of elsewhere.

Hi balupton! No, I'm not going after this one. I need to do my contest thing before the new year and get stuck in details too easily, so if you are of a mind to get 'er done then go for it. I would LOVE to open it up and see what makes it tick. Plus I'd probably use it and leave that piece out of my little thing.

EDIT: I've already shared everything I can in this direction. I admit defeat. I'm done with it.

Try this (it doesn't hide any icons, but it should stop the actions taking place )

	function AdminAfterMenuInit()
	{
		$ctrl = param( 'ctrl', 'string' );
		$action = param( 'action', 'string' );
		if( in_array( $ctrl, array( 'editactions', 'edit' ) ) )
		{
			$post_id = param( 'post', 'integer' );
			// run your normal checks here
			if( !empty( $your_check ) )
			{
				return true;
			}
			else
			{
				global $Messages, $ctrl;
				$Messages->add( T_( 'You are not authorised to take that action' ), 'error' );
				$ctrl = 'browse';
			}
		}

¥

I'm working on the hide icons now.

Maybe someone can do the settings, so;

   if( $current_User->ID != 1 ) { // current user is NOT the admin
   if( $the_setting_use_levels && $current_User->level <= $the_setting_level ) { // current user is NOT a high enough level
   if( $the_settings_use_groups && $current_User->Group->ID != $the_setting_group ) { // current user is NOT in the admin group 

here it is, i've tested it and it seems to work as it should.

Give it a whirl, and if everything is good, i'll release it.

From just a brief glance at the code that should work (not checked the js, but assume it works).

Just a couple of things :-

You might want to add "assigned_user_ID" to your checks

	function has_perm( $Item )
	{	// Returns whether the current user has permission to edit this item
		global $current_User;
		
		return (
			/* current user is the author */
				$current_User->ID == $Item->creator_user_ID
			/* current user has permission to edit */
				||	(($min_level = $this->Settings->get('min_level')) != 0 && $current_User->level >= $min_level)
			/* user is not in the admin group */
				||	in_array($current_User->Group->ID, explode(',',$this->Settings->get('allowed_groups')))
		);
	}

Instead of $_GET, let the core do the work and use param(), it's a good habbit to get into.

		if( ($ctrl = $_GET['ctrl']) && in_array($ctrl, array('editactions', 'edit')) )
		{	// We are a edit page
		
			$action = $_GET['action'];

¥

Instead of $_GET, let the core do the work and use param(), it's a good habbit to get into.

I had param, but it totall killed some pages, like the plugins page no plugins would be visible, so i'm using get, plus get is quicker, i like get ;)

You might want to add "assigned_user_ID" to your checks

will do.

Hmm, now that is a wierd one :p

¥

Thanks dude. I have 4 versions of me on my blog so that each postable blog has a different mailto for the message form thing. So I logged out as me and in as one of my alter-egos and - sure enough - didn't see an edit button. I did see the delete link though, so I tried it on an old post (written by the real me of course). I got the popup warning me my action could not be undone and told it to continue. This is what I got:

Fatal error: Call to a member function on a non-object in /my/server/path/plugins/editpermctrl_plugin/_editpermctrl.plugin.php on line 165

I'll do some more logging in and out to test it a bit more, but I do have a question off the top of my head. What would happen if a blogger decides to disable javascript? Would they then be able to edit someone else's work? If so is there a way to say "if javascript is disabled then the edit tab (or entire back office) crashes"? In other words, can you effectively force a blogger to choose to enable javascript?

I'm thinking of the worst-case situation for this feature: where a blogger goes out of his/her way to deface or delete someone else's work.

EDIT: WHOOPSIE!
I logged back in as me and got the same error when I tried to edit a post I created. Do I need to set one of the settings fields to something? All I did was install it and see what it got me.

Oh and this is a 1.8.6 installation.

Oh totally forgot about deleting, i'll add that stuff now ;)

I'm also adding checks to see if they are a admin for that blog they have full permission.

And i will look into that error.

I'll do some more logging in and out to test it a bit more, but I do have a question off the top of my head. What would happen if a blogger decides to disable javascript? Would they then be able to edit someone else's work? If so is there a way to say "if javascript is disabled then the edit tab (or entire back office) crashes"? In other words, can you effectively force a blogger to choose to enable javascript?

Disabling javascript would simply have the buttons visible but the actions would still fail. Javascript would be enabled anyway as a lot of admin things use it i believe.

Here's the latest, changes include hiding delete and deprecate buttons and checking to see if the user is a admin for the particular blog.

There's some stuff in there for comments, but it's commented out as it's too complicated for me. So atm comments just behave normally.

Give it a go EdB, and maybe you or Yabba can have a try at finishing up the checks for comments.

Edit: If you are interested in comments, you would check the comment's Post entity with check_perm AS WELL AS the comment's Post's Post entity with check_perm and if either match (OR) then the user will be able to edit the comment.

And you will need to add finding of comments in the AdminEndHtmlHead event, on both the view post AND comment list views.

Hence it's too complicated for a person who has no fricking clue on how the core works these days.

I'll give it a test drive and see what there is to see. I hadn't thought of comments at all. Another place the malicious user could misbehave, but for now stopping actions against a post is where it's at.

Unrelated: I am now the proud owner of an authentic lava lamp, so it's very likely I'll figure out plugins and do something groovy with them :D

EdB wrote:

I am now the proud owner of an authentic lava lamp, so it's very likely I'll figure out plugins and do something groovy with them :D

What's the correlation between plugins and a lava lamp? :roll:

EdB wrote:

Unrelated: I am now the proud owner of an authentic lava lamp, so it's very likely I'll figure out plugins and do something groovy with them :D

Maybe that's the secret because I already own a genuine lava lamp :D

Balupton wrote:

Give it a go EdB, and maybe you or Yabba can have a try at finishing up the checks for comments.

I'll take a look, but you also have to consider other things when it comes to comments. For instance, do you allow editing once another comment has been made?

¥

I'll take a look, but you also have to consider other things when it comes to comments. For instance, do you allow editing once another comment has been made?

Yeh sure why not? You can edit a post once a comment is made.

That's how you end up with threads like [url=http://forums.b2evolution.net/viewtopic.php?t=10207]this[/url] ;)

¥

¥åßßå wrote:

That's how you end up with threads like [url=http://forums.b2evolution.net/viewtopic.php?t=10207]this[/url] ;)

If i'm following then your saying that this plugin will get IT'S VERY OWN HACKS TOPIC!!! How awesome is that!!! 8| :lol:

Hello folks,

Have been using b2e for a few weeks now and have
been waiting for this functionality. Would not mind to
continue playing with and using this if you wish....

Small issue though

Downloaded v 0.1.0.0 and 0.3.0.0 of the plugin and installed on b2evolution v 1.8.6, php 4.4.4, mySQL 5.0.27

In both instances I get a warning when I log out and back in:

Notice: Undefined index: ctrl in i:\kiwime\plugins\_editpermctrl.plugin.php on line 158

Warning: Cannot modify header information - headers already sent by (output started at i:\kiwime\plugins\_editpermctrl.plugin.php:158) in i:\kiwime\inc\VIEW\_menutop.php on line 38

Pat

Will look into it.

those 12 lost days lost the latest version of this plugin ;) here it is re-upped.

Balupton,

Good as gold mate. We'll be playing with this in earnest
now. Thanks for your support!

Pat

thank you for the plugin, but getting an error message using 1.9.2

ar edit_link_title = "Edit this post..."; var delete_link_title = "Delete this post"; var deprecate_link_title = "Deprecate this post!"; // var delete_link_title2 = "Delete this comment"; // var edit_link_title2 = "Edit this comment"; // var deprecate_link_title2 = "Deprecate this comment!"; var remove_links_Array = new Array();
Fatal error: Call to a member function on a non-object in C:\Documents and Settings\HP_Administrator\My Documents\websites\b2evolution\blogs\plugins\editpermctrl_plugin\_editpermctrl.plugin.php on line 148

Any ideas?

This plugin is much appreciated and works like a charm on 2 installations. But on a third I'm getting a blank screen in IE 7 and the following in FF:

var edit_link_title = "Edit this post..."; var delete_link_title = "Delete this post"; var deprecate_link_title = "Deprecate this post!"; // var delete_link_title2 = "Delete this comment"; // var edit_link_title2 = "Edit this comment"; // var deprecate_link_title2 = "Deprecate this comment!"; var remove_links_Array = new Array();

This only seems to happen when logged in as admin, not when logged in as one of the restricted members.

So what is different in the 3rd setup from the other 2? And that would be your answer...

Yabba, EdB, do you think that modding the output buffer is a better idea? I think so...

Actually I was just thinking about this again. Quite a bit, but not acting is the thing. The hooks I need to hack in are (as far as I know) going to become official hooks one day, so I should just package what I've already got and call it a HACK/PLUG-IN until such times as the hacks part becomes part of a release.

Really busy with googlemaps right now...

well the way it works right now is fine and secure, just that non-js users are inconvienced hence why it could be better modding the buffer instead of using js. But i guess if it ain't broken don't fix it is in action...