Found this in description of 0019271

$t_existing_bug->view_state is of type string, needs to be casted to (int).

if( $t_existing_bug->view_state !== $t_updated_bug->view_state ) {

I'm not really sure why we're using strict type checking here.

That being said, I'm not able to reproduce the error, can you please provide steps to reproduce ?

It should be obvious -- if you have no right to change view state and the view state is not changing, you'll get access denied error on the next line, but you should not.

Sorry if I'm being dense here, but what is obvious to you may not be for others.

As I said, I can't reproduce...

• logged in as user with "updater" role
• workflow threshold changed so that "updater" can't change view state
• edit a bug, make some change

I get:
260 var_dump( $t_existing_bug->view_state,$t_updated_bug->view_state);

/home/dregad/dev/mantisbt/bug_update.php:260:string '10' (length=2)
/home/dregad/dev/mantisbt/bug_update.php:260:int 10

$t_existing_bug->view_state is cast to int, 10 === 10 so the test is not call.

The type mismatch can only occur if $t_updated_bug->view_state is not int, and I don't see how that can happen since it gets initialized by gpc_get_int(), which is defaulted to $t_existing_bug->view_state (since the user can't edit it, there is no POST variable for it).

I absolutely agree with you, but I was changing the code and in my case $t_updated_bug->view_state happened to be string.
I just would not wish someone else had lost an hour again.

but I was changing the code

It would have been nice of you to mention this upfront, it would have saved me the effort to analyze and try to reproduce the issue, twice...

I changed category to code cleanup and reduced severity, as this is not an issue with MantisBT core (at least not one I can reproduce), and @badfiles admitted he was modifying the code.

Using loose comparison avoids having this kind of issues and to rely on typecasting to fix them.