Hi

I investigate the issue a little bit.

Is it possible that in the File view_all_inc.php in the Lines
106 and 195 the called function should be gpc_get_string() instead
of gpc_get_int()? At least then i become no Error Message here.

Best Regards
Frank (Opi) Weber

Hello,

I got the similar error with Mantis 1.0.8:
APPLICATION ERROR #203
A number was expected for relationship_type.

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

Full path: /data/Q03PHP/httpd-dvpt/htdocs.dvpt/core/gpc_api.php
Line: 76
Variable Value Type
p_var_name relationship_type string
p_default -1 string
t_result any string
t_val any string

args
Variable Value Type
0 relationship_type string
1 -1 string

Filename Line Function Args
/data/Q03PHP/httpd-dvpt/htdocs.dvpt/core/gpc_api.php 76 trigger_error ( '203', 256 )
/data/Q03PHP/httpd-dvpt/htdocs.dvpt/view_all_set.php 230 gpc_get_int ( 'relationship_type', -1 )

I corrected it replacing in view_all_set.php line 230 a gpc_get_int()? by a gpc_get_string() BUT I do not manage the consequence of that.

BR,
Laurent

I've uploaded a small patch that changes the behaviour of gpc_get_int. This should fix these problems.

I changed it to use sscanf so that it would still work if attempting to get an integer value from something parseable, but not containing only digits.

I can't see anything wrong with the original regex,
How exactly do you get this to occur ?

(i've never seen this myself)

PAul

grangeway, You can get it to occur in many ways, one is entering a strange id for a bug: http://www.mantisbt.org/bugs/view.php?id=826--7 . My patch basically does a best effort attempt to read a number from the beginning of $t_val, and if something's there that fits (even if something on the end isn't numeric, etc) it uses that.

Why you ask how exactly i get this to occur?
Please read the initial comment about the Issue.

But here again:
Turn on "$g_show_detailed_errors" in config_defaults_inc.php
Then follow the 3 steps to reproduce the issue:

1. log into mantis
2. click "View Issues"
3. change nothing and click "Apply Filter"

Now you should see the errormessage...

Best Regards
Frank (Opi) Weber

I think that the filter storage may be corrupted. Could you post the results from the following query?

SELECT * FROM mantis_filters_table WHERE user_id=<your userid>;

Another thought is that your browser has remembered a URL with broken information in it. Could you clear your browser cache, history, and cookies for the site?

Hmm i really don't know what you mean but i do the follow:

Log in to phpMyAdmin (2.11.4), select the correct Database,
click "SQL", enter your query (with my userid =2), click "OK",
wait for the result, click Export (in the last line of the right
side window) and on the follow page select "send" and click "OK"

The resulting file will be attached to this Issue.

I hope that is what you want. If not please let me know.
BTW: here is a patch for this issue provided by bbryant. Does
this patch not work or why it's not yet included in mantisbt?

BTW: i still run the old Mantis 1.2.0a1 Version.
BTW2: Is here a chance to get a copy of the git version
back to svn? Or at least a permalink from which a user (betetester)
can download a recent Version?

Best Regards
Frank (Opi) Weber

bbryant: I think that given your example, we are doing the right thing. There can never be a bug 826--7. Your patch doesn't change this (It just accepts the erroneous data and displays bug 827 instead).

opi: The saved filters look correct. We do may use a browser cookie to save the filter information between sessions. It is possible that this has been corrupted. Can you log out of Mantis, clear the cookies related to the site, and retest this?

opi, You can find nightly snapshots at http://git.mantisbt.org/

thraxisp thanks for the link for the nightly snapshots.
(it was a lot easier with SVN) and sorry for the late answer.

I test the issue again with the latest version and the
issue still exists. So i had again a look at this:

In view_all_inc.php (Line 164) is this call:
$f_filter = gpc_get_int( 'filter', 0);

so i add some debug output to this function and get
for the variables follow output:

$args=Array
$t_result=Apply Filter
$t_val=ApplyFilter
$p_var_name=filter

So call_user_func_array( gpc_get, $args ) return 'Apply Filter'
and that is exactly what was send for filter from the Browser:
httpdebug says: POST ...&dir_0=DESC&search=&filter=Apply+Filter

So the fault is in this line (received from the Server):
<input type="submit" name="filter" class="button-small" value="Apply Filter" />

because the Browser add the name="filter" with the value="Apply Filter"
to the POST string (&filter=Apply+Filter) which triggers the error.

The easy solution is to remove the name="filter" from the input tag,
which is full html conform.
e.g. <input type="submit" class="button-small" value="Apply Filter" />

I guess here are some other submit buttons with a not needed name in
the mantis tree. Maybe anybody can check this?

Best Regards
Frank (Opi) Weber

i forget to mention thet the page is buld in view_filters_page.php

BTW: why the action = "view_all_set.php?f=3"
i think action = "view_all_set.php?" should work too!?

Best Regards
Frank (Opi) Weber

We are resolving this issue as "no change required", because it was reported against an old version of MantisBT which is no longer supported.

We recommend that you upgrade to the latest stable version [1]; if after doing so the problem still exists, do not hesitate to reopen the issue.

[1] http://www.mantisbt.org/download.php