+13We are having some users experience an issue where FSM is syncing photos from other users to their phone.
One case had a user receive over 300 photos. There are no connections to either of these technicians from a person record or task (which is where the attachments are attached to)
this has happened to 3 users, that we know of. Has this type of error been reported before?
Best answer by Lee Pinchbeck
Hi
You may also have a duplication on another sync rule where the attachment field may have been added in. Have any of the sync rules been amended from the standard? The most likely ones would be for the task tables or request. If so, I would check them to ensure that the attachment field has not been added in. If not you will need to raise this as a case to investigate the issue as a bug, ensuring that you have provided full replication steps as well as the mobile logs.
One other thing to check would be to search the tables using the method the sync rule uses to ensure that they are 1 to 1 joins i.e. the task_attachment table is joined using the attachment_id field on attachment being equal to the attachment_id field in task_attachment. As this is an ID field it should be unique but if not it will provide useful information for a case to be logged to investigate how this occurred.
The more likely join would be the link to task_assignment_view as I believe this may retain records for persons or teams that were assigned to a task but then removed. This would result in multiple lines in task_assignment_view for each task_id based on how many previous assignees there are. This is worth checking even if you are pretty sure there were no reassignments as there may have been a system function you were unaware of that has triggered this.
Kind regards,
Lee Pinchbeck
+24Hi
I have seen a similar thing occur but with parts instead and it was caused by a sync rule not being restrictive enough.
Essentially, for that issue, the sync rule looked not only at the task but also the request that task came from and then from there to all other tasks on that request. This would then cause it to sync all parts to all tasks.
You would need to check the sync rules for the table that the photos are being sent to and ensure that this is restrictive enough to prevent other tasks or person records being included.
Maybe try reverting to the sync rule held in FSM Sync Rules which will be the out of the box version of the rule and see if this still occurs.
You could also try setting the owner field to be the Person ID to restrict this down to the current person record.
Kind regards,
Lee Pinchbeck
+13Hi
I have seen a similar thing occur but with parts instead and it was caused by a sync rule not being restrictive enough.
Essentially, for that issue, the sync rule looked not only at the task but also the request that task came from and then from there to all other tasks on that request. This would then cause it to sync all parts to all tasks.
You would need to check the sync rules for the table that the photos are being sent to and ensure that this is restrictive enough to prevent other tasks or person records being included.
Maybe try reverting to the sync rule held in FSM Sync Rules which will be the out of the box version of the rule and see if this still occurs.
You could also try setting the owner field to be the Person ID to restrict this down to the current person record.
Kind regards,
Lee Pinchbeck
This is what it shows in the app param for ATTACHMENT (which is the same as FSM rule). No changes have been made to it. We have had no issues since October 2019 so odd that its only doing this now?
<hierarchy_select>
<primary_table>task_assignment_view</primary_table>
<from>
<table>task_assignment_view</table>
<table>task_attachment</table>
<table>attachment</table>
</from>
<attrs>
<attr>task_assignment_view.person_id</attr>
</attrs>
<where>
<data_constraint>
<constraint>
<left_operand>attachment.attachment_id</left_operand>
<operator>eq</operator>
<right_operand>{ATTACHMENT_ID}</right_operand>
</constraint>
</data_constraint>
<join_constraint>
<constraint>
<left_operand>task_assignment_view.task_id</left_operand>
<operator>equi</operator>
<right_operand>task_attachment.task_id</right_operand>
</constraint>
<constraint>
<left_operand>task_attachment.attachment_id</left_operand>
<operator>equi</operator>
<right_operand>attachment.attachment_id</right_operand>
</constraint>
</join_constraint>
</where>
</hierarchy_select>
+24Hi
You may also have a duplication on another sync rule where the attachment field may have been added in. Have any of the sync rules been amended from the standard? The most likely ones would be for the task tables or request. If so, I would check them to ensure that the attachment field has not been added in. If not you will need to raise this as a case to investigate the issue as a bug, ensuring that you have provided full replication steps as well as the mobile logs.
One other thing to check would be to search the tables using the method the sync rule uses to ensure that they are 1 to 1 joins i.e. the task_attachment table is joined using the attachment_id field on attachment being equal to the attachment_id field in task_attachment. As this is an ID field it should be unique but if not it will provide useful information for a case to be logged to investigate how this occurred.
The more likely join would be the link to task_assignment_view as I believe this may retain records for persons or teams that were assigned to a task but then removed. This would result in multiple lines in task_assignment_view for each task_id based on how many previous assignees there are. This is worth checking even if you are pretty sure there were no reassignments as there may have been a system function you were unaware of that has triggered this.
Kind regards,
Lee Pinchbeck
+13Hi
You may also have a duplication on another sync rule where the attachment field may have been added in. Have any of the sync rules been amended from the standard? The most likely ones would be for the task tables or request. If so, I would check them to ensure that the attachment field has not been added in. If not you will need to raise this as a case to investigate the issue as a bug, ensuring that you have provided full replication steps as well as the mobile logs.
One other thing to check would be to search the tables using the method the sync rule uses to ensure that they are 1 to 1 joins i.e. the task_attachment table is joined using the attachment_id field on attachment being equal to the attachment_id field in task_attachment. As this is an ID field it should be unique but if not it will provide useful information for a case to be logged to investigate how this occurred.
The more likely join would be the link to task_assignment_view as I believe this may retain records for persons or teams that were assigned to a task but then removed. This would result in multiple lines in task_assignment_view for each task_id based on how many previous assignees there are. This is worth checking even if you are pretty sure there were no reassignments as there may have been a system function you were unaware of that has triggered this.
Kind regards,
Lee Pinchbeck
All rules are fine, double checked with baseline rules and they match, none modified. will have to report to IFS
thanks!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.