Plugin to remove extended modUser

153 Posts

oori Reply #1, 16 years, 6 months ago

I have a plugin that should cleanup composites on user delete.
The extended object is defined like this:
<object class="memberUser" extends="modUser">
which has a bunch of <composite>

here’s a fragment (that doesn’t work) in the plugin (which is invoked by OnManagerDelteUser):

$id =& $scriptProperties['userid'];
$corePath = $modx->getOption('core_path', $properties, MODX_CORE_PATH);
$model_path = $corePath.'components/members/model/';
$modx->addPackage('members',$model_path);
$memberUser = $modx->getObject('memberUser', $id);
$memberUser->remove();

Here’s the error in the log:

 [2010-04-02 04:36:24] (ERROR @ /connectors/security/user.php) Could not get table name for class: modAccess
[2010-04-02 04:36:24] (ERROR @ /connectors/security/user.php) Error 42000 executing statement: 
Array
(
    [0] => 42000
    [1] => 1064
    [2] => You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS `modAccess` WHERE `modAccess`.`principal` = 93' at line 1
)

(93 = user id)

other clean-up functionalities in the plugin do work, so it is not the issue.
I guess after the user is already deleted, the plugin is invoked but it can not do the above, or can it?
can this be resolved via xpdo ? otherwise I’d resort to getTableName on each composite and sql DELETE one by one.

btw, I’m not sure abuot the error, as I get it also with the above fragment commented - although the plugin and all the other post-delete clean-ups still work (90% sure, still debugging it..)

thanks!

MODX Staff
10,725 Posts

opengeek Reply #2, 16 years, 5 months ago

What does you memberUser class look like?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

153 Posts

oori Reply #3, 16 years, 5 months ago

<object class="memberUser" extends="modUser">
	<composite alias="MemberApplication" class="memberApplication" local="id" foreign="internalKey" cardinality="one" owner="local" />
	<composite alias="MemberSkillGroups" class="memberSkillGroup" local="id" foreign="internalKey" cardinality="many" owner="local" />
	<composite alias="MemberProfessions" class="memberProfession" local="id" foreign="userId" cardinality="many" owner="local" />
	<composite alias="MemberLinks" class="memberLink" local="id" foreign="internalKey" cardinality="many" owner="local" />
	<composite alias="MemberResidencies" class="memberResidence" local="id" foreign="internalKey" cardinality="many" owner="local" />
	<composite alias="MemberContactInfos" class="memberContactInfo" local="id" foreign="internalKey" cardinality="many" owner="local" />
	<composite alias="MemberLanguages" class="memberLanguage" local="id" foreign="internalKey" cardinality="many" owner="local" />
</object>

Then, all the children objects refer back:

<aggregate alias="User" class="memberUser" local="internalKey" foreign="id" cardinality="one" owner="foreign" />

with some extra grandchild relationship within them which seems to me unrelated to the question, so i skip it here..
like MemberSkillGroups has composite to professions (member can work in a few fields (skillGroups) and have one or more professions in each field, etc..)

thanks.

MODX Staff
10,725 Posts

opengeek Reply #4, 16 years, 5 months ago

Yeah, I think this is simply an internal bug that is related to the access control systems when extending modUser, and should not be affecting anything. I’ll take a look at it as we have experienced this bug with our modCrowdUser extension.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

153 Posts

oori Reply #5, 16 years, 5 months ago

Yeah, I think this is simply an internal bug that is related to the access control systems when extending modUser, and should not be affecting anything.

Yea, I’m also not 100% sure about this error related to the plugin not working (as I said, other parts of the plugin do work and still i get this error..) - i’ll look into it further.

But, going back to the original question - $memberUser->remove() not working,
actually - should it work? as at that point the user object actually doesn’t exist anymore, getObject(’memberUser’,$id) would be too late at that stage, no?
maybe - can I use the refereed modUser (&$user) to remove the extended object (memberUser) instead somehow?
I mean, modUser doesn’t know about being extended, so by being deleted it would not remove the extended object and children.

Thanks again

153 Posts

oori Reply #6, 16 years, 5 months ago

..or I ask from a different side (unrelated to the remove), say I have this :
$userObj = $modx->getObject(’modUser’,$someId);
Now I want to get and work on it’s extended object (’memberUser’) from $userObj. can that be done in xpdo? (without doing another getObject(’memberUser’,$someId))

normally I work only with the extended object, which is naturally also a modUser. now I want to opposite.

MODX Staff
10,725 Posts

opengeek Reply #7, 16 years, 5 months ago

