[kmike]

Well, I see that the handling of alerts in the code is very prone to errors. It's in fact so broken that I don't even know how to start fixing it. I just put some bandaid hacks which disabled alerts altogether for us, as we don't need them.

First of all, the "alert" hidden form field in WarnUserNoPost and WarnUser forms (warn_addwarn and warn_addwarn_nopost templates) is never initialized at all, if alerts are disabled. It is supposed to be set to $_GET['alert'], but if alerts are disabled, no &alert=... parameter is being passed in URL to the forms, so "alert" form field stays empty.

So following the chain of events, this causes $alert global variable to be always empty in Warn.php script, in DoWarnUser and DoWarnUserNoPost sections. This in turn sets "if ($alert=='No')" condition in warn_calculations() function to true ($alert is empty, so it's not equal to "No"), and the execution of the script follows completely wrong code path from here, causing that bogus "This Warning Type does not allow you to issue an Alert." error.

All checks for $alert=='No' which are sprinkled all over the code are susceptible to this, too.
Part of the problem is an initial extremely bad database design decision - instead of using integer for a flag type db fields (alert, ban, etc), these fields are strings, and defaults to NULL, so in fact they could be in the 3 states: "Yes", "No" and NULL (or empty). This causes many problems and greatly encumbers the code as checks for empty values should be added everywhere.