I think the cause of the problem is in the function access_get_status_threshold() defined in the 'core/access_api.php' which is called from line 116 of bug_actiongroup.php.
The function checks the value of 'set_status_threshold' configuration option, but the value does not have an entry for '10' (= new) for some reason. As a result, it returns the value of 'update_bug_status_threshold' when the status of the bug is 'new'.

--
0006390 may be related to this issue.

I have tried this morning with a set of issues that were in the status of assigned and got the same error message so I don't think that the diagnosis is correct.

Hi briggsal,

Currently, bulk assigning requires an assignee to have privilege to (1) change bug status to 'assigned' or (2) update bug status if the current status is 'new'.
Assuming the assignee is a developer of your project, to give developers these privilege would solve your problem I suppose.
(1) is in the 'ACCESSS LEVELS' section in the [Manage] -> [Manage Configuration] -> [Workflow Transitions].
(2) is the 'Update issue status' in the [Manage] -> [Manage Configuration] -> [Workflow Thresholds].

--
To fix the inconsistency between bulk and single assigning, remove the line 116 and 117 of 'bug_actiongroup.php'.
$t_threshold = access_get_status_threshold( $t_assign_status, bug_get_field( $t_bug_id, 'project_id' ) );
if ( access_has_bug_level( $t_threshold , $t_bug_id, $f_assign ) &&
And insert the line below instead.
if ( access_has_bug_level( config_get( 'handle_bug_threshold' ) , $t_bug_id, $f_assign ) &&

Though I believe the change is valid, you should wait until someone in the dev team admits it.

Unfortunately as stated in the original issue - I am logged in as an administrator with all privileges - still doesn't work.

As you suggest I will wait for someone to approve those code changes.

Annoying I swiftly performed this upgrade to get the bulk update facility - which is not working still.

It looks like we are talking about different matter...

The bulk assigning feature existed at least in version 1.0.0.
I also noticed that the error message you reported is not the one raised by bulk assigning.
I guess what you are trying to do is updating 'fixed in version' or 'target version' for multiple issues, right?

If I am wrong, tell me exactly what you did step by step.

Oops...sorry, it was in the summary of the issue.
Please ignore my comments, and sorry for wasting your time.

I will look into the REAL issue, later.

At line 199 and 214 of bug_actiongroup.php, it seems to check version or something.

if ( version_exists( $t_project_id, $f_version ) ) {

But here's the actual definition of the function.

function version_exists( $p_version_id ) {
return version_cache_row( $p_version_id, false ) !== false;
}

As a result, it executes a query "SELECT * FROM mantis_project_version_table WHERE id='X'" with project id as X.

It doesn't make sense to me, but, as you can see, I am almost blind tonight.
Hope someone will cover this up.
0007852 is a duplicate.

Replacing the line 199 and 214 of bug_actiongroup.php will fix the problem.

Current:
if ( version_exists( $t_project_id, $f_version ) ) {

Replace with:
if ( version_get_id( $f_fixed_in_version, $t_project_id ) ) {

I guess it would be the intent of the original author, the error message for the validation seems to be a little bit misleading though.

yes that fixes the problem