7.11.18
Hi, is this intentended behaviour? When I send an email confirmation through a workflow, variables in the email template are being filled in as expected.
Sending the identical template from Event-Email invites failes to load the variables. I tried this with all sorts of variables, the below is just a simplified example. In both cases the template is of type āEventā.
Different places that pull vars are using different code.
My rule of thumbs is - if it worked, it worked. If it didnāt, it didnāt.
So I went and rewrote the whole template thing, itās much better now, if people really want it they can use the sponsorWare model and make it go into Core SuiteCRM in a while.
Youāre saying to basically completely forget the stock template integration and not to bother fixing? Email is kinda the key element of every CRM though?
Iām saying that at a project level, we shouldnāt bother with the small fixes that cause regressions, with the hacks placed upon hacks, that never take us to where we want to be - well designed software.
At your personal level, Iād just advise
donāt assume something will work until you see it working
budget some time/resources/developers to fix the parts of the code that are most critical to you. with some luck, it wonāt be too extensive.
I do agree with you that Email is critical and itās my no. 1 concern for this project. But the Community needs to pull together for this to progress, and itās not happening, and Iāve done all I can and I donāt know what else to doā¦
By means of feedback (if itās welcome) for corporate users, your supportware model is less than ideal. While we have budget for software development, we canāt do donations in the context of technical infrastructure for one, much less recurring donations for two, no matter what it is called by the way.
I understand your objective of recurring support revenues, thatās where everybody is going these days, but our controller wonāt even discuss that kind of expenditure. I know for a fact that many, if not most SMEs are like that. So while I might be able to unfreeze budget, this isnāt a good way to do it (strictly speaking for corporates). Just my 2 cents.
Would it be different for you if it was a paid add-on in the SuiteCRM Store? Those often involve recurring charges also. I was under the impression that my system would be the same for those corporate users.
Hmm, there is just a lot of scrutiny (especially now) on anything that involves longer term commitments. We need to budget for them (which costs time), we need to legally understand which license agreement we are entering and what the rights of use are (which costs BIG TIME and lawyer bucks), we need to approve them (which costs time), we need to track them (which costs time), we need to cancel them eventually (which costs time). At the time of cancellation we then need to ensure that we keep the right of use.
Understand that none of that might apply to this particular product. But we use in excess of 100 software packages/apps/programs all of which need to be asset managed. A controller / CFO or even CIO type doesnāt understand that and will not sign-off on stuff they dont understand and havenāt evaluated by a legal suit, especially if it is critical infrastructure to the business. That lawyer advice will cost more than the software license in most cases.
Bottom line, we like run and done type deals. Yo buy, when itās broken you buy a new one
Yes, in the US the mentality is different, I am aware of that, but here in the old country buy to own is easier. At least that is good as an option, then you can evaluate it, budget it and if approved buy it and forget it (financially).
Ok thanks a lot for the insight and explanations. Iāll consider if I can add such an option.
Iām juggling a few different āmentalitiesā here
itās one thing to try and be the ādeveloper hired by the Communityā that stays with the project and delivers continued value into Core (eventually)
a different thing is to be the add-on maker that provides business value by enhancing corporate processes and collects a fee for that
For me no. 1 is my vision and my identity, no. 2 is a possible complement to make sure I have a viable way to make a living. But I donāt like the SuiteCRM Store model (I think itās good, but insufficient for the long-term good of SuiteCRM) because it encourages people to hold back from the project, and to sell their contributions instead of giving them.
At the same time, everybody wants SalesAgility to give them immense free value and then some, and keep up a tremendous effort to sustain SuiteCRM. Things are unbalanced and itās proving quite hard to correct this āunbalanceā.
Looking at the functionality of what you have created, it should be relatively easy to come up with a freemium business model. Yes there is stuff that just should be free for the user. SA makes money off the store presumably, if the email component of a CRM is buggy a.f. they should have an interest in paying you for a base-line module/component that they then can release in the free model.
I for one have spent two days now to try and get a simple autoresponder email out after a user interaction. Thatās completely unacceptable and I am seriously questioning the viability of this product in a professional, fault-intolerant context.
Corporate/hard core users will then need more and if they use this to make money will be happy to pay A price for this if it streamlines the workflow/save time in administration. Thatās where you offer a premium product with extended functionality and give people a choice of paying once for what it is, they buy upgrades as and when they need OR buy a software maintenance contract and get automatic updates and support, if they are so inclined.
last checked suitecrm nearly 2 years, come back the email module still doesnāt work. I canāt get my server to verify Imap or SMTP with google and also it seems the campain template is broken?
any crm isnāt viable without basic email integration