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.
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? 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.
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 . @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.