I am working on improving the ability
to add users to a bug's monitoring list, letting the current user select
people from a list, instead of having to type a name in a text box (see
Your feedback and comments on this are appreciated.
To achieve the desired functionality,
I had to duplicate and slightly change some code in the print_user_option_list
function (print_api), which I think is not very good (the duplication,
I mean). So my next step would be, to modify that function to make it more
generic, so that code is easier to maintain, and can be reused.
Basically the change involves modifying
the initial list of users (built with project_get_all_user_rows), by removing
all user_id's existing in a second array (the users already monitoring
the issue in this case).
My first idea to achieve this, was to
add a new optional parameter to print_user_option_list to pass the list
to exclude. That should be fairly easy to implement, and the same function
could be used everywhere, without changing any of the existing code using
Then I saw the comment in the function
just below, print_reporter_option_list:
# @todo This function really ought to
print out all the users, I think.
# I just encountered a situation
where a project used to be public and
# was made private, so now I can't
filter on any of the reporters who
# actually reported the bugs at
the time. Maybe we could get all user
# who are listed as the reporter
in any bug? It would probably be a
# faster query actually.
And so I was wondering if a slightly
more ambitious change would not be even better, making it possible to address
the problem mentioned in this comment: separating the building of a list
of users, from the actual printing of it. This would make the code more
generic and versatile. So we would have the following function prototypes:
# a few standard build functions, reflecting
current Mantis functionality.
# additional ones could be built for
array build_users_list( $p_project_id
= null, $p_access = ANYBODY )
array build_reporters_list( $p_project_id
= null )
# the printing of the option list, would
now receive an array as parameter
void print_user_option_list ( array
$p_list, $p_selected )
I guess we could even make a fully generic
function for printing, by defining the id to use as option's value, and
use of a callback function (accepting an array element as parameter) to
define the display text, but maybe that's pushing it too far...
void print_generic_option_list( array
$p_list, $p_selected, $p_key, callback $p_print_values )
# Sample use
$t_users = build_users_list( $t_project,
config_get( 'report_bug_threshold' ) );
print_user_option_list ( $t_users );
Before I start writing code, I would
like to have your feedback and approval on my proposal. Also, the list
building functions, probably wouldn't belong in print_api anymore; any
recommendation on where to put them ? user_api ?
Thanks in advance for your replies.
This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.
Click http://disclaimer.merck.de to access the German, French, Spanish and Portuguese versions of this disclaimer.