Implementation of #11554 introduced a new functionality to show just status colors of current filter in legend, or even suppress the display of the legend. This makes sense on "Views Issues" page but not on "My View" page. This introduces a new parameter for html_status_legend(), allowing the caller to determine whether the legend should take the filter into consideration or not (by default, it does not and will display all valid status for the workflow). Only "My View" page uses the new parameter. Fixes #19573
The code to display the status legend did not use the same logic everywhere. We now consistently rely on binary and operator (&) throughout the code base, like the way we handle e.g. the filter. In particular, bug_group_action_print_bug_list() did not print the legend when position was STATUS_LEGEND_POSITION_BOTH. Fixes #19725
Conflicts: library/ezc/Base library/ezc/Graph
ezComponents became Zeta Components in 2010. Since 2012, they are hosted on Github (http://github.com/zetacomponents) so it makes sense to include them as submodules like we do other libraries. We currently only use the following components - Base - Graph Fixes #19688
There has not been an "official" release since 2.0.0, but it is worth updating this anyway, as the latest HEAD from the upstream repo includes several updates in the domains, including one that was used to effectively spam the MantisBT tracker.
When the installer is not able to connect to the database as admin, the DB version check fails because the version cannot be retrieved from the server. This causes display of a PHP notice. Initializing $t_version_info fixes this problem. Additionally, the test result is shown as 'BAD' in this case, which is not necessarily correct (we just don't know), so we now display 'POSSIBLE PROBLEM' instead. Fixes #19676
Since they are used only in the context of the string_process_bug_link() and string_process_bugnote_link() functions, we do not actually need to use global variables; local, static ones make more sense. - $g_string_process_bug_link_callback -> $s_bug_link_callback - $g_string_process_bugnote_link_callback -> $s_bugnote_link_callback
If the same custom field is used for filtering to a value that is not "any" and is also used for sorting, the generated query defines the same table alias twice causing a SQL error. The fix is to use different aliasing prefix for filtering vs. sorting. Fixes #19670