Avoid error when editing bug with invalid version

When editing an issue having the Product Version field set to a version
number which is not defined in the issue's current project (which can
happen when the issue has been moved from another project, or a version
has been deleted from the current project), APPLICATION ERROR 1601 -
Version "" not found occurs.

The error occurs because the version field in the bug table is not
cleared when the issue is moved, so when Mantis is building the version
selection list to edit the bug, it tries to add the version defined in
it to the list, which triggers the error since that version does not
exist in the current project.

Regression caused by commit 0ffb20f8807fc600750690e201ebf5fb325e7bfc

Fixes #13938
Fix typo

Added missing '$' in front of variable name
Error introduced by a939b3e70f8082b47967d680483ef1242be0af30

Affects #13938
Fix #13937: Filter dropdown values of [any], [none], etc not saved

Damien Regad <damien.regad@merckgroup.com> and Roland Becker
<roland@atrol.de> reported an issue whereby filter dropdowns would
always select the meta filter option of [any] by default, even if the
active filter was set to another value.

The cause is incorrect logic within both the check_checked and
check_selected functions dating back to issue #7995 in 2007.
Documentation has been added inline to the code to clarify how these
functions work and the gotcha to do with == vs. === comparisons.
Add missing quotation marks around array key in tag_view_page

With maximum error handling enabled, this threw a fatal error: undefined
constant.
Fix #13937: Fix check_selected and check_checked functions

These functions were originally designed very loosely with respect to
input data types. This was causing problems in numerous areas where
strings were being compared with integers, etc.

Both functions have been modified such that an error will be generated
when the types are inconsistent. This will force developers to properly
consider the types of variables when coding with MantisBT, ensuring less
likelihood of bugs arising from "1.1"=="1.10", 0=="" comparisons, etc.

Most if not all elements of the UI with drop-down boxes, check boxes,
radio boxes and lists have been thoroughly tested after these changes.
The default state of these UI fields should once again match default
configuration values in config_inc.php, current values of the
field/filter, etc. This greatly improves the usability of the UI.
Fix #12006: Mantis Graphs - Configuration - jpgraph library path not saved
Correct display custom status in cross-project relationships

In the bug relationships section in view.php, the target bug's status
was incorrectly displayed as "@X@" (where X is the status_enum id) if
the following conditions were true:
 - the target bug is in a different project
 - it is a custom status

This commit fixes the behavior, and displays the corresponding enum
element's language string.

2 new parameters have been added to function get_enum_element(): user
and project id (defaulted to null to preserve existing behavior). These
parameters are passed on to config_get() call, allowing to specify the
context for retrieving the enum element.

The call to get_enum_element() in function relationship_get_details()
has been altered to specify the target bug's project id.

Fixes #11323
Additional fixes for display of custom status

Resolves additional display issues of custom status cross-project, similar
to what was fixed in 324dbb4681255b7a1fa4cc309ab8742f028dbf43. These
can occur when "All Projects" is selected and one or more projects have
custom statuses not defined globally, in the following pages:

 - View Issues
 - Change Log
 - Roadmap
 - Sponsorship

Affects #11323
Code cleanup and optimization

 - fix whitespace errors
 - align to coding guidelines
 - moved variable initialization out of for loop
Fix cross-project display of custom status colors

When a custom status is defined in a different project, its custom
color was not used (displayed white) in the following cases

- view issue details page, relationship
- View Issues
- My View
- Sponsorship
- Bug group action list

This ports 1.2.x commit 7dfab37c3c79328d55aa851190a86414f5664cf0,
applying the modifications made in get_status_color() to
html_get_status_css_class().

Fixes #13682
Fix cross-project display of custom resolution codes

When a custom resolution is defined in a different project, its code
was displayed as @X@ instead of the corresponding string in the
resolution column, as well as when hovering over the status in the view
issues page.

Fixes #13707
Fix cross-project display of custom severity and priority

When a custom severity is defined in a different project, its code
was displayed as @X@ instead of the corresponding string in the
severity column on the View Issues page.

The same problem applied to custom priorities

Fixes #13718
More fixes of custom enum types across projects

Fixes #13728
Fix custom enum types across projects in exports

The CSV and Excel exports, as well as printing a report to Word now
properly handle custom enums when dealing with bugs from different
projects.

Fixes #13728
Extra column in csv export when sponsorship_total >= 1000

Bug introduced by commit 169b882b97b0c6cf1babbf072ce326f0779c6c0b.

Due to the use of number_format() function with default parameters, PHP
outputs the sponsorship amount formatted with ',' as a thousands
separator, which also happens to be MantisBT's default csv separator.
Since the fields are not escaped, this causes an extra column to be
generated.

Call to number_format() was removed, as it makes more sense to output
raw data in csv exports.

Fixes #13958
Add function to handle Excel formatting of sponsorship

When exporting issues in Excel format a fatal error is thrown if the
export includes sponsorship totals. This is due to a missing
excel_format_sponsorship_total() function.

Fixes #13959
Fix bug in access_has_bug_level() for private issues

When private_bug_threshold is defined as an array instead of a single
access level, e.g. array(0=>40, 1=>70, 2=>90) to prevent developers
from seeing private bugs while granting that privilege to updaters,
access_has_bug_level() incorrectly returned true.

The consequence is that unwanted access to Private bugs was granted to
users who are allowed to view them, e.g. allowing them to delete or
perform other restricted actions.

Fixes #10124
Fix #11916: List of user profiles not sorted alphabetically

A new, optional boolean parameter $p_all_users has been added to the
profile_get_all_rows() function, to indicate whether it should return
the list of profiles for the specified user only, or include also the
profiles for all users.

This allows simplification of profile_get_all_for_user()

Conflicts:

	core/profile_api.php
Revert incorrect change to function definition

The parameters for function excel_format_custom_field() were unduly
changed, preventing proper exporting of custom field data to Excel
(custom fields would be displayed as '@@'). This is a regression from
a39a948a439974b208cf7441d003177fc9d08105. Thanks to Roland Becker for
catching this.

This commit also fixes an incorrect comment in the function header for
excel_format_plugin_column_value().

Affects #13728
Fix #13816: Update history when copying issues

Until now, copying bugs using the "View Issues" page creates wrong/
incomplete history (entries for notes reflect the id's of the original
issue's notes) and also does not record any trace that the new issue is
in fact clone of another, which can be a source of confusion.

This commit prevents the duplication of the original bug's history,
generating instead a single history entry similar to what happens when
cloning a bug with the Clone button in view.php page.

The display of history entries for cloned bugs has been slightly
modified, the bug id is now printed under the 'Field' column instead of
the 'Change' column, like entries for adding notes (as cloning s not a
change).