noizeg,

This is not a bug or feature request for MantisBT (you are asking for help on how to deal with problems you introduced by changing original source of MantisBT). I am therefore resolving this issue as "no change required".

Please use the forums, the mantisbt-help mailing list or IRC to get support on customizing and using MantisBT (refer to http://www.mantisbt.org/support.php for links and further details).

Hi Atrol,
was not event system introduced to allow such actions and work properly?
I can't remember that documentation speaks about any limitations on placing event_signal in source code, so why's it's not a bug then?

This bug tracker is used to track bugs in delivered code of MantisBT. It is not used as a support channel.
I don't see at the moment that your problem is caused by original MantisBT code, but by your changes of the code (correct me if I am wrong).
That's why I set to "no change required".

was not event system introduced to allow such actions
No, the event system has been introduced to write plugins without having the need of changing original MantisBT source.
You have to create an issue and send us a pull request if you want a new event in MantisBT core.
Of course, this is open source, so you can change whatever you want in your code, but you might get problems when upgrading.

so why's it's not a bug then
it's not a bug in MantisBT code. It's a bug in your code as you implemented the event in a wrong way.
Events have to be declared, that's why you get ERROR_EVENT_UNDECLARED, WARNING );
check events_inc.php for it.

I can't remember that documentation speaks about any limitations on placing event_signal in source code, so why's it's not a bug then?

Documentation explains how to declare new event, from within a plugin, to be hooked by other plugins.
Declaration and trigger for core source may differ, and is not covered by documentation. It's not difficult though, look at how other current events are defined and used.

Atrol's response is right, probably it's an error on your side, which is not the subject of a bug report.

Just to get you going, core events are declared in file events_inc.php
once there, ther are good to go...

Thanks for reply. I agree that it's not as critical as I thought.

However, I have a lot of different changes in core api, but only project_api raises UNDECLARED for custom plugin events, that's why I still think it's a design issue, won't it be logically correct to declare all plugin events at the same time as core events?

but only project_api raises UNDECLARED for custom plugin events

then the fact that it worked in other places is actually an accident...

won't it be logically correct to declare all plugin events at the same time as core events?

No... Your dependency injection is reversed. Core cannot depend on a plugin, by definition, and by design...
You have modified core source to depend on a plugin, so in a way, that makes it to be a bug in your implementation.

The existence of a way to declare events by a plugin was introduced because the main point of plugin development is to NOT modify the application source. By this principle, the only place where you can use a plugin-defined event, is from another plugin. Anything else, is unsupported

Oh, so that's how it is. Got it, thanks.

The existence of a way to declare events by a plugin was introduced because the
main point of plugin development is to NOT modify the application source. By
this principle, the only place where you can use a plugin-defined event, is
from another plugin. Anything else, is unsupported

@cproensa, I think that's a pretty good explanation, which might be worth adding to the relevant section in the docs / dev guide.