You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Hans Bakker <ma...@antwebsystems.com> on 2012/01/27 07:40:45 UTC
proposal: overriding property setting per tenant.
Problem:
------------
1. If you would like to have different tenants on your system and want
to have different property settings for each tenant laike language or
currency etc, that is currently not supported.
2. the properties are not very well organized, to say the least.
Proposal:
------------
1. create the following entity SystemProperty with fields:
systemPropertyId(key)
parentSystemPropertyId
description
ofbizPropertyName(index)
systemPropertyValue
Initially load the systemPropertyid from the ofbiz propertyId so
accounting.fixedasset.autocreate=Y will have 3 records using the parent
id but only the lowest level will have the
accounting.fixedasset.autocreate name and value=Y
when we have this working we can slowly reorganize these records without
having to change the programs.
2. add the delegator parameter to the getPropertyValue method and change
the method system wide.
the getPropertyValue method will first look in this entity with the
provided delegator and when the property is null or not found, use the
properties file property as currently is done.
3. resolve anywhere where this method is called and where the delegator
is not available.
4. add a webtools option to set the properties.
Please provide comments or counter proposals......
Regards,
Hans
Re: proposal: overriding property setting per tenant.
Posted by Hans Bakker <ma...@antwebsystems.com>.
No it is not, property settings are taken for every tenant from the
properties file.
Do not confuse with userPreferences which are settings per userlogin.
Do not have a list yet...but is not really required because if it is
missing in the entity it still will retrieve it from the properties file.
Regards,
hans
On 01/27/2012 03:03 PM, Pierre Smits wrote:
> Hans,
>
> Is it not so that the default currency of any tenant is set when the
> ofbiz-setup process is run for that tenant? That should also be the case
> with other organizational settings per tenant, like default language.
>
> Do you currently have a list of all the properties that are spread over all
> the components?
>
>
> Regards, Pierre.
>
>
>
> 2012/1/27 Hans Bakker<ma...@antwebsystems.com>
>
>> Problem:
>> ------------
>> 1. If you would like to have different tenants on your system and want to
>> have different property settings for each tenant laike language or currency
>> etc, that is currently not supported.
>> 2. the properties are not very well organized, to say the least.
>>
>> Proposal:
>> ------------
>> 1. create the following entity SystemProperty with fields:
>> systemPropertyId(key)
>> parentSystemPropertyId
>> description
>> ofbizPropertyName(index)
>> systemPropertyValue
>>
>> Initially load the systemPropertyid from the ofbiz propertyId so
>> accounting.fixedasset.**autocreate=Y will have 3 records using the parent
>> id but only the lowest level will have the accounting.fixedasset.**autocreate
>> name and value=Y
>>
>> when we have this working we can slowly reorganize these records without
>> having to change the programs.
>>
>> 2. add the delegator parameter to the getPropertyValue method and change
>> the method system wide.
>> the getPropertyValue method will first look in this entity with the
>> provided delegator and when the property is null or not found, use the
>> properties file property as currently is done.
>> 3. resolve anywhere where this method is called and where the delegator is
>> not available.
>> 4. add a webtools option to set the properties.
>>
>> Please provide comments or counter proposals......
>>
>> Regards,
>> Hans
>>
Re: proposal: overriding property setting per tenant.
Posted by Pierre Smits <pi...@gmail.com>.
Hans,
Is it not so that the default currency of any tenant is set when the
ofbiz-setup process is run for that tenant? That should also be the case
with other organizational settings per tenant, like default language.
Do you currently have a list of all the properties that are spread over all
the components?
Regards, Pierre.
2012/1/27 Hans Bakker <ma...@antwebsystems.com>
> Problem:
> ------------
> 1. If you would like to have different tenants on your system and want to
> have different property settings for each tenant laike language or currency
> etc, that is currently not supported.
> 2. the properties are not very well organized, to say the least.
>
> Proposal:
> ------------
> 1. create the following entity SystemProperty with fields:
> systemPropertyId(key)
> parentSystemPropertyId
> description
> ofbizPropertyName(index)
> systemPropertyValue
>
> Initially load the systemPropertyid from the ofbiz propertyId so
> accounting.fixedasset.**autocreate=Y will have 3 records using the parent
> id but only the lowest level will have the accounting.fixedasset.**autocreate
> name and value=Y
>
> when we have this working we can slowly reorganize these records without
> having to change the programs.
>
> 2. add the delegator parameter to the getPropertyValue method and change
> the method system wide.
> the getPropertyValue method will first look in this entity with the
> provided delegator and when the property is null or not found, use the
> properties file property as currently is done.
> 3. resolve anywhere where this method is called and where the delegator is
> not available.
> 4. add a webtools option to set the properties.
>
> Please provide comments or counter proposals......
>
> Regards,
> Hans
>
Re: proposal: overriding property setting per tenant.
Posted by Jacques Le Roux <ja...@les7arts.com>.
What could be even more intereting is to add a dynamic way to load a property in the schema you proposed.
For instance SAP xMII usse a such scheme for dynamic i18n (which is not our concern since we have xml file for that)
http://help.sap.com/saphelp_xmii115/helpdata/en/Localization/Localization_Overview.htm
Excerpt:
<<Dynamic user localization is performed in a similar manner as Java resource bundles but uses custom code. User localization
changes are dynamic and take effect immediately. These files are located in the Properties directory. Unlike Java resource bundles,
the language
is used to identify the various files only, rather than the full locale information.>>
My 2 cts
Jacques
From: "Adrian Crum" <ad...@sandglass-software.com>
>I have been thinking about Properties handling too, not from a multi-tenant perspective, but from a convenience perspective.
>
> It seems to me the way we handle properties right now could be simplified. Instead of calling a static utility method to get a
> property or using a special mini-language element, the service or screen rendering context should contain a Map called
> "properties" - which provides a convenient means of accessing all configuration properties. So, instead of:
>
> <property-to-field resource="general.properties" property="currency.uom.id.default" field="rateCurrencyUomId"/>
>
> you would use:
>
> <set field="rateCurrencyUomId" from-field="properties.currency.uom.id.default"/>
>
> and in Java, instead of:
>
> String currencyUom = UtilProperties.getPropertyValue("general.properties", "currency.uom.id.default");
>
> you would use:
>
> String currencyUom = dctx.properties.get("currency.uom.id.default");
>
> Configuration Properties files could be read in at startup via an ofbiz.component.xml element or elements.
>
> The properties Map is read-only after startup.
>
> When all of the configuration properties are handled in a centralized way, then extending the design to use the entity engine as
> an additional configuration property data source will be trivial.
>
> The SystemProperty entity you proposed needs to be simplified:
>
> SystemProperty
> --------------
>
> propertyKey, id-vlong-ne*
> propertyValue, very-long
>
> Properties file entries contain only key+value pairs, so the entity should do the same.
>
> -Adrian
>
> On 1/27/2012 6:40 AM, Hans Bakker wrote:
>> Problem:
>> ------------
>> 1. If you would like to have different tenants on your system and want to have different property settings for each tenant laike
>> language or currency etc, that is currently not supported.
>> 2. the properties are not very well organized, to say the least.
>>
>> Proposal:
>> ------------
>> 1. create the following entity SystemProperty with fields:
>> systemPropertyId(key)
>> parentSystemPropertyId
>> description
>> ofbizPropertyName(index)
>> systemPropertyValue
>>
>> Initially load the systemPropertyid from the ofbiz propertyId so accounting.fixedasset.autocreate=Y will have 3 records using the
>> parent id but only the lowest level will have the accounting.fixedasset.autocreate name and value=Y
>>
>> when we have this working we can slowly reorganize these records without having to change the programs.
>>
>> 2. add the delegator parameter to the getPropertyValue method and change the method system wide.
>> the getPropertyValue method will first look in this entity with the provided delegator and when the property is null or not
>> found, use the properties file property as currently is done.
>> 3. resolve anywhere where this method is called and where the delegator is not available.
>> 4. add a webtools option to set the properties.
>>
>> Please provide comments or counter proposals......
>>
>> Regards,
>> Hans
Re: proposal: overriding property setting per tenant.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes thanks Joe,
I was (almost) sure I had read something in Commons for properties reloading but could not put my hand on it
Jacques
From: "Adrian Crum" <ad...@sandglass-software.com>
> Thanks for the reminder Joe!
>
> -Adrian
>
> On 1/29/2012 5:26 PM, J. Eckard wrote:
>> Apache Commons Configuration can do this.
>>
>> http://commons.apache.org/configuration/userguide/howto_multitenant.html#Multi-tenant_Configurations
>>
>> ---
>>
>> http://osdir.com/ml/user.ofbiz.apache.org/2010-03/msg00343.html
>>
>> Subject: Re: Brainstorming about the Framework: General - msg#00343
>>
>> List: user.ofbiz.apache.org
>>
>> Something I've thought about from time to time but never followed through all the way to make sure there are no glaring problems:
>> switch UtilProperties to use something like Commons Configuration.
>>
>> This would essentially put all configuration variables into one namespace, where they would be accessed via XPath expressions.
>> You could pull and merge from various sources like properties files or XML files, get (optional) automatic saving / reloading,
>> and (optional) property overriding.
>>
>> The main reason for this would be to have a single file you could use for deployment (dev.xml, staging.xml, production.xml,
>> etc) - drop this in your hot-deploy component and have it override the values in framework / applications.
>>
>> -Joe
>>
>>
>> On Jan 27, 2012, at 3:49 AM, Adrian Crum wrote:
>>
>>> I have been thinking about Properties handling too, not from a multi-tenant perspective, but from a convenience perspective.
>>>
>>> It seems to me the way we handle properties right now could be simplified. Instead of calling a static utility method to get a
>>> property or using a special mini-language element, the service or screen rendering context should contain a Map called
>>> "properties" - which provides a convenient means of accessing all configuration properties. So, instead of:
>>>
>>> <property-to-field resource="general.properties" property="currency.uom.id.default" field="rateCurrencyUomId"/>
>>>
>>> you would use:
>>>
>>> <set field="rateCurrencyUomId" from-field="properties.currency.uom.id.default"/>
>>>
>>> and in Java, instead of:
>>>
>>> String currencyUom = UtilProperties.getPropertyValue("general.properties", "currency.uom.id.default");
>>>
>>> you would use:
>>>
>>> String currencyUom = dctx.properties.get("currency.uom.id.default");
>>>
>>> Configuration Properties files could be read in at startup via an ofbiz.component.xml element or elements.
>>>
>>> The properties Map is read-only after startup.
>>>
>>> When all of the configuration properties are handled in a centralized way, then extending the design to use the entity engine as
>>> an additional configuration property data source will be trivial.
>>>
>>> The SystemProperty entity you proposed needs to be simplified:
>>>
>>> SystemProperty
>>> --------------
>>>
>>> propertyKey, id-vlong-ne*
>>> propertyValue, very-long
>>>
>>> Properties file entries contain only key+value pairs, so the entity should do the same.
>>>
>>> -Adrian
>>>
>>> On 1/27/2012 6:40 AM, Hans Bakker wrote:
>>>> Problem:
>>>> ------------
>>>> 1. If you would like to have different tenants on your system and want to have different property settings for each tenant
>>>> laike language or currency etc, that is currently not supported.
>>>> 2. the properties are not very well organized, to say the least.
>>>>
>>>> Proposal:
>>>> ------------
>>>> 1. create the following entity SystemProperty with fields:
>>>> systemPropertyId(key)
>>>> parentSystemPropertyId
>>>> description
>>>> ofbizPropertyName(index)
>>>> systemPropertyValue
>>>>
>>>> Initially load the systemPropertyid from the ofbiz propertyId so accounting.fixedasset.autocreate=Y will have 3 records using
>>>> the parent id but only the lowest level will have the accounting.fixedasset.autocreate name and value=Y
>>>>
>>>> when we have this working we can slowly reorganize these records without having to change the programs.
>>>>
>>>> 2. add the delegator parameter to the getPropertyValue method and change the method system wide.
>>>> the getPropertyValue method will first look in this entity with the provided delegator and when the property is null or not
>>>> found, use the properties file property as currently is done.
>>>> 3. resolve anywhere where this method is called and where the delegator is not available.
>>>> 4. add a webtools option to set the properties.
>>>>
>>>> Please provide comments or counter proposals......
>>>>
>>>> Regards,
>>>> Hans
Re: proposal: overriding property setting per tenant.
Posted by Adrian Crum <ad...@sandglass-software.com>.
Thanks for the reminder Joe!
-Adrian
On 1/29/2012 5:26 PM, J. Eckard wrote:
> Apache Commons Configuration can do this.
>
> http://commons.apache.org/configuration/userguide/howto_multitenant.html#Multi-tenant_Configurations
>
> ---
>
> http://osdir.com/ml/user.ofbiz.apache.org/2010-03/msg00343.html
>
> Subject: Re: Brainstorming about the Framework: General - msg#00343
>
> List: user.ofbiz.apache.org
>
> Something I've thought about from time to time but never followed through all the way to make sure there are no glaring problems: switch UtilProperties to use something like Commons Configuration.
>
> This would essentially put all configuration variables into one namespace, where they would be accessed via XPath expressions. You could pull and merge from various sources like properties files or XML files, get (optional) automatic saving / reloading, and (optional) property overriding.
>
> The main reason for this would be to have a single file you could use for deployment (dev.xml, staging.xml, production.xml, etc) - drop this in your hot-deploy component and have it override the values in framework / applications.
>
> -Joe
>
>
> On Jan 27, 2012, at 3:49 AM, Adrian Crum wrote:
>
>> I have been thinking about Properties handling too, not from a multi-tenant perspective, but from a convenience perspective.
>>
>> It seems to me the way we handle properties right now could be simplified. Instead of calling a static utility method to get a property or using a special mini-language element, the service or screen rendering context should contain a Map called "properties" - which provides a convenient means of accessing all configuration properties. So, instead of:
>>
>> <property-to-field resource="general.properties" property="currency.uom.id.default" field="rateCurrencyUomId"/>
>>
>> you would use:
>>
>> <set field="rateCurrencyUomId" from-field="properties.currency.uom.id.default"/>
>>
>> and in Java, instead of:
>>
>> String currencyUom = UtilProperties.getPropertyValue("general.properties", "currency.uom.id.default");
>>
>> you would use:
>>
>> String currencyUom = dctx.properties.get("currency.uom.id.default");
>>
>> Configuration Properties files could be read in at startup via an ofbiz.component.xml element or elements.
>>
>> The properties Map is read-only after startup.
>>
>> When all of the configuration properties are handled in a centralized way, then extending the design to use the entity engine as an additional configuration property data source will be trivial.
>>
>> The SystemProperty entity you proposed needs to be simplified:
>>
>> SystemProperty
>> --------------
>>
>> propertyKey, id-vlong-ne*
>> propertyValue, very-long
>>
>> Properties file entries contain only key+value pairs, so the entity should do the same.
>>
>> -Adrian
>>
>> On 1/27/2012 6:40 AM, Hans Bakker wrote:
>>> Problem:
>>> ------------
>>> 1. If you would like to have different tenants on your system and want to have different property settings for each tenant laike language or currency etc, that is currently not supported.
>>> 2. the properties are not very well organized, to say the least.
>>>
>>> Proposal:
>>> ------------
>>> 1. create the following entity SystemProperty with fields:
>>> systemPropertyId(key)
>>> parentSystemPropertyId
>>> description
>>> ofbizPropertyName(index)
>>> systemPropertyValue
>>>
>>> Initially load the systemPropertyid from the ofbiz propertyId so accounting.fixedasset.autocreate=Y will have 3 records using the parent id but only the lowest level will have the accounting.fixedasset.autocreate name and value=Y
>>>
>>> when we have this working we can slowly reorganize these records without having to change the programs.
>>>
>>> 2. add the delegator parameter to the getPropertyValue method and change the method system wide.
>>> the getPropertyValue method will first look in this entity with the provided delegator and when the property is null or not found, use the properties file property as currently is done.
>>> 3. resolve anywhere where this method is called and where the delegator is not available.
>>> 4. add a webtools option to set the properties.
>>>
>>> Please provide comments or counter proposals......
>>>
>>> Regards,
>>> Hans
Re: proposal: overriding property setting per tenant.
Posted by "J. Eckard" <ec...@redrocketcorp.com>.
Apache Commons Configuration can do this.
http://commons.apache.org/configuration/userguide/howto_multitenant.html#Multi-tenant_Configurations
---
http://osdir.com/ml/user.ofbiz.apache.org/2010-03/msg00343.html
Subject: Re: Brainstorming about the Framework: General - msg#00343
List: user.ofbiz.apache.org
Something I've thought about from time to time but never followed through all the way to make sure there are no glaring problems: switch UtilProperties to use something like Commons Configuration.
This would essentially put all configuration variables into one namespace, where they would be accessed via XPath expressions. You could pull and merge from various sources like properties files or XML files, get (optional) automatic saving / reloading, and (optional) property overriding.
The main reason for this would be to have a single file you could use for deployment (dev.xml, staging.xml, production.xml, etc) - drop this in your hot-deploy component and have it override the values in framework / applications.
-Joe
On Jan 27, 2012, at 3:49 AM, Adrian Crum wrote:
> I have been thinking about Properties handling too, not from a multi-tenant perspective, but from a convenience perspective.
>
> It seems to me the way we handle properties right now could be simplified. Instead of calling a static utility method to get a property or using a special mini-language element, the service or screen rendering context should contain a Map called "properties" - which provides a convenient means of accessing all configuration properties. So, instead of:
>
> <property-to-field resource="general.properties" property="currency.uom.id.default" field="rateCurrencyUomId"/>
>
> you would use:
>
> <set field="rateCurrencyUomId" from-field="properties.currency.uom.id.default"/>
>
> and in Java, instead of:
>
> String currencyUom = UtilProperties.getPropertyValue("general.properties", "currency.uom.id.default");
>
> you would use:
>
> String currencyUom = dctx.properties.get("currency.uom.id.default");
>
> Configuration Properties files could be read in at startup via an ofbiz.component.xml element or elements.
>
> The properties Map is read-only after startup.
>
> When all of the configuration properties are handled in a centralized way, then extending the design to use the entity engine as an additional configuration property data source will be trivial.
>
> The SystemProperty entity you proposed needs to be simplified:
>
> SystemProperty
> --------------
>
> propertyKey, id-vlong-ne*
> propertyValue, very-long
>
> Properties file entries contain only key+value pairs, so the entity should do the same.
>
> -Adrian
>
> On 1/27/2012 6:40 AM, Hans Bakker wrote:
>> Problem:
>> ------------
>> 1. If you would like to have different tenants on your system and want to have different property settings for each tenant laike language or currency etc, that is currently not supported.
>> 2. the properties are not very well organized, to say the least.
>>
>> Proposal:
>> ------------
>> 1. create the following entity SystemProperty with fields:
>> systemPropertyId(key)
>> parentSystemPropertyId
>> description
>> ofbizPropertyName(index)
>> systemPropertyValue
>>
>> Initially load the systemPropertyid from the ofbiz propertyId so accounting.fixedasset.autocreate=Y will have 3 records using the parent id but only the lowest level will have the accounting.fixedasset.autocreate name and value=Y
>>
>> when we have this working we can slowly reorganize these records without having to change the programs.
>>
>> 2. add the delegator parameter to the getPropertyValue method and change the method system wide.
>> the getPropertyValue method will first look in this entity with the provided delegator and when the property is null or not found, use the properties file property as currently is done.
>> 3. resolve anywhere where this method is called and where the delegator is not available.
>> 4. add a webtools option to set the properties.
>>
>> Please provide comments or counter proposals......
>>
>> Regards,
>> Hans
Re: proposal: overriding property setting per tenant.
Posted by Adrian Crum <ad...@sandglass-software.com>.
I have been thinking about Properties handling too, not from a
multi-tenant perspective, but from a convenience perspective.
It seems to me the way we handle properties right now could be
simplified. Instead of calling a static utility method to get a property
or using a special mini-language element, the service or screen
rendering context should contain a Map called "properties" - which
provides a convenient means of accessing all configuration properties.
So, instead of:
<property-to-field resource="general.properties"
property="currency.uom.id.default" field="rateCurrencyUomId"/>
you would use:
<set field="rateCurrencyUomId"
from-field="properties.currency.uom.id.default"/>
and in Java, instead of:
String currencyUom =
UtilProperties.getPropertyValue("general.properties",
"currency.uom.id.default");
you would use:
String currencyUom = dctx.properties.get("currency.uom.id.default");
Configuration Properties files could be read in at startup via an
ofbiz.component.xml element or elements.
The properties Map is read-only after startup.
When all of the configuration properties are handled in a centralized
way, then extending the design to use the entity engine as an additional
configuration property data source will be trivial.
The SystemProperty entity you proposed needs to be simplified:
SystemProperty
--------------
propertyKey, id-vlong-ne*
propertyValue, very-long
Properties file entries contain only key+value pairs, so the entity
should do the same.
-Adrian
On 1/27/2012 6:40 AM, Hans Bakker wrote:
> Problem:
> ------------
> 1. If you would like to have different tenants on your system and want
> to have different property settings for each tenant laike language or
> currency etc, that is currently not supported.
> 2. the properties are not very well organized, to say the least.
>
> Proposal:
> ------------
> 1. create the following entity SystemProperty with fields:
> systemPropertyId(key)
> parentSystemPropertyId
> description
> ofbizPropertyName(index)
> systemPropertyValue
>
> Initially load the systemPropertyid from the ofbiz propertyId so
> accounting.fixedasset.autocreate=Y will have 3 records using the
> parent id but only the lowest level will have the
> accounting.fixedasset.autocreate name and value=Y
>
> when we have this working we can slowly reorganize these records
> without having to change the programs.
>
> 2. add the delegator parameter to the getPropertyValue method and
> change the method system wide.
> the getPropertyValue method will first look in this entity with the
> provided delegator and when the property is null or not found, use the
> properties file property as currently is done.
> 3. resolve anywhere where this method is called and where the
> delegator is not available.
> 4. add a webtools option to set the properties.
>
> Please provide comments or counter proposals......
>
> Regards,
> Hans
Re: proposal: overriding property setting per tenant.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Ruth,
Could you elaborate on "true multitenancy", describe it in more details?
Could you compare with current OFBiz solution?
What would be the best way for OFBiz to achieve it?
Thanks
Jacques
From: "Ruth Hoffman" <rh...@aesolves.com>
> Hi Pierre:
>
> I understand the premise. I don't understand the value proposition. I
> just don't see how this is any better than separate instances. Just
> wondered if anyone has done an ROI comparing the two approaches. My
> analysis suggests that the OFBiz implementation may not be the best way
> to achieve true multitenancy. I'm wanting to know if anyone has data to
> prove me wrong.
>
> Best Regards
> Ruth
>
> On 1/27/12 10:31 AM, Pierre Smits wrote:
>> Hi Ruth,
>>
>> For an explanation on multi-tenancy see
>> http://en.wikipedia.org/wiki/Multitenancy.
>>
>> OFBiz does handle specific tenant usage with that datasets for each tenant
>> can be customer specific and with regards of provision of hot-deploy
>> applications each application can be made available to the tenants through
>> the security model.
>>
>> With regards,
>>
>> Pierre Smits
>>
>> 2012/1/27 Ruth Hoffman<rh...@aesolves.com>
>>
>>> Hi Hans, et al.
>>> Could someone take a few minutes and explain to me the value of OFBiz
>>> multi-tenancy? Why not just use SVN or other tool specifically designed to
>>> manage multiple versions of a project where a project is an OFBiz tenant.
>>> The problem as I see it is that the OFBiz multi-tenant implementation does
>>> not include the concept of a "landlord". Nor does it have any notion of how
>>> to handle specific tenant useage. It assumes that all tenants are equal and
>>> have the same system level requirements. Are they? Maybe I just don't
>>> understand the use-case for it.
>>>
>>> Han's example is just one of the challenges presented when using this
>>> approach to host multiple "tenants".
>>>
>>> Thanks much.
>>> Ruth
>>>
>>>
>>> On 1/27/12 1:40 AM, Hans Bakker wrote:
>>>
>>>> Problem:
>>>> ------------
>>>> 1. If you would like to have different tenants on your system and want to
>>>> have different property settings for each tenant laike language or currency
>>>> etc, that is currently not supported.
>>>> 2. the properties are not very well organized, to say the least.
>>>>
>>>> Proposal:
>>>> ------------
>>>> 1. create the following entity SystemProperty with fields:
>>>> systemPropertyId(key)
>>>> parentSystemPropertyId
>>>> description
>>>> ofbizPropertyName(index)
>>>> systemPropertyValue
>>>>
>>>> Initially load the systemPropertyid from the ofbiz propertyId so
>>>> accounting.fixedasset.**autocreate=Y will have 3 records using the
>>>> parent id but only the lowest level will have the accounting.fixedasset.*
>>>> *autocreate name and value=Y
>>>>
>>>> when we have this working we can slowly reorganize these records without
>>>> having to change the programs.
>>>>
>>>> 2. add the delegator parameter to the getPropertyValue method and change
>>>> the method system wide.
>>>> the getPropertyValue method will first look in this entity with the
>>>> provided delegator and when the property is null or not found, use the
>>>> properties file property as currently is done.
>>>> 3. resolve anywhere where this method is called and where the delegator
>>>> is not available.
>>>> 4. add a webtools option to set the properties.
>>>>
>>>> Please provide comments or counter proposals......
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>>
Re: proposal: overriding property setting per tenant.
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Hi Ruth,
Multitenancy has several benefits:
- Maintenance
You can do maintenance and upgrades once, rather than repeating that effort
for each customer.
- Resource usage
Entirely separate instances of OFBiz require entirely separate Java Virtual
Machines. Multitenancy makes more efficient use of resources like RAM. That
matters if you're hosting on a cloud or virtual private server.
Cheers
Paul Foxworthy
Ruth Hoffman-2 wrote
>
> Hi Pierre:
>
> I understand the premise. I don't understand the value proposition. I
> just don't see how this is any better than separate instances. Just
> wondered if anyone has done an ROI comparing the two approaches. My
> analysis suggests that the OFBiz implementation may not be the best way
> to achieve true multitenancy. I'm wanting to know if anyone has data to
> prove me wrong.
>
> Best Regards
> Ruth
>
> On 1/27/12 10:31 AM, Pierre Smits wrote:
>> Hi Ruth,
>>
>> For an explanation on multi-tenancy see
>> http://en.wikipedia.org/wiki/Multitenancy.
>>
>> OFBiz does handle specific tenant usage with that datasets for each
>> tenant
>> can be customer specific and with regards of provision of hot-deploy
>> applications each application can be made available to the tenants
>> through
>> the security model.
>>
>> With regards,
>>
>> Pierre Smits
>>
>> 2012/1/27 Ruth Hoffman<rhoffman@>
>>
>>> Hi Hans, et al.
>>> Could someone take a few minutes and explain to me the value of OFBiz
>>> multi-tenancy? Why not just use SVN or other tool specifically designed
>>> to
>>> manage multiple versions of a project where a project is an OFBiz
>>> tenant.
>>> The problem as I see it is that the OFBiz multi-tenant implementation
>>> does
>>> not include the concept of a "landlord". Nor does it have any notion of
>>> how
>>> to handle specific tenant useage. It assumes that all tenants are equal
>>> and
>>> have the same system level requirements. Are they? Maybe I just don't
>>> understand the use-case for it.
>>>
>>> Han's example is just one of the challenges presented when using this
>>> approach to host multiple "tenants".
>>>
>>> Thanks much.
>>> Ruth
>>>
>>>
>>> On 1/27/12 1:40 AM, Hans Bakker wrote:
>>>
>>>> Problem:
>>>> ------------
>>>> 1. If you would like to have different tenants on your system and want
>>>> to
>>>> have different property settings for each tenant laike language or
>>>> currency
>>>> etc, that is currently not supported.
>>>> 2. the properties are not very well organized, to say the least.
>>>>
>>>> Proposal:
>>>> ------------
>>>> 1. create the following entity SystemProperty with fields:
>>>> systemPropertyId(key)
>>>> parentSystemPropertyId
>>>> description
>>>> ofbizPropertyName(index)
>>>> systemPropertyValue
>>>>
>>>> Initially load the systemPropertyid from the ofbiz propertyId so
>>>> accounting.fixedasset.**autocreate=Y will have 3 records using the
>>>> parent id but only the lowest level will have the
>>>> accounting.fixedasset.*
>>>> *autocreate name and value=Y
>>>>
>>>> when we have this working we can slowly reorganize these records
>>>> without
>>>> having to change the programs.
>>>>
>>>> 2. add the delegator parameter to the getPropertyValue method and
>>>> change
>>>> the method system wide.
>>>> the getPropertyValue method will first look in this entity with the
>>>> provided delegator and when the property is null or not found, use the
>>>> properties file property as currently is done.
>>>> 3. resolve anywhere where this method is called and where the delegator
>>>> is not available.
>>>> 4. add a webtools option to set the properties.
>>>>
>>>> Please provide comments or counter proposals......
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>>
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/proposal-overriding-property-setting-per-tenant-tp4332720p4337667.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: proposal: overriding property setting per tenant.
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Pierre:
I understand the premise. I don't understand the value proposition. I
just don't see how this is any better than separate instances. Just
wondered if anyone has done an ROI comparing the two approaches. My
analysis suggests that the OFBiz implementation may not be the best way
to achieve true multitenancy. I'm wanting to know if anyone has data to
prove me wrong.
Best Regards
Ruth
On 1/27/12 10:31 AM, Pierre Smits wrote:
> Hi Ruth,
>
> For an explanation on multi-tenancy see
> http://en.wikipedia.org/wiki/Multitenancy.
>
> OFBiz does handle specific tenant usage with that datasets for each tenant
> can be customer specific and with regards of provision of hot-deploy
> applications each application can be made available to the tenants through
> the security model.
>
> With regards,
>
> Pierre Smits
>
> 2012/1/27 Ruth Hoffman<rh...@aesolves.com>
>
>> Hi Hans, et al.
>> Could someone take a few minutes and explain to me the value of OFBiz
>> multi-tenancy? Why not just use SVN or other tool specifically designed to
>> manage multiple versions of a project where a project is an OFBiz tenant.
>> The problem as I see it is that the OFBiz multi-tenant implementation does
>> not include the concept of a "landlord". Nor does it have any notion of how
>> to handle specific tenant useage. It assumes that all tenants are equal and
>> have the same system level requirements. Are they? Maybe I just don't
>> understand the use-case for it.
>>
>> Han's example is just one of the challenges presented when using this
>> approach to host multiple "tenants".
>>
>> Thanks much.
>> Ruth
>>
>>
>> On 1/27/12 1:40 AM, Hans Bakker wrote:
>>
>>> Problem:
>>> ------------
>>> 1. If you would like to have different tenants on your system and want to
>>> have different property settings for each tenant laike language or currency
>>> etc, that is currently not supported.
>>> 2. the properties are not very well organized, to say the least.
>>>
>>> Proposal:
>>> ------------
>>> 1. create the following entity SystemProperty with fields:
>>> systemPropertyId(key)
>>> parentSystemPropertyId
>>> description
>>> ofbizPropertyName(index)
>>> systemPropertyValue
>>>
>>> Initially load the systemPropertyid from the ofbiz propertyId so
>>> accounting.fixedasset.**autocreate=Y will have 3 records using the
>>> parent id but only the lowest level will have the accounting.fixedasset.*
>>> *autocreate name and value=Y
>>>
>>> when we have this working we can slowly reorganize these records without
>>> having to change the programs.
>>>
>>> 2. add the delegator parameter to the getPropertyValue method and change
>>> the method system wide.
>>> the getPropertyValue method will first look in this entity with the
>>> provided delegator and when the property is null or not found, use the
>>> properties file property as currently is done.
>>> 3. resolve anywhere where this method is called and where the delegator
>>> is not available.
>>> 4. add a webtools option to set the properties.
>>>
>>> Please provide comments or counter proposals......
>>>
>>> Regards,
>>> Hans
>>>
>>>
Re: proposal: overriding property setting per tenant.
Posted by Pierre Smits <pi...@gmail.com>.
Hi Ruth,
For an explanation on multi-tenancy see
http://en.wikipedia.org/wiki/Multitenancy.
OFBiz does handle specific tenant usage with that datasets for each tenant
can be customer specific and with regards of provision of hot-deploy
applications each application can be made available to the tenants through
the security model.
With regards,
Pierre Smits
2012/1/27 Ruth Hoffman <rh...@aesolves.com>
> Hi Hans, et al.
> Could someone take a few minutes and explain to me the value of OFBiz
> multi-tenancy? Why not just use SVN or other tool specifically designed to
> manage multiple versions of a project where a project is an OFBiz tenant.
> The problem as I see it is that the OFBiz multi-tenant implementation does
> not include the concept of a "landlord". Nor does it have any notion of how
> to handle specific tenant useage. It assumes that all tenants are equal and
> have the same system level requirements. Are they? Maybe I just don't
> understand the use-case for it.
>
> Han's example is just one of the challenges presented when using this
> approach to host multiple "tenants".
>
> Thanks much.
> Ruth
>
>
> On 1/27/12 1:40 AM, Hans Bakker wrote:
>
>> Problem:
>> ------------
>> 1. If you would like to have different tenants on your system and want to
>> have different property settings for each tenant laike language or currency
>> etc, that is currently not supported.
>> 2. the properties are not very well organized, to say the least.
>>
>> Proposal:
>> ------------
>> 1. create the following entity SystemProperty with fields:
>> systemPropertyId(key)
>> parentSystemPropertyId
>> description
>> ofbizPropertyName(index)
>> systemPropertyValue
>>
>> Initially load the systemPropertyid from the ofbiz propertyId so
>> accounting.fixedasset.**autocreate=Y will have 3 records using the
>> parent id but only the lowest level will have the accounting.fixedasset.*
>> *autocreate name and value=Y
>>
>> when we have this working we can slowly reorganize these records without
>> having to change the programs.
>>
>> 2. add the delegator parameter to the getPropertyValue method and change
>> the method system wide.
>> the getPropertyValue method will first look in this entity with the
>> provided delegator and when the property is null or not found, use the
>> properties file property as currently is done.
>> 3. resolve anywhere where this method is called and where the delegator
>> is not available.
>> 4. add a webtools option to set the properties.
>>
>> Please provide comments or counter proposals......
>>
>> Regards,
>> Hans
>>
>>
Re: proposal: overriding property setting per tenant.
Posted by Pierre Smits <pi...@gmail.com>.
Re 1: Sandbox
This is generaly done in larger organization wrt system integration testing
and education/training of endusers.
Re 2: With current version (trunk) of OFbiz this can be done. Keeping in
mind JIRA issue https://issues.apache.org/jira/browse/OFBIZ-4130 with
regards to privacy.
Regards,
Pierre
2012/1/27 Adrian Crum <ad...@sandglass-software.com>
> The use cases I can think of:
>
> 1. Implement a "sandbox" instance for users to learn on (with demo data),
> and also have a "live" instance (with live data). OFBiz users can learn in
> the sandbox without affecting live data, and then switch to the live
> instance.
> 2. Offer a customized version of OFBiz as SAAS, with each customer being a
> tenant.
>
> -Adrian
>
>
> On 1/27/2012 2:04 PM, Ruth Hoffman wrote:
>
>> Hi Hans, et al.
>> Could someone take a few minutes and explain to me the value of OFBiz
>> multi-tenancy? Why not just use SVN or other tool specifically designed to
>> manage multiple versions of a project where a project is an OFBiz tenant.
>> The problem as I see it is that the OFBiz multi-tenant implementation does
>> not include the concept of a "landlord". Nor does it have any notion of how
>> to handle specific tenant useage. It assumes that all tenants are equal and
>> have the same system level requirements. Are they? Maybe I just don't
>> understand the use-case for it.
>>
>> Han's example is just one of the challenges presented when using this
>> approach to host multiple "tenants".
>>
>> Thanks much.
>> Ruth
>>
>> On 1/27/12 1:40 AM, Hans Bakker wrote:
>>
>>> Problem:
>>> ------------
>>> 1. If you would like to have different tenants on your system and want
>>> to have different property settings for each tenant laike language or
>>> currency etc, that is currently not supported.
>>> 2. the properties are not very well organized, to say the least.
>>>
>>> Proposal:
>>> ------------
>>> 1. create the following entity SystemProperty with fields:
>>> systemPropertyId(key)
>>> parentSystemPropertyId
>>> description
>>> ofbizPropertyName(index)
>>> systemPropertyValue
>>>
>>> Initially load the systemPropertyid from the ofbiz propertyId so
>>> accounting.fixedasset.**autocreate=Y will have 3 records using the
>>> parent id but only the lowest level will have the accounting.fixedasset.
>>> **autocreate name and value=Y
>>>
>>> when we have this working we can slowly reorganize these records without
>>> having to change the programs.
>>>
>>> 2. add the delegator parameter to the getPropertyValue method and change
>>> the method system wide.
>>> the getPropertyValue method will first look in this entity with the
>>> provided delegator and when the property is null or not found, use the
>>> properties file property as currently is done.
>>> 3. resolve anywhere where this method is called and where the delegator
>>> is not available.
>>> 4. add a webtools option to set the properties.
>>>
>>> Please provide comments or counter proposals......
>>>
>>> Regards,
>>> Hans
>>>
>>>
Re: proposal: overriding property setting per tenant.
Posted by Adrian Crum <ad...@sandglass-software.com>.
The use cases I can think of:
1. Implement a "sandbox" instance for users to learn on (with demo
data), and also have a "live" instance (with live data). OFBiz users can
learn in the sandbox without affecting live data, and then switch to the
live instance.
2. Offer a customized version of OFBiz as SAAS, with each customer being
a tenant.
-Adrian
On 1/27/2012 2:04 PM, Ruth Hoffman wrote:
> Hi Hans, et al.
> Could someone take a few minutes and explain to me the value of OFBiz
> multi-tenancy? Why not just use SVN or other tool specifically
> designed to manage multiple versions of a project where a project is
> an OFBiz tenant. The problem as I see it is that the OFBiz
> multi-tenant implementation does not include the concept of a
> "landlord". Nor does it have any notion of how to handle specific
> tenant useage. It assumes that all tenants are equal and have the same
> system level requirements. Are they? Maybe I just don't understand the
> use-case for it.
>
> Han's example is just one of the challenges presented when using this
> approach to host multiple "tenants".
>
> Thanks much.
> Ruth
>
> On 1/27/12 1:40 AM, Hans Bakker wrote:
>> Problem:
>> ------------
>> 1. If you would like to have different tenants on your system and
>> want to have different property settings for each tenant laike
>> language or currency etc, that is currently not supported.
>> 2. the properties are not very well organized, to say the least.
>>
>> Proposal:
>> ------------
>> 1. create the following entity SystemProperty with fields:
>> systemPropertyId(key)
>> parentSystemPropertyId
>> description
>> ofbizPropertyName(index)
>> systemPropertyValue
>>
>> Initially load the systemPropertyid from the ofbiz propertyId so
>> accounting.fixedasset.autocreate=Y will have 3 records using the
>> parent id but only the lowest level will have the
>> accounting.fixedasset.autocreate name and value=Y
>>
>> when we have this working we can slowly reorganize these records
>> without having to change the programs.
>>
>> 2. add the delegator parameter to the getPropertyValue method and
>> change the method system wide.
>> the getPropertyValue method will first look in this entity with the
>> provided delegator and when the property is null or not found, use
>> the properties file property as currently is done.
>> 3. resolve anywhere where this method is called and where the
>> delegator is not available.
>> 4. add a webtools option to set the properties.
>>
>> Please provide comments or counter proposals......
>>
>> Regards,
>> Hans
>>
Re: proposal: overriding property setting per tenant.
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Hans, et al.
Could someone take a few minutes and explain to me the value of OFBiz
multi-tenancy? Why not just use SVN or other tool specifically designed
to manage multiple versions of a project where a project is an OFBiz
tenant. The problem as I see it is that the OFBiz multi-tenant
implementation does not include the concept of a "landlord". Nor does it
have any notion of how to handle specific tenant useage. It assumes that
all tenants are equal and have the same system level requirements. Are
they? Maybe I just don't understand the use-case for it.
Han's example is just one of the challenges presented when using this
approach to host multiple "tenants".
Thanks much.
Ruth
On 1/27/12 1:40 AM, Hans Bakker wrote:
> Problem:
> ------------
> 1. If you would like to have different tenants on your system and want
> to have different property settings for each tenant laike language or
> currency etc, that is currently not supported.
> 2. the properties are not very well organized, to say the least.
>
> Proposal:
> ------------
> 1. create the following entity SystemProperty with fields:
> systemPropertyId(key)
> parentSystemPropertyId
> description
> ofbizPropertyName(index)
> systemPropertyValue
>
> Initially load the systemPropertyid from the ofbiz propertyId so
> accounting.fixedasset.autocreate=Y will have 3 records using the
> parent id but only the lowest level will have the
> accounting.fixedasset.autocreate name and value=Y
>
> when we have this working we can slowly reorganize these records
> without having to change the programs.
>
> 2. add the delegator parameter to the getPropertyValue method and
> change the method system wide.
> the getPropertyValue method will first look in this entity with the
> provided delegator and when the property is null or not found, use the
> properties file property as currently is done.
> 3. resolve anywhere where this method is called and where the
> delegator is not available.
> 4. add a webtools option to set the properties.
>
> Please provide comments or counter proposals......
>
> Regards,
> Hans
>
Re: proposal: overriding property setting per tenant.
Posted by Hans Bakker <ma...@antwebsystems.com>.
Then I am always thinking, why didn't you contribute it?
On 01/27/2012 02:49 PM, pierre.gaudin wrote:
> Yes this is a good idea. We did such a modification into an old OFbiz
> project and it was very useful.
>
> On 27/01/2012 07:40, Hans Bakker wrote:
>> Problem:
>> ------------
>> 1. If you would like to have different tenants on your system and
>> want to have different property settings for each tenant laike
>> language or currency etc, that is currently not supported.
>> 2. the properties are not very well organized, to say the least.
>>
>> Proposal:
>> ------------
>> 1. create the following entity SystemProperty with fields:
>> systemPropertyId(key)
>> parentSystemPropertyId
>> description
>> ofbizPropertyName(index)
>> systemPropertyValue
>>
>> Initially load the systemPropertyid from the ofbiz propertyId so
>> accounting.fixedasset.autocreate=Y will have 3 records using the
>> parent id but only the lowest level will have the
>> accounting.fixedasset.autocreate name and value=Y
>>
>> when we have this working we can slowly reorganize these records
>> without having to change the programs.
>>
>> 2. add the delegator parameter to the getPropertyValue method and
>> change the method system wide.
>> the getPropertyValue method will first look in this entity with the
>> provided delegator and when the property is null or not found, use
>> the properties file property as currently is done.
>> 3. resolve anywhere where this method is called and where the
>> delegator is not available.
>> 4. add a webtools option to set the properties.
>>
>> Please provide comments or counter proposals......
>>
>> Regards,
>> Hans
>>
>
Re: proposal: overriding property setting per tenant.
Posted by Pierre Smits <pi...@gmail.com>.
Hi Charles,
Could you please state with which version this is committed to OFBiz trunk?
I am very much interested in this subject and didn't find anything related
when I upgraded to the latest version this morning.
Regards,
Pierre
2012/1/31 STELTZLEN Charles <ch...@nereide.biz>
> Hi,
>
>
> Yes this is a good idea. We did such a modification into an old OFbiz
>> project and it was very useful.
>>
>
> It's now updated for ofbiz trunk and package as an addon ;-)
>
> We have implemented a new entity called GeneralPropertyAttribute that
> allow us to manage dynamic properties.
>
> That solve multi-tenant issues and allow us to overload classical file
> properties
> (new usage of getPropertyValue search properties in bdd, and, if it
> doesn't exist, get classical property from file).
>
> We also use a fromDate/thruDate to be able to disabled it.
>
> I will send you a patch in the next few days.
>
> Charles
>
> PS: see comments below
>
>
>
>> On 27/01/2012 07:40, Hans Bakker wrote:
>>
>>> Problem:
>>> ------------
>>> 1. If you would like to have different tenants on your system and want
>>> to have different property settings for each tenant laike language or
>>> currency etc, that is currently not supported.
>>> 2. the properties are not very well organized, to say the least.
>>>
>>> Proposal:
>>> ------------
>>> 1. create the following entity SystemProperty with fields:
>>> systemPropertyId(key)
>>> parentSystemPropertyId
>>> description
>>> ofbizPropertyName(index)
>>> systemPropertyValue
>>>
>> In your case : GeneralPropertyAttribute
> propKeyId (key)
> fromDate (key)
> thruDate
> propValue
> propName
> propDomain
> resource
> comments
>
> The propKeyId is same value as property index in properties files.
> We don't use a system of parent record (I don't see the functional
> purpose).
> But we add a field "propDomain" that allow us to indicate a domain, just
> for search/filter or simple classification.
> As I said above, we also use a fromDate/thruDate to be able to disabled it.
>
> For instant, field "resource" is added to keep transparency between both
> properties systems,
> and to set property file name that will be overloaded.
>
> Not sure that's the best way...
>
>
>
>>> Initially load the systemPropertyid from the ofbiz propertyId so
>>> accounting.fixedasset.**autocreate=Y will have 3 records using the
>>> parent id but only the lowest level will have the accounting.fixedasset.
>>> **autocreate name and value=Y
>>>
>>> In your implementation, no initial load.
>
> when we have this working we can slowly reorganize these records without
>>> having to change the programs.
>>>
>>> 2. add the delegator parameter to the getPropertyValue method and change
>>> the method system wide.
>>> the getPropertyValue method will first look in this entity with the
>>> provided delegator and when the property is null or not found, use the
>>> properties file property as currently is done.
>>>
>> Exactly what we do.
>
> 3. resolve anywhere where this method is called and where the delegator
>>> is not available.
>>>
>> This part need some improvement. Depends on what you want.
>
> 4. add a webtools option to set the properties.
>>>
>> In the addon, we have a portal page with a simple portlet for
> GeneralPropertyAttribute
>
>
>>> Please provide comments or counter proposals......
>>>
>>> Regards,
>>> Hans
>>>
>>> Thanks for your comments,
>
>
Re: proposal: overriding property setting per tenant.
Posted by STELTZLEN Charles <ch...@nereide.biz>.
Hi,
> Yes this is a good idea. We did such a modification into an old OFbiz
> project and it was very useful.
It's now updated for ofbiz trunk and package as an addon ;-)
We have implemented a new entity called GeneralPropertyAttribute that
allow us to manage dynamic properties.
That solve multi-tenant issues and allow us to overload classical file
properties
(new usage of getPropertyValue search properties in bdd, and, if it
doesn't exist, get classical property from file).
We also use a fromDate/thruDate to be able to disabled it.
I will send you a patch in the next few days.
Charles
PS: see comments below
>
> On 27/01/2012 07:40, Hans Bakker wrote:
>> Problem:
>> ------------
>> 1. If you would like to have different tenants on your system and
>> want to have different property settings for each tenant laike
>> language or currency etc, that is currently not supported.
>> 2. the properties are not very well organized, to say the least.
>>
>> Proposal:
>> ------------
>> 1. create the following entity SystemProperty with fields:
>> systemPropertyId(key)
>> parentSystemPropertyId
>> description
>> ofbizPropertyName(index)
>> systemPropertyValue
In your case : GeneralPropertyAttribute
propKeyId (key)
fromDate (key)
thruDate
propValue
propName
propDomain
resource
comments
The propKeyId is same value as property index in properties files.
We don't use a system of parent record (I don't see the functional purpose).
But we add a field "propDomain" that allow us to indicate a domain, just
for search/filter or simple classification.
As I said above, we also use a fromDate/thruDate to be able to disabled it.
For instant, field "resource" is added to keep transparency between both
properties systems,
and to set property file name that will be overloaded.
Not sure that's the best way...
>>
>> Initially load the systemPropertyid from the ofbiz propertyId so
>> accounting.fixedasset.autocreate=Y will have 3 records using the
>> parent id but only the lowest level will have the
>> accounting.fixedasset.autocreate name and value=Y
>>
In your implementation, no initial load.
>> when we have this working we can slowly reorganize these records
>> without having to change the programs.
>>
>> 2. add the delegator parameter to the getPropertyValue method and
>> change the method system wide.
>> the getPropertyValue method will first look in this entity with the
>> provided delegator and when the property is null or not found, use
>> the properties file property as currently is done.
Exactly what we do.
>> 3. resolve anywhere where this method is called and where the
>> delegator is not available.
This part need some improvement. Depends on what you want.
>> 4. add a webtools option to set the properties.
In the addon, we have a portal page with a simple portlet for
GeneralPropertyAttribute
>>
>> Please provide comments or counter proposals......
>>
>> Regards,
>> Hans
>>
Thanks for your comments,
Re: proposal: overriding property setting per tenant.
Posted by "pierre.gaudin" <pi...@nereide.fr>.
Yes this is a good idea. We did such a modification into an old OFbiz
project and it was very useful.
On 27/01/2012 07:40, Hans Bakker wrote:
> Problem:
> ------------
> 1. If you would like to have different tenants on your system and want
> to have different property settings for each tenant laike language or
> currency etc, that is currently not supported.
> 2. the properties are not very well organized, to say the least.
>
> Proposal:
> ------------
> 1. create the following entity SystemProperty with fields:
> systemPropertyId(key)
> parentSystemPropertyId
> description
> ofbizPropertyName(index)
> systemPropertyValue
>
> Initially load the systemPropertyid from the ofbiz propertyId so
> accounting.fixedasset.autocreate=Y will have 3 records using the
> parent id but only the lowest level will have the
> accounting.fixedasset.autocreate name and value=Y
>
> when we have this working we can slowly reorganize these records
> without having to change the programs.
>
> 2. add the delegator parameter to the getPropertyValue method and
> change the method system wide.
> the getPropertyValue method will first look in this entity with the
> provided delegator and when the property is null or not found, use the
> properties file property as currently is done.
> 3. resolve anywhere where this method is called and where the
> delegator is not available.
> 4. add a webtools option to set the properties.
>
> Please provide comments or counter proposals......
>
> Regards,
> Hans
>