Advanced Warning System (Beta Version)

Advanced Warning System


IF YOU ARE RUNNING vB 3.6, THERE IS A NEW THREAD FOR THIS HACK UNDER THAT VERSION. vB 3.6 USERS GO HERE:

https://vborg.vbsupport.ru/showthread.php?t=124477


This is a direct port of the Advanced Warning System, as it was implemented in vB 3.0.x. This port has all the features of AWS version 3.4.16, except the Notes.

For a complete description of AWS capabilities, please refer to the following thread:

https://vborg.vbsupport.ru/showthread.php?p=574374

The vB 3.5 compliant version of AWS includes:

1 Product XML (17 Plugins, 107 Phrases, 26 Templates, 43 Settings)
1 ACP Navigation XML
1 PHP Functions File
3 Images
2 PHP Frontend Files
1 PHP Admin CP File
1 PHP Mod CP File
3 PHP Cronjob Files

This port would not be possible, without the help of KirbyDE, to whom I am greatful. KirbyDE will also be responsible for supporting you here, with questions related to this particular release. Also, this port would not have been possible, without the help of Juan P hernandez, who offered me a free test system, in which the porting was performed.

The hack has been tested and it is believed to be bug-free, however since this is a major hack, I release it today (September 9th 2005) as beta.

I hope you all enjoy it.

History (Productversion)
3.5.b
Initial Version

3.5.b1
Fixed a typo that caused Errors in User Datamanager.
Fixed a wrong object reference in functions_warning.php

3.5.b2
Fixed a Bug that caused PHP Error Messages.
Fixed a Typo in the Install Code that causes mySQL Errors.
Updated the Template Edit instructions to be (hopefully) compatible with RC3

3.5.b3
Fixed User not showing up in automatic warning PMs
Fixed 2 missing Phrases
Fixed Hidden Warner being Used for Automatic Warnings
Fixed "View x's Warnings" Button in Usermanager not working

3.5.b4
Removed one unsued Phrase, added one missing Phrase
Fixed a Typo that caused PHP Errors when sending PMs
Fixed a Typo that caused PHP Errors upon Installation
Changed Product ID for Admin CP Navigation XML from vbulletin to aws, so it won't show up any longer if AWS is uninstalled/disabled.

A bug was found which didn't allow you to delete an entered Warning Type. Bug fixed in the current distribution file.

If you found a Bug, please report it at http://bugs.kirbydemos.ath.cx

This helps to keep issues organized, which can't be guaranteed if it's only posted in the Thread.
Thank you.

P.S.1: After you install the hack per the instructions, please update your installation with the separate files listed. They are newer files not included in the zip.

P.S.2: If you want to use the Notes feature, as it existed in AWS 3.4.16, please install AWS per the instructions in the zip file, and THEN follow the instructions included in the warn_notes_update_instructions.txt.

IMPORTANT NOTE: Please keep in mind that this hack is not supported. What this means is that I have no obligation to support it. The reason for that, is because I have no access to a vB 3.5 system any more, so I can't work on this hack any more. Andreas (or KirbyDE) who undertook the support of this version of the AWS hack in the beginning, is obviously too busy to support it. So you are on your own, at least as far as the interaction with vB is concerned. If you have an issue with the hack files themselves, I'll do my best to solve it, but without a test environment, it is not easy. So users of vB 3.5 beware!

P.S. May 31st 2006: The zip file uploaded today, should contain all the debugging done by Delphi, so it should be fine as it is. You do not need the other files listed at the right, only the zip. Download it and follow the instructions in it, for installing the hack. I leave the other files there, just in case some one needs them, they will be deleted later.

SV1CEC

[Delphiprogrammi]

Originally Posted by sv1cec

OK, I am completely stuck here. Delphi, or whoever else can check out the admin_warn.php code for me, I need some ... support.

When viewing the Warnings Log, there are two links, one saying "Remove" and the other saying "Complete Removal". My problem is this:

The first one, when clicked, shows the next screen correctly, i.e. all the information is there. The second one, does not passes all the parameters to the next screen, it does not pass all the TYPE_STR fields. As a result, the name of the warned user, and type of warning and the parameter which shows if this warning has caused a ban or no, are not passed.

The code in these two routines (remove and completeremove) is exactly the same. The code from which the two routines are called, is also exactly the same, it's shown below:

Routine remove call:

