View Issue Details

IDProjectCategoryView StatusLast Update
0022898mantisbtemailpublic2018-03-29 19:08
Reporterwally68Assigned To 
Status newResolutionopen 
Product Version2.2.1 
Target VersionFixed in Version 
Summary0022898: Email for a new private bugnote was send to a non authorized reporter

We have found a strange problem with private bug-notes:
A reporter has received a private bug note from a developer while the reporter is not authorized to see any private notes or bugs.

After some code digging, we found this in <b>core/email_api.php::email_collect_recipients</b>, around line 461:

exclude users who don't have at least viewer access to the bug,

    # or who can't see bugnotes if the last update included a bugnote
    if( !access_has_bug_level( config_get( 'view_bug_threshold', null, $t_id, $t_bug->project_id ), $p_bug_id, $t_id )
     || ( $t_bugnote_id !== 0 &&
            $t_bug_date == $t_bugnote_date && !access_has_bugnote_level( config_get( 'view_bug_threshold', null, $t_id, $t_bug->project_id ), $t_bugnote_id, $t_id ) )
    ) {
        log_event( LOG_EMAIL_RECIPIENT, 'Issue = #%d, drop @U%d (access level)', $p_bug_id, $t_id );


The recipient for a bugnote email is excluded if the bug date is equal to the bugnote date and the access level is wrong. You use the lastmod-timestamp from the bug and the bugnote to differ between a bug email and a bugnote email.

The timestamp for a bugnote is created by <b>db_now()</b> in <b>core/bugnote_api.php::bugnote_add</b>. The timestamp for the bug is created by <b>db_now()</b> in <b>core/bug_api.php::bug_update_date</b>. The function <b>bug_update_date</b> is called from <b>bugnote_add</b>.

In our opinion there is a potential gap to create two different timestamps for the bugnote and the bug especially on slow machines.

As a possible solution, function <b>core/bug_api.php::bug_update_date</b> may be extended with a default parameter <b>$p_last_modified = 0</b> and the call from <b>bugnote_add</b> would set the timestamp from the bugnote as a parameter to <b>bug_update_date</b>.

kind regards

TagsNo tags attached.


has duplicate 0023492 closedatrol Due to condition race email may be sent to reporter where it should not 




2017-05-19 04:57

reporter   ~0056905

Instead of testing the bug timestamp against the bugnote timestamp in <b>core/email_api.php::email_collect_recipients</b> the function parameter <b>$p_notify_type</b> could be tested against 'bugnote' right?



2018-02-14 15:51

reporter   ~0058870

Last edited: 2018-02-19 10:39

View 2 revisions

function bug_update_date( $p_bug_id, $p_last_modified = 0 ) {
    $t_query = 'UPDATE {bug} SET last_updated=' . db_param() . ' WHERE id=' . db_param();
    if ($p_last_modified == 0) {
        $p_last_modified = db_now()
    db_query( $t_query, array( $p_last_modified, $p_bug_id ) );

    bug_clear_cache( $p_bug_id );

    return true;

line 306:

    # update bug last updated
    if( !$p_skip_bug_update ) {
        bug_update_date( $p_bug_id, $c_last_modified );

EDIT (dregad) fix markdown



2018-02-14 15:53

reporter   ~0058871

we'll check and then I'll create a pull request



2018-02-15 02:54

reporter   ~0058873



2018-02-28 23:19

administrator   ~0059059

Do we really need to timestamp check? Should we base this on the fact that the change is about a bugnote addition and having a bugnote id?



2018-03-01 02:23

reporter   ~0059060

That's what I mean in my note 0022898:0056905. It would be much simpler to implement, right?



2018-03-29 19:08

manager   ~0059356

@wuttke what do you think?

Issue History

Date Modified Username Field Change
2017-05-18 06:51 wally68 New Issue
2017-05-19 04:57 wally68 Note Added: 0056905
2017-10-17 10:04 atrol Relationship added has duplicate 0023492
2018-02-14 15:51 wuttke Note Added: 0058870
2018-02-14 15:53 wuttke Note Added: 0058871
2018-02-15 02:54 wuttke Note Added: 0058873
2018-02-19 10:39 dregad Note Edited: 0058870 View Revisions
2018-02-28 23:19 vboctoradmin Note Added: 0059059
2018-03-01 02:23 wally68 Note Added: 0059060
2018-03-29 19:08 vboctor Note Added: 0059356