Magento 1.9 – Event Observer Not Working or Event Not Firing

EDIT:

You can also do the following, which I would recommend over the previous solution I posted. Mostly because it doesn't use setPost, which I would consider scary.

config.xml:

<adminhtml>
  <events>
    <sales_order_status_history_save_before>
      <observers>
        <module_status_history_save_before>
          <class>module/observer</class>
          <method>commentSaveBefore</method>
        </module_status_history_save_before>
      </observers>
    </sales_order_status_history_save_before>
  </events>
</adminhtml>

Observer.php:

public function commentSaveBefore($obs) {
    $event = $obs->getEvent();
    $status = $event->getDataObject();
    $status->setComment($status->getComment().$this->_getAppend());
}

protected function _getAppend()
{
    $admin = Mage::getSingleton('admin/session')->getUser();
    $username = $admin->getUsername();
    return " : " . $username;
}

This would accomplish the same thing, except you're intercepting the model before it gets saved, allowing you to alter the comment without having to use setPost().

Original Post: You could do the following:

config.xml:

<adminhtml>
    <events>
        <controller_action_predispatch_adminhtml_sales_order_addComment>
            <observers>
                <module_order_save_comment>
                    <class>module/observer</class>
                    <method>adminhtmlSavingOrderComment</method>
                </module_order_save_comment>
            </observers>
        </controller_action_predispatch_adminhtml_sales_order_addComment>
    </events>
</adminhtml>

Observer.php:

public function adminhtmlSavingOrderComment($obs) {
    $event = $obs->getEvent();
    $order = $event->getOrder();
    $data = Mage::app()->getRequest()->getPost('history');
    if ($data && isset($data['comment'])) {
        $data['comment'] .= $this->_getAppend();
        Mage::app()->getRequest()->setPost('history', $data);
    }
}

protected function _getAppend()
{
    $admin = Mage::getSingleton('admin/session')->getUser();
    $username = $admin->getUsername();
    return " : " . $username;
}

This should work for you.

You're not going to find a good, clear, deterministic answer here. By and large, you should dispatch events in your module where you and your users need them -- if you can't think of anywhere they might be needed, you don't need to dispatch them. Magento itself emits so many events at so many different places (controller pre/post dispatch, any crud operation, etc) that your module will already dispatch a number of useful events without you doing anything.

Since that's unsatisfying, you'd want your module to dispatch an event when there's some action your module takes that your users might want to add items to, delete items from, change, or take a separate action independent of the original action. For example -- Magento has a visitor_init event that's not part of its standard suite of auto generated events. This event allows programmers to modify the visitor objet before Magento logs data. These was no way the original module developers to deterministically know this was where an event needed to be added -- it likely came from feature requests and/or interviews with system users. Know what your users want, and if its not possible/practical to build out a UI/UX to let them do it via the admin, add an event hook so another programmer can do it for them.

Less sexily, adding events can also be a cheap way to enable developers (either your users, or even your team) to add some functionality into a gnarly bit of code that everyone's afraid to touch. Plop your dispatchEvent call in the middle of the code, hook into it, and you can add your functionality without disturbing the code in the original scope. [Editor: Also you should refactor that awful code at some point]

Performance wise, adding an event to dispatch will depend on where you add it. When you call dispatch event, Magento needs to make a few extra PHP calls, query the configuration for any configured observers, and then call the observers. Done once, this is a cheap addition in the scope of a standard Magento dispatch. However, done repeatedly, (say, before every block render) this may add up. There's no good rule of thumb here -- as always the right answer is profile.

Finally, w/r/t Magento 2, it's still too early to say. All of the above still applies -- however the plugin system adds a few wrinkles. Plugins are, from one point of view, a way to create event like behavior for any public method call in Magento. In theory, if you're designing your classes correctly, you shouldn't ever need an event. However, in practice, dropping an event into a bit of protected or private method code will be a tempting solution for Magento developers when the alternative is a long refactoring process. Also, creating a specifically named event can often create a friendlier experience for developers using your module.

Hope that helps!