View Revisions: Issue #22898

Summary 0022898: Email for a new private bugnote was send to a non authorized reporter
Revision 2019-08-09 10:03 by dregad
Description

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 core/email_api.php::email_collect_recipients, 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 );
            continue;
        }

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 db_now() in core/bugnote_api.php::bugnote_add. The timestamp for the bug is created by db_now() in core/bug_api.php::bug_update_date. The function bug_update_date is called from bugnote_add.

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 core/bug_api.php::bug_update_date may be extended with a default parameter $p_last_modified = 0 and the call from bugnote_add would set the timestamp from the bugnote as a parameter to bug_update_date.

kind regards
Andreas

Revision 2019-08-09 10:01 by dregad
Description

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 );
            continue;
        }

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
Andreas

Revision 2017-05-18 06:51 by wally68
Description

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:
<pre>
...

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 );
        continue;
    }

...
</pre>

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
Andreas