xPDO knows modUser is extended because you have to store the class_key in the users table. You cannot use a different table to store your extended user object; it relies on single table inheritance. Make sure your memberUser sets the class_key appropriately (I usually do this be extending the constructor and setting the class_key explicitly, e.g.

<?php
function __construct(& $xpdo) {
    parent::__construct($xpdo);
    $this->set('class_key', 'memberUser');
}
?>

So again, if memberUser extends modUser, it should a) be in the same table with the appropriate class_key and b) will be returned, as an instance of memberUser, when you call $modx->getObject(’modUser’, $someId) automatically.

So this is all that should be needed to "use" the instance of your memberClass:

<?php
$userObj = $modx->getObject('modUser', $someId);
if ($userObj instanceof memberClass && $userObj->getOne('MemberApplication')) {
    var_dump($userObj->MemberApplication->toArray());
}
?>

However, you have to make sure your memberClass is loaded available in any request by adding it to the setting extension_packages with the value

package:path

e.g.

modx.user.crowd:{core_path}model/

If existing packages are specified in extension_packages, they are separated with a semi-colon, e.g.

modx.user.foo:{core_path}model;bobs.userpkg:{core_path}components/bobs/model/

Likewise, remove() should just work on the modUser instance, regardless of what derivative class it is.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

153 Posts

oori Reply #8, 16 years, 5 months ago

Thanks for the reply.
We should have had this chat two months ago... I always used addPackage and getObject(’memberUser’) where i needed, as the info you just told exists nowhere..
Fortunetly - I mainly have a central module that takes care of this - so I am now starting to modify it.

a) be in the same table with the appropriate class_key

memberUser never had it’s own table, so that’s not a problem.
about the class_key, now I understand - this is the same idea as what modDocument is for modResource. It makes sense.

If existing packages are specified in extension_packages, they are separated with a semi-colon, e.g.

Breaking my head and then looking at modx.class.php I realized:
a. I think you mean it should be separated by comma, and not semi-colon (line 378)
b. there’s a bug in line 381 affecting windows hosts, it should be:
$exploded= explode(’:’, $extPackage,2);
otherwise addPackage doesn’t happen (don’t forget we windows people have the c:/ in the start...)
should i jira this?

My current issue I’m on is that this does not work with the *Graph methods.
I get only the modUser composite (like Profile) and not my own.

$memberSchemaDef = '{"Profile":{},"MemberApplication":{},"MemberLinks":{},"MemberResidencies":{},"MemberContactInfos":{},"MemberLanguages":{},"MemberSkillGroups":{}}';
$memberUser = $modx->getObjectGraph('modUser', $memberSchemaDef , $myQuery);

It does works fine with getObject and getOne/getMany!

The info you sent must go somewhere in the modx/xpdo docs for future extenders.
Thanks.

153 Posts

oori Reply #9, 16 years, 5 months ago

oh, and btw it resolved the original question about user remove, as it’s now automatic...
thanks.

hoo.... i like it - this change has done much more then the above... I got a very nice performance boost in the application simply by moving to the memberUser class_key (and ofcourse changing the central getUserDetails module). still not sure why - can the repeated calls to addPackage were bad?

MODX Staff
10,725 Posts

opengeek Reply #10, 16 years, 5 months ago

Quote from: oori at Apr 03, 2010, 05:32 PM

If existing packages are specified in extension_packages, they are separated with a semi-colon, e.g.

Breaking my head and then looking at modx.class.php I realized:
a. I think you mean it should be separated by comma, and not semi-colon (line 378)
b. there’s a bug in line 381 affecting windows hosts, it should be:
$exploded= explode(’:’, $extPackage,2);
otherwise addPackage doesn’t happen (don’t forget we windows people have the c:/ in the start...)
should i jira this?

I tried to forget you windows people, but alas, you reminded me. tongue

Please enter a ticket; I’ll have to modify this code to handle such, but not sure adding the limit of 2 will do it if you have multiple extension packages. Regardless, we can sort it out.

Quote from: oori at Apr 03, 2010, 05:32 PM

My current issue I’m on is that this does not work with the *Graph methods.
I get only the modUser composite (like Profile) and not my own.
$memberSchemaDef = '{"Profile":{},"MemberApplication":{},"MemberLinks":{},"MemberResidencies":{},"MemberContactInfos":{},"MemberLanguages":{},"MemberSkillGroups":{}}';
$memberUser = $modx->getObjectGraph('modUser', $memberSchemaDef , $myQuery);

What does $myQuery look like?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek