Hi Damien

From my point of view:
I also find positive the move of print_user_option_list to call into a more generic print-user-list whicc would receive an array of users (built by the current print-user... functions)
At the moment print_user_option_list accepts a parameter for acl threshold to build the list of users showed. With that change it would be easier to do custom "user list" inputs, while keeping the main printing functions inside mantis core.
For a more complex monitoring scheme, though, as your case is, i think its better to do customization through plugins. This is what i am trying to do.

Another issue which i have found on this way is that even if a user is assigned to monitor a bug, email which contains a note wont be sent to him if that user doesn't have permission to view notes for that bug.

The check is on email.api: email_collect_recipients
1) there is an event EVENT_NOTIFY_USER_INCLUDE to provide custom recipients, which is called before the recipients validation.
2) recipients are purged according to some checks, one of which is bugnote access.
3) an event EVENT_NOTIFY_USER_EXCLUDE is called for each of the remainig recipients, which a plugin would use to evaluate if that individual recipient shall be excluded

- the two event calls are not consistent, as first ask for a user list to add, and the other ask for exclusion one by one.
and more important:
- doesn't seem to allow a plugin to bypass the bugnote permission check.
previous validations are appropiate: non-existant user, valid email, etc
but a permission check should be allowed to be bypassed by customizing plugins

Damien, I am sorry to "hijack" your thread, but i think these are closely related issues

Thanks to all!

2010/11/24 <damien.regad@merckserono.net>

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 http://www.mantisbt.org/bugs/view.php?id=12557). 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 http://disclaimer.merck.de to access the German, French, Spanish and Portuguese versions of this disclaimer.
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
mantisbt-dev mailing list