Opening Attachments Discussion

I am not looking to start any dumpster fires here. Just trying to get a better understanding of some loss of functionality.

I just learned that we will not be able to open attachments in the Kinetic UI like we do in Classic UI. We have ECM and just need to double click an attachment and it opens up in the Classic UI. In Kinetic UI we have to click on the document number which opens a slide out and then we need to download the file and then open the downloaded attachment.

To me, this seems like a HUGE loss of functionality, but I have not seen that much chatter on the site. Am I the only one who thinks this is a big deal?

Olga explained to me yesterday why the functionality is gone, but I do not know enough to really understand it. Browsers do not support the functionality. But why, is it a security concern or something else? Since this is not supported in browsers, should this be something installed locally? I know they are moving away from client installs, but (in general) is something like this possible? I can even think of a slight tweak they could make in the application to make it easier to interface with. If they just put the download button in the grid, it would be a huge improvement. No more clicking the number to open a slider to download and then closing the slider to then open up the next document.

I’m not looking to die on this hill, I guess I am just surprised that I did not see this earlier. I know Hannah and other people have worked on creating something to replicate the functionality, but I think this is more of Epicor’s problem than the users.

Any who, thanks for reading my rant! I feel better already. Please feel free to add any insightful comments! No :candle: allowed near the dumpster.

2 Likes

I agree John - more clicks are always a problem - and using http file transfer seems like going backwards when ECM documents are available via URL. Either way, a big loss in functionality for all of us who have both products and were hoping to be fully browser based this year.

I’ve been giving it some thought since your post yesterday and I’m wondering why some code could not be altered and present the direct URL to the attachments/document based on the code I dug up ECM Direct links to documents (not forms). If these URLs were active in the browser/Kinetic UI it would work without having to download anything. I’ve not fully thought this out as there is still the issue of authentication into ECM and the licensing/access issue.

1 Like

not be able to open attachments in the Kinetic UI like we do in Classic UI
This is a Huge Issue for us also.

So much to this topic, so thanks for bringing it up. First a little history…

The base level of Document Management has two sources: Links and Uploads. Links were just that, links to a file location. For most customers at this time, they were File paths like \server\share\filename or maybe a drive letter - including c:. This had obvious problems if the server changed names or people used different drive letters.

The Uploads stored files at the application server is a folder structure that looked like:

…\company\table_attached_to\Filename

The bad part about this is everybody on the network had read and write access to all of these files.

image

When SharePoint came along, the folder structure remained the same. A Document Library was created with the same folder structure. Everything was in one Document Type (category held the Epicor Document Type if I recall). I believe at this time, Epicor also added the Metadata capability. When a column was added to the metadata, Epicor would add it to the SharePoint Library. Since it was one Document Type for the whole library, every file got the column added. The downside of metadata is that only a field in the attached record could automatically be assigned to the metadata. If adding a document to a ship to, there was no way to pull in data from the bill to record.

When DocStar/ECM was added, everything remained the same except Document Types map directly to ECM Document types, which was a huge improvement for security since one can add ECM Security Groups to Document Types.

I assume that for DropBox (and Box?), the folder structure has remained the same. Could be wrong…

Trouble started brewing with the advent of SaaS. Rightly, Epicor isn’t going to give read/write access to folders on the application server. File upload is DOA in SaaS but Link remaiined.

Since Document Management touches a lot of tables, it makes sense to put all the code in one place and call it from the object one is linking to. So, we have a button for attachments in the .NET client and a slide out in the Kinetic UI. Is the Slide Out the best way to handle attachments? :thinking: I agree with @MikeGross that it’s too many clicks. I can envision a document list component that can be embedded into a Kinetic page, but I have no idea if that is on the roadmap. One could just let the browser render the document in a new tab on a click. :person_shrugging:

