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 <[email protected]>

> 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
>>>
>>>

Reply via email to