I *think* I was able to trace this to a plugin that I modified last week. I disabled the plugin, and was able to save the resource normally as my test user. However, then I re-enabled the plugin, and was still able to save just fine. I logged out & in again just to be sure, and could still save. These users were able to save last week, after I had updated the plugin in question. It was only over the weekend & this morning that they started to have trouble.
Aside from the obvious reason (I tweaked the plugin and the resource saving problem immediately went away), I have my reasons for suspecting this plugin. The logic I added to it last week does the following:
- Finds a particular parent resource (by calling a custom snippet)
- Checks a particular TV value of that parent resource
- Sets the TV value for the current resource to be the same as that parent's TV value.
The code I added (which I cribbed from somewhere on the forums) looks like this:
$site = $modx->runSnippet('getSite', array('pid'=>$id));
// get siteKey
$skTV = $modx->getObject('modTemplateVar', array('name'=>'sitekey'));
if ($sk = $skTV->getValue($site)) {
//set sitekey for current resource
$skTV->setValue($id, $sk);
$skTV->save();
$resource->save();
}
else {
$modx->log(modX::LOG_LEVEL_ERROR, 'groupify: did NOT find the sitekey for site #' . $site);
}
I'm wondering if there's anything in that code that requires permissions that these users don't have? What permissions are required to fire $skTV->save()?
Or else maybe I cleared something in the cache when I disabled that plugin?
☆ A M B ☆