For those of us on prem, there is a security issue with opening files on file servers or locally from the browser. Threat actors would love it so it’s rather a Bad Idea :tm:. @LarsonSolutions has shared a solution where you run your own web server and serve those files from file server via https. This works for reading but you won’t be able to upload files this way. Also, one should pass the credentials of the user through the webserver, or you’ll have to duplicate the file server folder security on the web server.

Which is where I think we are with ECM. It’s both a security issue and a licensing issue. The traditional model for on prem software is sales by seats. You can’t read or write files in ECM without a login. I think Epicor made an exception for Epicor/Kinetic users within the client. There’s probably a REST service that does the reading and writing on behalf of the Kinetic users. Had they required a seat for every Epicor/Kinetic user, they probably would not have sold many ECM instances since SharePoint is licensed differently. In a world where there is a single authentication server (Epicor IdP for example), one could come up with something that handles both the licensing and security issue, but we’ll have to see what Epicor comes up with.

1 Like

I was waiting @Mark_Wonsil

Bored Cabin Fever GIF

Edge Agent opens file attachments automatically.

But wait… :slight_smile:

and you have to install local Edge Agent.

I’ve heard SharePoint called to be the most expensive file storage. (SQL Server in on the second place :slight_smile: )

Under the user’s security context or a service credential? :thinking:

Oh, absolutely. I hear Azure File storage (SMB in the Azure) is up there too!

2 Likes

user’s

I would rather use Azure Blob/file storage, is it already suggested in Ideas?

But only local files, thanks to you imparting your knowledge yesterday :smiley:

It only works with local-side file attachments, yes. But it should open them the same way as smart client does - download from share and open automatically.

I’m not following. Local, but from a share? What do we mean by local?


I mean transfer type - Client System Direct Copy - copy from local machine directly to file share without using service

1 Like

I’m not so sure about that statement.
Depends on the file type and if a handler is registered.

Are you wanting to open documents INSIDE the Kinetic screens, or just have it download
and open up inside or outside the browser?

The second part certainly works fine, and many companies do that now.

I’d like some clarification from both sides in case I’m confused.

Or go back to our roots and use open S3 Buckets!

:face_with_hand_over_mouth:

@klincecum I’m just repeating what I am being told. I do not know what the technical/security issues might be, but let me explain why this is an issue for me.

I am not sure if you have ECM or not. For people that do, we could just open up the tree on a screen and double click the attachment and it would open. Granted, this looks much easier because I already opened the tree. I may have had to do multiple clicks to get them all open, but once they are open like below you can just double click on each of them to open (you’ll see why I mention this later).
image

Now in the browser, there are a few changes that are inconvenient. First, the attachments are not listed in the tree anymore. You have to open up the slideout by clicking the paper clip and then you get your list.
image

Once the list opens, you need to click on the reference number of the document you want and it will open up another slideout.

Once the next slideout opens, you need to click the download button.

Then you need to open the file from the download and you will see your file.
image

Now, to look at the next file, you need to X out the last slide out. This gets you back to the list. Then you need to click the next document number of the file you want to view which opens back up the next slide out where you need to click the download button again. If you are trying to open up multiple documents, it takes a long time compared to before.

Is this a big deal? Not in my opinion. Is it an inconvenience? 1 billion percent. Especially when you factor in that Epicor touts the integration between ERP and ECM. Additionally, I now need to work with my MSP to come up with a way to have users download folders cleared automatically because everyone will just be downloading mass amounts of documents. And we use ECM to store models so the floor can open them. Plus we are going to be moving to tablets which will have even less space.

Like I said earlier, will I die on this hill? No. But in my opinion it is a huge miss by Epicor.

1 Like

Piling on here, you also see that “View in ECM” button… which can be used instead of downloading, but using that actually opens ECM in another browser window and consumes a license.

2 Likes

I understand, just trying to get some clarification.

From what you’ve described, if I understand it correctly, it should be no problem to implement
on their end, as this is pretty standard functionality:

just curious, who are “they”? where is “their end”?

1 Like

I’m referring to the programmers of the Kinetic UI.