What you describe is the expected behavior when using the File Picker feature of the legacy attachment screens in FSM Mobile.  The file name on the device was used as the file name saved on the server.  So different mobile users that happen to attach the same file name would overwrite each other.

This was resolved with the Attachment API enhancement initially introduced in Update 6 and then enhanced in Update 11.  If you are on a version older than Update 11, to resolve this issue you will need to upgrade and use the new Task and Quote Attachment screens.

Hi @brian.gummin,

Thanks for the response.  Can you confirm please what the upgraded screen is called? i see two task attachment screens DebriefTaskAttachment and DebriefTaskAttachmentAdd. Our implementation uses DebriefTaskAttachment. What we are seeing is that sometimes the Task ID gets added to the attachment from the Mobile, but oftentimes it does not.

Regards,

Martin

Hi @MartinF,

You are using the legacy (deprecated) task attachment screens.  The new DebriefAttachmentList screen was introduced in FSM 6 Update 11.  As an Attachment API List screen, the Task ID is no longer used in the file name.  The new file naming convention for Task attachments is task_{PersonId}_{DeviceSequence}_YYYYMMDDHHMISS.  If using the new MULTI-SELECT ATTACHMENTS feature also introduced in Update 11, an additional digit is appended to the file name if the attachment is saved within the same second.

Hi @brian.gummin

Something we have experienced however is that some attachments have the task_id added to the filename and some do not. We are on IFS6u10, so what determins that behaviour on our version?

Martin

On the legacy task attachment screens, the Task ID value is part of the file name when a photo or video is attached by tapping on the Photo or Video icons.  If a file of any type is attached from the device’s memory by using the File Picker icon, the file name is exactly the file name as stored on the device.

@brian.gummin @MartinF 

Hi Brian, 

Can you please confirm as to whether this issue has been addressed post FSM6u10? We are looking at upgrading to FSM6u16, but really need to be sure that if TechA attaches a file “TestResults.Doc” and Tech B adds a file “TestResults.Doc”, that they are uniquely stored and identifyable.?

Many thanks

Angelo

Hi @AngeloPav and @MartinF 

This issue has been addressed with the new DebriefAttachmentList screen introduced in Update 11.  After your upgrade, you will need to make the new screen active in your mobile design and make the legacy screen inactive.  This is covered in the Release Notes for Update 11.  Release Notes are cumulative, so if you’ve got the Update 16 Release Notes, just search for DebriefAttachmentList.

Hi @brian.gummin 

We just upgraded to u16 and are using the new screen.  However, it only works properyl if you use it in a workflow.  Our design calls screens explicitly to give us more workflow flexibility, the problem is with this new screen is that if you call it using gotoScreen() it doesnt function at all and just shows you a text list. I will be raising this as a bug along with the fact that you cannot override the next button on this screen also.

Martin

The Attachment API screens have a new architecture.  They allow capturing attachments practically anywhere and are configurable.  These are not Standard or List screens and are not designed to work within workflow.  They are designed to be called from a button to open a list screen, or to be opened by a new attachment field control.  

Except for the new DebriefAttachmentList and QuoteAttachmentList screens added in Update 11, the Attachment API screens cannot be added to workflow.  They also cannot be opened the using goToScreen() client scripting method.  This is by design.

If you feel it essential for Task or Quote attachments to have custom workflow through scripting, then the legacy screens can still be used.  They have been deprecated and are no longer supported, but there is no intention of removing the screens.

Hi @brian.gummin

“The Attachment API screens have a new architecture.  They allow capturing attachments practically anywhere and are configurable.  These are not Standard or List screens and are not designed to work within workflow.  They are designed to be called from a button to open a list screen, or to be opened by a new attachment field control.  “

Are we talking about the screen ‘DebriefAttachmentList’? i have found it behaves in the opposite way to which you describe.  See attachment.

Please review the full UPDATE 6 MOBILE ENHANCEMENTS section of the Release Notes for information about the Attachment API feature, including the information about how client scripting is used to launch the attachment widget.

Then review the ATTACHMENTS section of the UPDATE 11 MOBILE ENHANCEMENTS in the Release Notes, where it covers the new DebriefAttachmentList and QuoteAttachmentList screens that have been added to replace the legacy Task and Quote Attachment screens.  Code was added to allow these special versions of the Attachment API List screens to be used in workflow in a way similar to the old coded screens.  However, these are special screens that you cannot goToScreen() as you could with the legacy screens.  You have to use the methods allowed by the Attachment API.

Hi @brian.gummin 

Thanks fo this, was very helpful.  I have added the script to call the Attachment API from the DebreifOverview screen, but it will not work if called from a button on another custom screen.  A message pops up saying ‘Record must bne sdaved first before attachments can be added’ I tried adding a saveChanges() in the script to open the attachment API screen, but has no effect.  I can do it by having the ‘DebriefAttachmentList’ in the workflow, btu this is not waht we want and puts me back to where i started. We want the Attachment API to be opened from two places on a button, but the script example only seems to work on the DebriefOverview screen

Martin

@brian.gummin 

“As an Attachment API List screen, the Task ID is no longer used in the file name.  The new file naming convention for Task attachments is task_{PersonId}_{DeviceSequence}_YYYYMMDDHHMISS.”

Do you know if there is an way to add the task ID or relate the attachment to thet task ID? We need to add the signature to the task attachments, But there is no way to identify the task anymore