CanEditRow List Plugin

[rackem]

Several months ago, I had set up two of my lists with the CanEditRow Plugin. Sometime since then they stopped working and now when I go into the options, there is a new option called "Access". What is this for? There is no tooltip to describe it and the wiki was never updated. I have experimented with different settings but can't get this plugin to work again.

Attached is a picture of my settings and here is the Eval code I was using. The idea is that if a record is "owned", then you must either be the owner or a "power" user in order to edit record.

$user =& JFactory::getUser();
$me = $user->id;
$pwr = in_array(11,$user->getAuthorisedGroups());
$own = '{mps_players___owner_raw}';

if($pwr) return TRUE;
elseif($own <> 0 AND $own <> $me) return FALSE;
else return TRUE;

This code no longer seems to be working. My list access is set to registered. So any registered user is able to edit any of the records.

 

[rackem]

*friendly bump*

 

[rob]

Access states which access level of user the plugin will be applied to. I've updated the wiki and the hover text.
However, you should just be able to use the standard list access controls I think, so set 'edit' to be that of you power user , the set 'or use field' to the 'mps_players___owner' field

 

[rackem]

OK, that makes sense, thanks for explaining.

I can't use the standard list controls unfortunately. Here is a little better description of what I am looking for: ALL registered users have edit access unless a record is "owned". If the record is "owned", then you must either be the owner or a "power" user in order to edit record.

I think there might be an issue with the PHP(eval) part of this plugin. My list edit access is set to "registered". My plugin settings are as shown in my 1st post however I put "return FALSE;" in the eval field. However, if I log in as a registered user, I still have edit access. If I understand correctly, this should not be the case?

 

[troester]

Maybe it's a type issue:
try
$own = (int)'{mps_players___owner_raw}';
var_dump($own,$me);exit;

 

[rackem]

Maybe it's a type issue:

Thanks, I tried casting both of the userid values to int as you suggested but it still doesn't work. The code did work when I set it up originally so I don't think it is a type issue.

Can you confirm that simply returning true or false in the eval box for this plugin isn't working?

 

[troester]

Yup, this commit is breaking the canEditRow

6679e6254ec3a6382934a0894d5f24bbe55d1ab4
Author: Hugh Messenger <hugh.messenger@gmail.com> 2013-03-20 04:17:55
Defensive coding in list model to do with faceted links and 'joins to
this key'.

 

[rob]

I think there was some thing not quiet right in the logic we were using with respect to your usecase. We were only really using the plugin to return if a user could edit the record. Where as you need it to return either true or false, which is a fair assumption.
So now, with the latest commit, as soon as a can edit row plugin is applied, its result (either true or false) will set the editability of the row, regardless of any other settings.
If more than one can edit plugin is used, and any one of the plugins returns false, then the row will not be editable.

 

[rackem]

Looks like this plugin is back in business! Thanks.

Now if only I could close threads...

 

[cheesegrits]

Rob pretty much explained the issue.

The problem is, I need two ways of modifying canEdit privs. I need to be able to override a standard ACL/canUserDo setting of 'no' with 'yes', and vice versa.

And as it turns out, you can't do it both ways, with one plugin. So canEditRow can ONLY override a 'no' with a 'yes'.

I'm in the process of adding a cannotEditRow plugin, which can ONLY override a "yes" (from the standard ACL/canUserDo settings) with a "no".

And I think my flailing around trying to get canEditRow to work both ways, before I realized it was impossible to do what I needed to do in just one plugin, fubar'ed the logic, which Rob then had to fix.

However, I have a lingering suspicion that the change Rob made is going to break some other people's usage of canEditRow.

-- hugh

 

[rackem]

OK, I see the distinction in usecase. Thanks for explaining the situation. The true/false approach seemed like a clean & intuitive way to go but I totally understand the concern with breaking existing setups if that wasn't how it was set up to begin with. It's no problem if you need me to switch over to a CannotEditRow plugin when it is available.

Out of curiousity, were these changes related to the hoopla with the prefilters too? When I updated, this was working but the prefilters weren't, so I ended up reverting back to my earlier version. My prefilters are more important than having this plugin working.