Hi Jacques,I think the SystemProperty feature should not be tight together with the multi tenant terminology. It is usable without it and therefore should have it's own configuration. It would just add more confusion to users.
Regards, Michael Am 18.02.18 um 08:08 schrieb Jacques Le Roux:
Thanks Michael,Taher's reluctance pushed me to think about another solution. I add the same thought than you but with a different solution.We could have a multitenant and multitenant-initial readers, like we have seed and seed-initialLike ext readers , it would not be included in loadAll. So only multitenant deployments would use them.Then all files loading SystemProperties would declare using the multitenant or the multitenant-initial reader, eg<entity-resource type="data" reader-name="multitenant" loader="main" location="data/CommonSystemPropertyData.xml"/>A simple documentation should suffice. About>So I propose to introduce a file property which can switch the SystemProperty reading on and off.We already have it, it's the multitenant general property. But anyway with the multitenant reader modifying the code would not be needed. The data would not be loaded in a no multitenant deployment.With this solution all the problems related to SystemProperties would vanish and most of the related Jira issues could be closed, maybe with some changes like for OFBIZ-7112, anyway the list is belowIf nobody disagree I'll look at it soon... Jacques Le 17/02/2018 à 12:01, Michael Brohl a écrit :I don't think that this is the right way to go.The original problem is that we have some example SystemProperty data which is loaded automatically when you setup OFBiz in the documented way. This leads to confusion when someone changes the file properties for e.g. the mail transport configuration without success because the example data overrides it.The immediate solution for this problem is simple: just don't load/override file properties with example SystemProperty data by default.Although I do not agree with the deprecation of file properties in favor of SystemProperty, there are some aspects we should consider/do.OFBiz should consistently provide the possibility to overload file properties with SystemProperty data, not just in a few places.So +1 to implement this in all areas where it is reasonable for either multi tenant environments or configuration you might want to change at runtime. Of course, this is not something we should do in a simple search & replace session. It needs careful consideration.A good central documentation of all properties and if they can be changed at file or SystemProperty level would leave no questions open. A good task for contributors to the new documentation framework ;-)Additionally, I think we should make the SystemProperty loading configurable also, disabled by default. This would be the setting where only file properties would be used. For single tenant environments, it can avoid permanent entity checks/reading attempts where it is not necessary because SystemProperty is not used. So I propose to introduce a file property which can switch the SystemProperty reading on and off.This way, the default loading of the example SystemProperty data would do no harm also.For multi tenant environments or single tenant environments it can be switched on and allows overriding the file properties.This way, we are flexible to a maximum, there are no backward compatibility problems and there are no unneccessary memory usages or performance issues when the user does not want to use SystemProperty configurations.So in short: * -1 for file properties deprecation* +1 for consistently implementing SystemProperty reads where applicable/reasonable* additionally make SystemProperty reads configurable, off by default. Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 16.02.18 um 16:12 schrieb Jacques Le Roux:The more I think about it, the more I believe the ultimate solution is to remove all properties in favour of SystemProperties. And to no longer use properties but only SystemProperties.This entails to 1. completely implements EntityUtilProperties 2. deprecate UtilProperties 3. replace all properties by SystemPropertiesOne could argue that not all properties need to be SystemProperties because they are not useful for multi-tenants. But I believe that for consistency reasons it's easier to have all or nothing. Once well documented, this would avoid confusion and prevent creation of new erratic properties.Even the general-multitenant properties could be a SystemProperty, I see no reasons why not.Opinions, ideas? Thanks Jacques Le 16/02/2018 à 08:49, Jacques Le Roux a écrit :This could be a solution for this specific problem if we get a consensus. OFBIZ-7754 is relatedTo summarize: the problem is, because of OFBIZ-7112, if you use the same seeds than in 13.07 you will get nothing which can even be more confusing. That's why we have values in SystemProperty, this was done with r1748560.While at it, and about OFBIZ-7754 what about the other SystemProperty in other seed or seed-initial data files. seed-initial: WorkEffortSeedInitialData CatalogSystemPropertyData OrderSystemPropertyData BiSystemPropertyData ProjectMgrSystemPropertyDataseed: CommonSystemPropertyData EcommerceSystemPropertyDataI note that we have no other solutions yet than EntityUtilProperties to handle properties in multi-tenants. There is another related topic: we need to be sure to keep the SystemProperty and the properties in file synchronised as shown in OFBIZ-9924 I wonder if a solution could not be to remove any property which has a related SystemProperty. What do you think about that?So we need to get a consensus, or even a vote if necessary, to definitely resolve these issues.For that I exceptionally cross post this discussion in dev ML and it should be continued there.Thanks Jacques Le 15/02/2018 à 18:22, Mike a écrit :but to comment them out of the ofbiz-component.xml.+1On Thu, Feb 15, 2018 at 8:42 AM, Michael Brohl <michael.br...@ecomify.de>wrote:I agree that the default population of SystemProperty with configurationvalues is confusing, especially for the mail configurationI'd suggest to not remove the load data but to comment them out of the ofbiz-component.xml. They can stay there as an example but would not beloaded by default. Regards, Michael Am 15.02.18 um 17:07 schrieb Mike:Jacques: I understand the value of the feature. What I'm referring to issomebody, in 16.x, hard-coded the above values in "seed", which caused theproblem for this user.This is an advanced feature, and caused a lot of confusion. I'd recommendthat the 16.x CommonSystemPropertyData.xml be edited to remove all "systemPropertyValue=" entries. 13.07: ./framework/common/data/CommonSystemPropertyData.xml Here is the latest version of 13.07, which does not hard-code these values. None of the 13.07 seed data have "systemPropertyValue=" set. systemPropertyId="ORGANIZATION_PARTY systemPropertyId="VISUAL_THEME" systemPropertyId="currency.uom.id.default" systemPropertyId="country.geo.id.default" systemPropertyId="partner.trackingCodeId.default" systemPropertyId="defaultFromEmailAddress" systemPropertyId="mail.notifications.enabled" systemPropertyId="mail.smtp.relay.host" systemPropertyId="mail.smtp.auth.user" systemPropertyId="mail.smtp.auth.password" systemPropertyId="mail.smtp.port" systemPropertyId="mail.smtp.starttls.enable" systemPropertyId="mail.smtp.socketFactory.port" systemPropertyId="mail.smtp.socketFactory.class" systemPropertyId="mail.smtp.socketFactory.fallback" systemPropertyId="mail.smtp.sendpartial" On Thu, Feb 15, 2018 at 1:15 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Mike, thanks for askingThis controversial feature has been initially discussed with http://markmail.org/message/be3ts56b5w22k6pzWe currently have some related pending Jira about that (sorry maybe a bit too much, also a way to remind/check myself before discussing again indev ML) https://issues.apache.org/jira/browse/OFBIZ-7112 https://issues.apache.org/jira/browse/OFBIZ-7754 https://issues.apache.org/jira/browse/OFBIZ-6166 https://issues.apache.org/jira/browse/OFBIZ-6164 http://markmail.org/message/i4rubhbo7wlm4wts https://s.apache.org/oTA6 https://issues.apache.org/jira/browse/OFBIZ-6712 https://issues.apache.org/jira/browse/OFBIZ-6205 https://issues.apache.org/jira/browse/OFBIZ-6210Because this is now entrenched in OFBiz for many years, and I guess usedby many customs projects, it will maybe hard to get back. But then we need a better documentation. Beginning as simply as I proposed below. And we need to agree and fix the pending issues. HTH Jacques Le 14/02/2018 à 16:49, Mike a écrit : Jacques: Why does ofbiz 16.x set real propertiesin: ./framework/common/data/CommonSystemPropertyData.xml? This is partof "seed"... It hard-codes:systemPropertyId="ORGANIZATION_PARTY" systemPropertyValue="Company"systemPropertyId="VISUAL_THEME" systemPropertyValue="FLAT_GREY"systemPropertyId="currency.uom.id.default" systemPropertyValue="USD" systemPropertyId="country.geo.id.default" systemPropertyValue="USA"systemPropertyId="defaultFromEmailAddress" systemPropertyValue=" ofbizt...@example.com"systemPropertyId="mail.notifications.enabled" systemPropertyValue="N"systemPropertyId="mail.smtp.port" systemPropertyValue="465"systemPropertyId="mail.smtp.starttls.enable" systemPropertyValue="true"systemPropertyId="mail.smtp.socketFactory.port" systemPropertyValue="465" systemPropertyId="mail.smtp.socketFactory.class" systemPropertyValue="javax.net.ssl.SSLSocketFactory" systemPropertyId="mail.smtp.socketFactory.fallback" systemPropertyValue="false"systemPropertyId="mail.smtp.sendpartial" systemPropertyValue="true"Which seems to override general.properties. On Tue, Feb 13, 2018 at 6:55 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Thanks Pierre!This is indeed something which is tricky for new users and even easilyforgettable in general.Before I post about SystemProperty and EntityUtilProperties on dev ML,I want to suggest here that we put a comment at the top of each propertiesfile as a reminder that the properties there could be overridden in aSystemProperty Jacques Le 12/02/2018 à 21:32, pierre.gaudin a écrit : Also, have a look at SystemProperty entity for keymail.notifications.enabled Pierre On 12/02/2018 19:53, Mike wrote: For TLS (mail.smtp.starttls.enable=true ), use port 587On Mon, Feb 12, 2018 at 4:37 AM, Дмитрий Цыганок <d...@kapitanweb.ru>wrote: Hello!I've deployed Ofbiz several times, but each time with the rightsettings, email notifications are not sent. Here are my settings from /var/www/ofbiz/framework/commo n/config/general. properties: unique.instanceId=ofbiz1 currency.uom.id.default=USD ORGANIZATION_PARTY=Company VISUAL_THEME=RAINBOWSTONE_SAPHIR currency.decimal.format=#,##0.00 currency.rounding.default=10 currency.scale.enabled=N locale.properties.fallback=en #locales.available=ar,de,en,es,fr,hi,it,nl,pt,ro,ru,th,zh #timeZones.available=US/Eastern,US/Central,US/ Mountain,US/Pacific,US/Alaska,US/Hawaii country.geo.id.default=USA partner.trackingCodeId.default=usps.address.match=(^.*?p[\\. ]*o[\\. ]*box.*$)|(^.*?post.*?office.*?box.*$)|((^|(^.*? ))r[\\. ]*r[\\. ]*(( +)|([0-9#]+)).*$)|(^.*?rural.*?route.*$) defaultFromEmailAddress=dmtsyga...@gmail.com mail.notifications.enabled=Y mail.notifications.redirectTo=d...@kapitanweb.ru mail.smtp.relay.host=smtp.gmail.com mail.smtp.auth.user=dmtsyga...@gmail.com mail.smtp.auth.password=******* mail.smtp.port=465 mail.smtp.starttls.enable=true mail.smtp.socketFactory.port=465 mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory mail.smtp.socketFactory.fallback=false mail.address.caseInsensitive=N mail.debug.on=N mail.smtp.sendpartial=true http.upload.max.sizethreshold=10240 http.upload.tmprepository=runtime/tmp http.upload.max.size=-1 mail.spam.name=X-Spam-Flag mail.spam.value=YESOfbiz always issues this error in the logs and the mail is not sent:" 2018-01-17 22:21:19,562 |OFBiz-JobQueue-1 |EmailServices|I| Mail notifications disabled in general.properties; mailwith subject [test] not sent to addressee [ d...@kapitanweb.ru "I also tried different mail accounts, but the result is always thesame.What could be the reason? Please help me to solve this problem.Thank you very much in advance! --- Best Regards, Dmitriy
smime.p7s
Description: S/MIME Cryptographic Signature