$y="<a href='{$vbulletin->options['bburl']}/$admincpdir/admin_warn.php?act=remove&id={$warn[wid]}&userid={$warn[warned_userid_v]}&uname={$warn[warned_username_v]}&wname={$warn[warn_name]}&postid={$warn[warned_post]}&ban=$warn[caused_ban]&orderstring={$order}'>Remove</a>";

Routine completeremove call:

$cy="<a href='{$vbulletin->options['bburl']}/$admincpdir/admin_warn.php?act=completeremove&id={$warn[wid]}&userid={$warn[warned_userid_v]}&uname={$warn[warned_username_v]}&wname={$warn[warn_name]}&postid={$warn[warned_post]}&ban=$warn[caused_ban]&orderstring={$order}'>Complete Removal</a>";

The strange thing is that if you hover your cursor above the two links, you can see that the parameters are shown, in other words, they are passed.

Anyone has any ideas?????

It's not affecting the operation of the program per se, the warnings are completely removed, but I do not like it when I can't figure out what's going on and why things do not work as expected.

did notice that to verry strange.Gonna check it out.

[sv1cec]

Yes, and if you add a couple of display echos, you will see that all the numeric valiables are passed, and all the string ones are not. Why? I haven't the faintest idea.

[Delphiprogrammi]

hi,

yes true.I haven't got an idea either but it's obvious variables of type TYPE_INT are passed and TYPE_STR aren't

PHP Code:

$vbulletin->input->clean_array_gpc('g',array(
        'id' => TYPE_INT,
        'userid' => TYPE_INT,
        'uname' => TYE_STR,
        'wname' => TYPE_STR,
        'postid' => TYPE_INT,
        'orderstring' => TYPE_STR,
        'ban' => TYPE_STR,
    )); 


looks correct to me.Verry "frusterating" that one screen works fine and the other just refuses to work.the g means the type of variables $_GET that can be

• g => $_GET
• p =>$_POST
• r=>$_REQUEST,
• c=>$_COOKIE,
• s=>$_SERVER,
• e=>$_ENV,
• f=$_FILES,

maybe that got something todo with it just guessing here through

there is a problem with it if you call GettType() of those TYPE_STR variables it just returns the plain function call while TYPE_INT is properly returned

PHP Code:

echo gettype($temp_wname);
echo gettype($temp_uid); 


[Delphiprogrammi]

John,

Look at the attached screenshot...

:banana: :ermm:

if you output those variables with $_GET[name] (no quotes) it does work verry strange i'm thinking about a vbulletin bug here ?

[sv1cec]

I spend the best part of this morning, trying to figure that out. I compared the code, where the completeremove and the remove are called from. Same thing. I compared the GPC cleaning thing, I even copied parts of the code from the remove to the completeremove. Nothing!

This afternoon, I tried something, below the section of code that should affect this. Guess what? It fixed something, wname and uname are now passed, but not the parameter which shows if that warning has caused a ban.

Darn vB 3.5!!

[sv1cec]

I have to agree with you. Have a look at the attached admin_warn.php. The code for the remove and for the complete remove is the same. What I added to have the first variables shown (the ones which didn't show before), was the clean_array_gpc BELOW the form. How on earth can the code below the form, affect the code which is above the form, is totally beyond my understanding. Still, there is no way I can make the "N" (for No ban) pass!

Other members, please do not use this file. It contains debug code, which will mess up your system.

[Drewish]

The automatic warning seemed to work fine when I used the default userID(1), but when i used the one for my bot(47), it diddnt work anymore.

[sv1cec]

Originally Posted by Drewish

The automatic warning seemed to work fine when I used the default userID(1), but when i used the one for my bot(47), it diddnt work anymore.

Excuse me, but what is a bot? The automatic warner should be just another user. I hope this is what you mean. I tested that this morning and everything works fine. My warner is userid 2 and it works fine. See my previous posts on this matter, to solve a minor issue.

[Delphiprogrammi]

well,

The ban parameter is indeed not passed.A quick n dirty solution would be changing "caused_ban" to a bool and use "TYPE_BOOL" this is either true or false (0 or 1 ) and that should work i know this is a "dirty" solution but the cause of this parameter not being passed can be anywhere.admin_warn.php are 3260 rules of code so .....

again the problem is the same it works fine in remove and doesn't in completeremove

[sv1cec]

That's the worst possible solution, it will require people to alter their existing tables. Neah, I'll give it some more thought when I get some more time. In the mean time, nobody is telling me if the Automatic Warnings are working OK now.