I have an on site implementation (Sugar Ent 10.0.3) and I have an external process on the CRON server that creates pdf files that I have to relate to Contact Records.
Your Logicbuilder tool looks great, but I couldn't justify the additional recurring cost for every Sugar customer, but would be great as part of a Sugar developers toolbox :-)
I just found this which you may or may not be aware of, for this AWS requirements seems to be what Jeff Bickart was referring to, some Config settings rather than code?
CRM Business Consultant
Appreciate your appraisal.
Regarding the recurring cost - benefits may look unclear, but this frankly surprising feedback in another discussion branch says everything about possible outcomes.
I hope Sugar has got a customer for life with such a great platform adoption!
Also, if you've been to the recent Sugar SKO, you probably heard about Logic Builder in at least one of Sugar subscribers testimonials (which also surprised me)
I have had no clue about the code Jeff has pointed to as well as knew nothing about the current status of AWS S3 bucket support in Sugar core - probably support may help with the current status.
In Logic Builder, the operator AWS Command implements external API call to Amazon - that is why not just an S3 bucket is available but dozens of other services.
Have you signed up for Logic Builder?
If so, I could just share the flowchart this topic started from.
We make work in Sugar CRM system faster, more convenient and efficient
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
Principal Technical Advisory Manager
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
Principal Technical Advisory Manager
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.
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?
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?