Maybe it's not clear.. after these steps, Mantis crashes ALL the time.

The issue IS submited and SAVED. Then all the pages this issue appears doesn't open, just show the application error.

Seems quite a weird and unlikely scenario to have a category deleted just while a bug is being reported / edited...

But anyway, I'll have a look as time allows.

Until then, please check the manual, under troubleshooting section. You'll find a workaround for your problem.

"It's a weird and unlikely scenario to have a project deleted just while a bug is being reported / edited" aswell, but the verification is and must be made...

For security issues... It can be a problem if someone does it maliciously, on a open system (just like this one)

Ok, it's easy to solve the problem, not a BIG security risk, but it can create some inconvenience.

This scenario is just an example, without "page hacking", of how this can be reproduced.

I did not say it was an invalid issue or that it wouldn't be fixed... Just mitigating your severity of "crash"...

Ok,

I've just put a possible PR in for this issue.
https://github.com/mantisbt/mantisbt/pull/346

At the risk of starting a debate, I've set the 'severity' back to crash and a priority to 'low' and reproduciblity to 'random' for the following rationale:

We don't have a "reproducibility" that equates to "you've probably got more odds of winning the lotter then hitting this bug" aka as dregad describes, it's a pretty unlikely scenario to hit.

However, I'd agree with original reporter that the severity should be set to 'crash'. Once you do hit this scenario, you can't access the view issues page without manually editing the database. Given that my personal view is that end users should not ever have to touch the database (As they don't know our schema etc), the severity of this issue is pretty severe and warrants the status of 'crash'.

EDIT [dregad]: added link to PR

OK, so this can reduce the time window and a subset of scenarios where we can hit this crash. In other cases when a status is not found (@25) or a user no longer exists (user123 with strikethrough), we handle such case at render time. I wonder if we should actually do the same for this and have category get name return "@15" when there is no category records with id 15.

I don't have a strong opinion either way, but thought I would mention another approach that will make handling such case consistent with other scenarios.

The two approaches are not mutually exclusive actually.

@grangeway's fix is good in the sense that it provides immediate feedback on the problem to end users, and prevents them from creating invalid issues.

@vboctor's approach would fix the problem in a more generic way, which would probably avoid most occurences of crashes (error 1502) when a category is deleted, so I think it would be worth implementing as well.

end users should not ever have to touch the database

I agree. However, SQL is the only way to identify offending issues and to fix the problem. Therefore, to avoid that, we need to offer an admin page to assist in such resolution, along the lines of the troubleshooting instructions we provide in the manual [1]

EDIT: opened issue 0017700 to track this.

[1] http://mantisbt.org/docs/master-1.2.x/en/administration_guide/admin.troubleshooting.html#ADMIN.TROUBLESHOOTING.ERRORS.1502

Target version set to 1.3.x so we can pick up the other issue mentioned above.

Here is a pull requests that provides a more comprehensive fix.
https://github.com/mantisbt/mantisbt/pull/519