githubbob42 / mingle2github2

0 stars 1 forks source link

Sync Upload error for Geolocation field on ticket item after generating a validation error #5514

Open githubbob42 opened 5 years ago

githubbob42 commented 5 years ago

Mingle Card: 5875 Steps to Reproduce

| | |
|-|-|
|**Version #**|4.0.1.4075|
|Hardware|tablet/ipad|
|**OS**|Android 7.0/IOS 10.3.3|
|**Browser**|Chrome/Safari|
|**Username**|pradeepfield2@six.com|
|**Password**|Use LastPass|
|ORG ID| |
|User ID| |
|RayGun Error ID| |
  1. Login to the mobile app as the field user
  2. Open a ticket (Ex: T-205)
  3. Go to ticket items and find any ticket item and open it (Ex: TI-3552)
  4. Make sure geolocation field is on the ticket page layout and has a value already filled.
  5. Change the End Date < Start date so validation error is generated
  6. Click the blue check mark on bottom right corner and click continue to leave the ticket item page
  7. Go back to the ticket item again and change the end date (this time date > start date)
  8. Sync

Expected Result

Should sync the data changes and show the updated end date for the ticket item in the backoffice

Actual Result

You get following upload error.

AL-7475

INVALID_FIELD_FOR_INSERT_UPDATE : Unable to create/update fields: Geolocation__c. Please check the security settings of this field and verify that it is read/write for your profile or permission set. : Geolocation__c

However, when you update geolocation field and/or ticket item end date without generating validation error, you don’t get this upload error.

Also double checked the field security for Geolocation__c field for field user and system admin.. they both have read/write access.

Analysis

I was able to reproduce this error on production with version 4052 and got the following upload error.

AL-7484

INSUFFICIENT_ACCESS_OR_READONLY : insufficient access rights on object id

Related Cards

5552

Steps for Creating a Defect Card

| | |
|-|-|

1

   |

Ensure the defect title and description is clear and understandable.

   |

   |

2.

   |

Ensure the following are listed on the card:

    *   Mobile or back office version.
    *   Operating system
    *   Devices
    *   Browsers
    *   Username/Password.

   |

   |

3. 

   |

Ensure there are steps to reproduce and are easy to follow.

Add screenshots as necessary for clarity

   |

   |

4. 

   |

Ensure the Expected and Actual results are listed.

   |

   |

5.

   |

Check whether the bug exists in production (Sync V4) and/or Sync V4 Beta

    *   If the bug exists in current production then select the “**Sync V4 Channel”**
    *   If the bug exists in the Beta Channel but is not in production yet, then select “**Beta Channel”**
    *   If the bug was created during current iteration then select "**Regression**”

   |

   |

Test Plan

| | |
|-|-|

1.

   |

Ensure the card has enough information from the programmer before you start the verification

If not request more information

   |

   |

2.

   |

Ensure you’re able to reproduce the defect prior to verifying it

   |

   |

3.

   |

Ensure to verify if the PR is still valid by going to Github.

   |

   |

3.

   |

Create a test plan and write/update test case for the card is there is no test case in Tarantula.

   |

   |

4

   |

Test the card on all required devices and versions. If it’s a mobile card, always test the offline functionality around that defect. Attach screenshots to the card as necessary displaying the fix

   |

   |

5.

   |

Add the following test result documentations:

    *   Test Status:
    *   PR Build:
    *   Username/Password
    *   Test case name:
    *   Environment and devices tested on:
    *   Test Note.

   |

   |

6.

   |

Push the card to “Testing Complete”

   |

   |