Exitilus, have you defined any warning types? And have you specified which one of them are non-post related?

Rgds

Aye. I created a Warning Called Bot. With 5 Warning Points (Which is the # set to Ban a User) and set Perma Ban to Yes

I set the Alert to NO. Even if I Disable Alerts. It still won't work and gives the same error message :|

I am not sure what to tell you. This error is coming from the hack files, not the ones of vB that you have edited, so it appears that either (a) something is wrong with the file or (b) something is wrong with your settings. If you want, give me access to your system and I'll try to figure it out (if it is not too well hidden).

To be on the safe side, please upgrade to the latest version.

Rgds

I am getting the exact same problem

Please be a little more specific. What problem? And which version of AWS are you currently running? If you are not running the latest, please upgrade to the latest version first and then see if the problem persists.

Rgds

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.

Yes, it would, but I need time to change the code. I wanted to bring out a release which would fix the errors the users encountered. I plan to do a code-maintenance release in the next few days, where several areas of the code will be improved. If you have any other comments, I would appreciate if you could let me know.

Rgds