Upload files to AWS S3

Sugar has the AWS S3 libraries available in the vendor directory. You don't need to install anything. There is an old article from Angel Magana, http://cheleguanaco.blogspot.com/2015/05/sugarcrm-customization-custom-upload.html which discusses using S3, 

Check this file <sugarcrm>/include/SugarUploadS3.php and <sugarcrm>/vendor/aws/aws-sdk-php for more hints

Jeff Bickart and all, please note that the aws functionality including the configuration has been deprecated from our code base. See here: https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_10.3/Architecture/Configurator/Core_Settings/#aws 

Cheers

Enrico Simonetti would it be possible to upgrade the AWS and the Zend libraries included? They are pretty old as referenced in composer.json 

Jeff, do feel free to file an enhancement request please through the support portal, so that it can be properly tracked from all parts of the business.

The above message was to make you aware that the deprecation message has been there a while, and the code will eventually be going away

Hi Enrico Simonetti, thanks for the link. We have a couple of customers that rely on that library heavily since they have over 1 TB of documents each. Do you know if Sugar will provide an options? or would it need to be custom Development?

Any reason to remove it, it seems like a great feature with little to no overhead to mantain rather than removing it.

Regards,

Hi Enrico Simonetti, thanks for the link. We have a couple of customers that rely on that library heavily since they have over 1 TB of documents each. Do you know if Sugar will provide an options? or would it need to be custom Development?

Any reason to remove it, it seems like a great feature with little to no overhead to mantain rather than removing it.

Regards,

Hector Arteaga, I have circulated the question to Product Management. Expect a reply shortly.

Thanks!

Hector Arteaga The AWS S3 configuration as it was designed had a number of issues OOB where 1) it does not actually help customers save on their SugarCloud storage cost or bypass the uploads but simply retains another copy/takes a "backup" of sorts to the customers own AWS S3 bucket. Most customers that look towards this option assume that this configuration will help them save on storage OOB and the feature does not work in that manner and resulted in missed expectations in what it was perceived to be and what it actually did  2) The feature itself had a number of issues and errors (unless there is a specific customization done to make this work)  3) Adoption of the feature was also kept in mind as we found an extremely small base of our cloud customers making use of it per our last scan 

Our goal is for customers to rely on SugarCloud and we are also working towards some storage efforts to help customers that have a large need of uploads in our cloud -- more on that in upcoming quarters. 

With the above said, happy to jump on a call with you and chat about your scale of customers, how they make use of the feature and determine your usecases around it with your own S3. Are the customers you are referring to on-premise or hosted in SugarCloud? 

Best,

Vandita

I have the same case, i trying core settings aws and this comment its correct, this config is not really the best solution, I did not get the expected results. Team, other alternate solution? Enrico Simonetti some answer from Product Management?