Correct mass update behavior against selection

[innosys]

Hello,

Running Sugar Community 5.0c

Scenario:
Search for a bunch of contacts matching a specific criteria.
Select all the results
Mass update assign to another user.

The mass update is applied against the entire list of contacts in the database, and not the selection.

Is this the expected behavior?

If it is, how do you make mass changes against a selection of contacts?

Thanks

[andopes]

Hi, innosys

If you are able to reproduce this same issue in another installation of the SugarCRM 5.0.0c then you could submit a bug into Bug Tracker.

Cheers

[jjwdesign]

Yesterday I came across the same problem, except with Leads. One of our sales Admins was reassigning all leads from a specific user (Advanced Search for Assigned User) to another user. The first time this happend was about 3 months ago; with v5.0.0. Now that it's happend a second time with a different person (v5.0.0c), I'm a bit more concerned that this is a bug. Here are the steps that produced the problem.

Leads Reassign All Issue:

Advanced Search: User 'msmith'
Select All Records - 81
Mass Update
Assigned User: webmaster

Somehow "all" of our 4810 leads got reassigned.

Unfortunately, this is the second time this has happend to us. It's not easily reversed. Luckily I have nightly backups and only a half of a day's work was lost.

After speaking with the Sales Admin in more detail, I found out that she tends to have many tabs/windows open at one time. This got me thinking about the session variables and how she might reset the search parameters with one window, then go back to the original search window and perform the mass update. Is it possible that the session variables which determine the search could be altered by another Leads search in another window, which in turn caused the Mass Update to malfunction?

[BrianSteffens]

I can confirm this behavior for Accounts in 5.0a. It only seems to happen when using Select->All records. Select->This Page, the individual check boxes, and the covering check box above all work as expected.

I was able to write a script using the audit tables to restore the data without losing any work, but this should be fixed.

[mundadashri]

Hi,

Even I have faced this issue.
Can it be a problem with the SQL Query doing massupdate for All records ?
The Confirmation Alert also gives the proper number as in -
"Do you want to update all 81 records ?"
but the result is it updates all 4810 records.

I also do the same thing as Jeff Walters scenerio.

Sugar Team Members should take this on high priority as it is a major bug.
You also cannot undo the consequences if you do not have a backup.

Please help in solving this.

[cjohnston]

I had reported this to the bug tracker a long time ago
http://www.sugarcrm.com/crm/?option=...5-4782386e60dd

although it's status has not been change nor have I checked recently for this bug's existence in the patch releases.

Hello,

Running Sugar Community 5.0c

Scenario:
Search for a bunch of contacts matching a specific criteria.
Select all the results
Mass update assign to another user.

The mass update is applied against the entire list of contacts in the database, and not the selection.

Is this the expected behavior?

If it is, how do you make mass changes against a selection of contacts?

Thanks

[mundadashri]

Hey added a note to your bug.
Can you change the priority from Medium to High or Urgent.
It is very necessary.
I wonder why the Sugar Team Members / Engineers have not resolved it.

[nbiondi]

I have to put my vote in on this issue as it is such a seriously defect with the software. I too am confused at the seeming neglect of its resolution. I was able to force the entire mode of massupdate to the selected mode, but this only updates the 20 records on the first page...at least it doesn't do all records.

-nbiondi

[heytimc]

I have added a note requesting that this raised to **CRITICAL**. It is a serious and dangerous defect which really should hve been looked at some while back - if it were present in the Pro version I'd be pretty hacked off....

[nbiondi]

I know that the fix is scheduled for the Brazil patch, but that isn't to come out until the end of June. If we are lucky, so I propose that we try to get it fixed ahead of that schedule. This is too critical to wait. I have been troubleshooting this issue and come to some conclusions. I am close to a resolution, but am in need of some collaboration. The following is an summary of where I am at.

The issue lies directly in the handleMassUpdate() function of include/MassUpdate.php. When a user chooses 'All Records' from 'Select' popup the mode of 'entire' is set through javascript. When evaluating inside hadnleMassUpdate() 'elseif(isset($_REQUEST['entire']))' evaluates true. The next line is where the issue lies. The session is supposed to hold the value that filters the desired list from all records. This variable is used to construct a 'where' clause to be used in the query. If this value is not set or empty then it evaluates to '' which causes the query to select all records.

Here is where I am so far:

I filter the list according to a user in 'assigned to' and hit the search button. Once the list is populated I click 'Select' and choose 'All Records'. I then proceed to the 'Mass Update' panel, choose a different user for 'Assigned User:' and click the Update button. With my test code in place I see that 'entire' evaluates true, $_SESSION['export_where'] is not set thus $where = '', the query = SELECT accounts.*, users.user_name as assigned_user_name FROM accounts LEFT JOIN users ON accounts.assigned_user_id=users.id where accounts.deleted=0 and the array that holds the record ids holds all 50 ids of the 50 accounts in my accounts table.

Here is the confusing part...If I then refresh the page the outcome is different in that $_SESSION['export_where'] is now set and the query contains the 'where' clause: SELECT accounts.*, users.user_name as assigned_user_name FROM accounts LEFT JOIN users ON accounts.assigned_user_id=users.id where (((accounts.assigned_user_id like 'max_id%')) AND accounts.deleted=0) AND accounts.deleted=0

So it appears that the problem has something to do with accessing the 'export_where' value from the session.

Does anyone else have any thoughts on this?

-nbiondi