Triggering Events After User Info Is Updated in Dashboard
Permalink
So, I want to trigger an event every time one of the sales people change a customer's attributes using the dashboard UI. This sounded like a simple task... but it has been, hardly, straightforward. There is something about the AJAX call that edits user info in a way that I am unfamiliar with.
I, first, tried extending the UserInfo object like this:
This code should do 3 things when a user's info is edited in the dashboard:
1) write 'set attribute is overridden' in the log
2) change, whatever value I put in to 'default'
3) fire the event 'on_set_attribute'
To make a long story short, I followed the chain up to the attribute key model and made the following changes to the CORE FILE (to eliminate the possibility of there being an override cache issue, etc.)
So, expected output when a user attribute (or any attribute is changed would be:
1) a line in the log saying 'this should, always, be triggered'
2) testing.txt to have an updated datestring
Neither happens when a customer's data is edited via the UI dashboard interface.
However, the following code runs, absolutely, as expected:
What's going on here? Why is AJAX not hitting the, normal, attribute setters? How is the data being updated in the database?
I, first, tried extending the UserInfo object like this:
class UserInfo extends Concrete5_Model_UserInfo { /** * Sets the attribute of a user info object to the specified value, and saves it in the database */ public function setAttribute($ak, $value) { Log::addEntry('set attribute is overridden'); $value = 'default value'; Loader::model('attribute/categories/user'); if (!is_object($ak)) { $ak = UserAttributeKey::getByHandle($ak); } $ak->setAttribute($this, $value); $this->reindex(); Events::fire('on_set_attribute', $this->ui, $ak); }
Viewing 15 lines of 16 lines. View entire code block.
This code should do 3 things when a user's info is edited in the dashboard:
1) write 'set attribute is overridden' in the log
2) change, whatever value I put in to 'default'
3) fire the event 'on_set_attribute'
To make a long story short, I followed the chain up to the attribute key model and made the following changes to the CORE FILE (to eliminate the possibility of there being an override cache issue, etc.)
/** * Sets an attribute directly with a passed value. */ public function setAttribute($obj, $value) { Log::addEntry('this should, always, be triggered'); $path = DIR_BASE; $file = fopen($path . '/WritableFolder/testing.txt', 'w+'); fwrite($file, date('l jS \of F Y h:i:s A')); fclose($file); $this->saveAttribute($obj, $value); }
So, expected output when a user attribute (or any attribute is changed would be:
1) a line in the log saying 'this should, always, be triggered'
2) testing.txt to have an updated datestring
Neither happens when a customer's data is edited via the UI dashboard interface.
However, the following code runs, absolutely, as expected:
$ui = UserInfo::getByID(1); $ui->setAttribute('admin_notes', 'test');
What's going on here? Why is AJAX not hitting the, normal, attribute setters? How is the data being updated in the database?
If you look at this pagehttp://www.concrete5.org/documentation/developers/system/events... you will see that there is an 'on_user_update' Event that you can use to have a class method called when the user is updated. I think that this would be easier than trying to modify the UserInfo Model.
That was the first way I attacked this problem, but 'on_user_update' is NOT triggered when a user is updated via the JS UI on the dashboard. It IS, however, triggered when the big blue button on the page is pressed, however.
It was deemed, for my purposes, that we couldn't rely on our sales department to hit the 'update' button to sync all their info changes with our CRM (ACT!), so I need to find some other, better, method.
I'm looking into triggering an ajax call to a tool and passing the uID before page unload, currently.
It was deemed, for my purposes, that we couldn't rely on our sales department to hit the 'update' button to sync all their info changes with our CRM (ACT!), so I need to find some other, better, method.
I'm looking into triggering an ajax call to a tool and passing the uID before page unload, currently.
