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 it today.

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 specific needs
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 to access the German, French, Spanish and Portuguese versions of this disclaimer.