View Issue Details

IDProjectCategoryView StatusLast Update
0012215mantisbtbugtrackerpublic2014-02-05 07:55
Reporterdhx Assigned Todregad  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionduplicate 
Product Version1.3.0-beta.1 
Summary0012215: Write to target_version field may fail due to unhandled access check
Description

Shakra reported on IRC a regression in 1.3.x (as per 0012097) whereby this line:

$t_updated_bug->target_version = gpc_get_string( 'target_version', $t_existing_bug->target_version );

Should really be:

if( access_has_project_level( config_get( 'roadmap_update_threshold' ), $t_existing_bug->project_id ) ) {
$t_updated_bug->target_version = gpc_get_string( 'target_version', $t_existing_bug->target_version );
}

TagsNo tags attached.

Relationships

duplicate of 0016475 closeddregad bug_update.php throws access denied when updater changes status 
has duplicate 0012251 closeddhx User without roadmap update privilege cannot assign or update bugs at all 
child of 0012097 closedatrol Tracking issue for the refactoring of bug_update.php 

Activities

atrol

atrol

2013-04-27 18:48

developer   ~0036715

Removed assignment. dhx will not contribute to this issue in near future.

dregad

dregad

2013-10-12 18:57

developer   ~0038249

I believe this should be fixed by 0016475, which basically skips triggering the access denied error when we're not actually trying to change the target_version.

In a normal situation, the target_version field is not displayed for update to users who don't have access to it.

Implementing the above is probably belt and braces. Let me know what you think.

vboctor

vboctor

2013-10-17 00:09

manager   ~0038282

It seems that with the fix for 0016475 we have the right protection and we only pay the cost for the check when the value changes. I was going to say we should do the right thing and fix it, but as I looked at the diff, I think it is OK to resolve as duplicate.