[OFBiz] Users - Application for industry regulator ...

[Ian Gilbert]

Good evening list :)

I am hoping to use Ofbiz as a base for an industry regulator.  It has the
following characteristics.

1.  There are 100 member companies.  80 of these are unique whilst the
others are 'branches' of other members. These are nearly all importer
organisations.
2.  The requirement is to allow 'members' to add product and company
information for the production of a 'catalog'.  Historically this catalog
has been printed out once a year and sent to members.  It is more a list
of members information than a list of product information but they would
like to include some of this information in the printed catalog and allow
access to the other information through the website.
3.  Access to this information would be via subscription (I think that
this might work in the same way as the subscription service to access the
Ofbiz docs) which is all the 'ecommerce' portion of the site would sell
(i.e. it would not sell the products from all the different companies).
4.  It is possible, although is not an initial requirement, that the
member companies might employ other functional business modules of Ofbiz.
5.  Although many of these companies source unique items, there are a
number of products that are shared amongst member stores.  In addition to
this, items are traded between stores.  In some cases the suppliers of
these stores have inventory that they would like displayed (and will pay
for this).

I am aware that support for Multi-companies in Ofbiz is not supported out
of the box and I agree with this position.

Is Ofbiz the correct choice for this deployment?  I have run Ofbiz for a
couple of small orgs in single company mode for some time but am having
some problems working out the implications.  There seem to be several
options that I could adopt.  I would like to get the opinions of those on
the list before starting.

The options that I see are:
1.  Use multiple instances of Ofbiz, one for each company, draw the
company contact information as well as any product information from
separate databases (probably going in 'above' Ofbiz).  Allow the
proprietors of the stores to maintain their own information (there is a
definite UI implication here).
2.  Use multiple instances of Ofbiz, one for each company, but store only
company information in this.  Have another instance - 'Industry Regulator'
which contains the product information.  In the future populate the
websites of the companies with products drawn from the 'Regulator'
instance (probably using WS).  Give each 'proprietor' access to their own
products and maybe separate these using categories.  Advantage is that
products are centralised making reporting easier.  Disadvantage is that
this seems a complex method of doing it and would require careful analysis
of the 'roles' allocated to proprietors (this is probably unavoidable
though).  In this case the actual company specific instances could be
gradually made available by module as the subscription model is developed
(e.g. For the lowest level of subs you would just be able to add people to
your system through the 'Party Manager' thereby giving them the ability to
add/modify/delete product info in the main instance whilst a higher level
might give you a trading site etc.,).  There remains issues with the UI as
NONE of these proprietors will be happy with conf file maintenance.  I am
happy to do this for three instances but 100?  This may cause maintenance
problems.
3.  Store the company details in a separate database and manage everything
through one 'Regulator' instance.  This would have the advantage of being
very simple but wouldn't be able to exploit the other elements of the
system unless we made a large number of mods which would, inevitably,
permanently fork our setup - something I am not keen to do as we lack
resource to support this even in the medium term.

Writing this has been useful.  I am now favouring number two but would
value other opinions and comment.  I will be happy to provide further
information on our setup if this would be considered helpful.

Thanks and very best wishes

Ian

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

Ian,

It seems like it all you are trying to do is gather information from  
them, or rather, have them maintain their own information, then maybe  
it is best to do a little customization of UI and/or permissions and  
let them login and create/update products (using the existing role  
limited catalog admin permissions), and use something like the  
ecommerce profile pages (perhaps in a new app, ie throw references/
view-maps to the screens in a new controller.xml file).

If they are going to be running other parts of their business or  
doing _anything_ other than entering this very specific information  
then you would probably want separate instances. If you might want to  
encourage them to run their own instances in the future, then maybe  
building a data push bridge with remote service calls as well as  
manual entry might be needed.

Best of luck, or as would be said there, cheers!
-David


On Oct 10, 2005, at 5:42 PM, Ian Gilbert wrote:

> Good evening list :)
>
> I am hoping to use Ofbiz as a base for an industry regulator.  It  
> has the
> following characteristics.
>
> 1.  There are 100 member companies.  80 of these are unique whilst the
> others are 'branches' of other members. These are nearly all importer
> organisations.
> 2.  The requirement is to allow 'members' to add product and company
> information for the production of a 'catalog'.  Historically this  
> catalog
> has been printed out once a year and sent to members.  It is more a  
> list
> of members information than a list of product information but they  
> would
> like to include some of this information in the printed catalog and  
> allow
> access to the other information through the website.
> 3.  Access to this information would be via subscription (I think that
> this might work in the same way as the subscription service to  
> access the
> Ofbiz docs) which is all the 'ecommerce' portion of the site would  
> sell
> (i.e. it would not sell the products from all the different  
> companies).
> 4.  It is possible, although is not an initial requirement, that the
> member companies might employ other functional business modules of  
> Ofbiz.
> 5.  Although many of these companies source unique items, there are a
> number of products that are shared amongst member stores.  In  
> addition to
> this, items are traded between stores.  In some cases the suppliers of
> these stores have inventory that they would like displayed (and  
> will pay
> for this).
>
> I am aware that support for Multi-companies in Ofbiz is not  
> supported out
> of the box and I agree with this position.
>
> Is Ofbiz the correct choice for this deployment?  I have run Ofbiz  
> for a
> couple of small orgs in single company mode for some time but am  
> having
> some problems working out the implications.  There seem to be several
> options that I could adopt.  I would like to get the opinions of  
> those on
> the list before starting.
>
> The options that I see are:
> 1.  Use multiple instances of Ofbiz, one for each company, draw the
> company contact information as well as any product information from
> separate databases (probably going in 'above' Ofbiz).  Allow the
> proprietors of the stores to maintain their own information (there  
> is a
> definite UI implication here).
> 2.  Use multiple instances of Ofbiz, one for each company, but  
> store only
> company information in this.  Have another instance - 'Industry  
> Regulator'
> which contains the product information.  In the future populate the
> websites of the companies with products drawn from the 'Regulator'
> instance (probably using WS).  Give each 'proprietor' access to  
> their own
> products and maybe separate these using categories.  Advantage is that
> products are centralised making reporting easier.  Disadvantage is  
> that
> this seems a complex method of doing it and would require careful  
> analysis
> of the 'roles' allocated to proprietors (this is probably unavoidable
> though).  In this case the actual company specific instances could be
> gradually made available by module as the subscription model is  
> developed
> (e.g. For the lowest level of subs you would just be able to add  
> people to
> your system through the 'Party Manager' thereby giving them the  
> ability to
> add/modify/delete product info in the main instance whilst a higher  
> level
> might give you a trading site etc.,).  There remains issues with  
> the UI as
> NONE of these proprietors will be happy with conf file  
> maintenance.  I am
> happy to do this for three instances but 100?  This may cause  
> maintenance
> problems.
> 3.  Store the company details in a separate database and manage  
> everything
> through one 'Regulator' instance.  This would have the advantage of  
> being
> very simple but wouldn't be able to exploit the other elements of the
> system unless we made a large number of mods which would, inevitably,
> permanently fork our setup - something I am not keen to do as we lack
> resource to support this even in the medium term.
>
> Writing this has been useful.  I am now favouring number two but would
> value other opinions and comment.  I will be happy to provide further
> information on our setup if this would be considered helpful.
>
> Thanks and very best wishes
>
> Ian
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Sykes]

Ian,

We've had to make similar decisions in the past, just to supplement
David's response, we were able to actually run multiple webapps for
different companies within a single OFBiz instance, each connecting to a
separate DB.

Of course with the large number of companies involved this may not be a
practical solution on it's own, but the advantage of course is that
setting up multiple instances is fairly straight forward if the apps are
already separated. You also have the added advantage of being able to
shift individual apps between different instances to help tune
performance, which is a far more frugal setup than a separate instance
for each company.

That being said, we made this choice on the basis that the number of
companies was never likely to exceed about 20. If I'd been faced with
100 companies, I suspect I would have opted for David's suggestion :-)

One more thing I noticed, in your second solution scenario, you describe
a multi instance setup with a separate instance for potentially shared
data, perhaps you could do this the other way around, i.e. have a
separate instance serving USER_LOGIN and such like data using multiple
delegator/DBs in a single instance as mentioned above and a second
instance for your shared data...

I hope that's useful...
--
Andrew Sykes <[hidden email]>
Sykes Development Ltd

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David Garrett]

Ian,

I have done a directory of businesses for an industry organisation.
 
The listings were implemented as products with extensions to the product
table for the contact and party info. Control of what could be edited used
the limited category admin permissions. We had a few options here - we
finally implemented a category for each user who needed to admin specific
products and used the Limited admin party role so that this user could edit
only the products in that category. Therefore this association needs to be
established. (Hope that made sense)

The public UI used the ecommerce category/product view mechanism. Th admin
site had simplified maintenance pages.

All this was done in one instance.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Ian Gilbert
Sent: Tuesday, 11 October 2005 9:43 AM
To: [hidden email]
Subject: [OFBiz] Users - Application for industry regulator ...

Good evening list :)

I am hoping to use Ofbiz as a base for an industry regulator.  It has the
following characteristics.

1.  There are 100 member companies.  80 of these are unique whilst the
others are 'branches' of other members. These are nearly all importer
organisations.
2.  The requirement is to allow 'members' to add product and company
information for the production of a 'catalog'.  Historically this catalog
has been printed out once a year and sent to members.  It is more a list of
members information than a list of product information but they would like
to include some of this information in the printed catalog and allow access
to the other information through the website.
3.  Access to this information would be via subscription (I think that this
might work in the same way as the subscription service to access the Ofbiz
docs) which is all the 'ecommerce' portion of the site would sell (i.e. it
would not sell the products from all the different companies).
4.  It is possible, although is not an initial requirement, that the member
companies might employ other functional business modules of Ofbiz.
5.  Although many of these companies source unique items, there are a number
of products that are shared amongst member stores.  In addition to this,
items are traded between stores.  In some cases the suppliers of these
stores have inventory that they would like displayed (and will pay for
this).

I am aware that support for Multi-companies in Ofbiz is not supported out of
the box and I agree with this position.

Is Ofbiz the correct choice for this deployment?  I have run Ofbiz for a
couple of small orgs in single company mode for some time but am having some
problems working out the implications.  There seem to be several options
that I could adopt.  I would like to get the opinions of those on the list
before starting.

The options that I see are:
1.  Use multiple instances of Ofbiz, one for each company, draw the company
contact information as well as any product information from separate
databases (probably going in 'above' Ofbiz).  Allow the proprietors of the
stores to maintain their own information (there is a definite UI implication
here).
2.  Use multiple instances of Ofbiz, one for each company, but store only
company information in this.  Have another instance - 'Industry Regulator'
which contains the product information.  In the future populate the websites
of the companies with products drawn from the 'Regulator'
instance (probably using WS).  Give each 'proprietor' access to their own
products and maybe separate these using categories.  Advantage is that
products are centralised making reporting easier.  Disadvantage is that this
seems a complex method of doing it and would require careful analysis of the
'roles' allocated to proprietors (this is probably unavoidable though).  In
this case the actual company specific instances could be gradually made
available by module as the subscription model is developed (e.g. For the
lowest level of subs you would just be able to add people to your system
through the 'Party Manager' thereby giving them the ability to
add/modify/delete product info in the main instance whilst a higher level
might give you a trading site etc.,).  There remains issues with the UI as
NONE of these proprietors will be happy with conf file maintenance.  I am
happy to do this for three instances but 100?  This may cause maintenance
problems.
3.  Store the company details in a separate database and manage everything
through one 'Regulator' instance.  This would have the advantage of being
very simple but wouldn't be able to exploit the other elements of the system
unless we made a large number of mods which would, inevitably, permanently
fork our setup - something I am not keen to do as we lack resource to
support this even in the medium term.

Writing this has been useful.  I am now favouring number two but would value
other opinions and comment.  I will be happy to provide further information
on our setup if this would be considered helpful.

Thanks and very best wishes

Ian

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users


 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Ian Gilbert]

We have tried to duplicate the permissions in the security group called
'viewadmin' in our own security group and then tried to log in resulting
in an error message 'not enough permissions'.  We then revert to the
'viewadmin' and it then works ok.  This is not a consistent error and we
have noticed that if it is left for a bit then it seems to start working.

Do security group permissions and party group permissions take place
immediately?

Thanks and very best wishes

Ian

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Ian Gilbert]

Thanks very much to everyone who responded to this.  It has been very
helpful and I've decided to have one 'retailer' whose products are split
up and managed by a number of 'Producers'.  This will, in effect, work the
way that David has suggested I think and I'm just playing with the latest
Sequoia build to see if I can realise this.

I would like to find out more about how the permissions work as this will
be central to this project.  In particular the existing 'limited catalog'
permissions as you mention below do, indeed, seem to be the way to go here
but I'm having a hard time trying to work out how these are set.

Is there any way to restrict access to individual catalogs using the
security groups?

Thanks and very best wishes

Ian


On Tue, October 11, 2005 3:51 am, David E. Jones wrote:
>

> Ian,
>
>
> It seems like it all you are trying to do is gather information from
> them, or rather, have them maintain their own information, then maybe it is
> best to do a little customization of UI and/or permissions and let them
> login and create/update products (using the existing role limited catalog
> admin permissions), and use something like the ecommerce profile pages
> (perhaps in a new app, ie throw references/
> view-maps to the screens in a new controller.xml file).
>
> If they are going to be running other parts of their business or
> doing _anything_ other than entering this very specific information then
> you would probably want separate instances. If you might want to encourage
> them to run their own instances in the future, then maybe building a data
> push bridge with remote service calls as well as manual entry might be
> needed.
>
> Best of luck, or as would be said there, cheers!
> -David
>
>
>
> On Oct 10, 2005, at 5:42 PM, Ian Gilbert wrote:
>
>
>> Good evening list :)
>>
>>
>> I am hoping to use Ofbiz as a base for an industry regulator.  It
>> has the following characteristics.
>>
>> 1.  There are 100 member companies.  80 of these are unique whilst the
>> others are 'branches' of other members. These are nearly all importer
>%

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

These are cached and by default entries expire every 1/2 hour. If you  
want to make it happen sooner you can change the cache.properties  
file or use the webtools cache management page to clear it, or the  
entries page to clear the individual entry.

-David


On Oct 15, 2005, at 9:21 AM, Ian Gilbert wrote:

> We have tried to duplicate the permissions in the security group  
> called
> 'viewadmin' in our own security group and then tried to log in  
> resulting
> in an error message 'not enough permissions'.  We then revert to the
> 'viewadmin' and it then works ok.  This is not a consistent error  
> and we
> have noticed that if it is left for a bit then it seems to start  
> working.
>
> Do security group permissions and party group permissions take place
> immediately?
>
> Thanks and very best wishes
>
> Ian
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Ian Gilbert]

Thanks for that David.  That makes perfect sense.

I've been playing around with these for most of the day and it's been very
interesting indeed.  I hope to have some more questions tomorrow.

Very best wishes

Ian

On Sat, October 15, 2005 9:09 pm, David E. Jones wrote:
>

> These are cached and by default entries expire every 1/2 hour. If you
> want to make it happen sooner you can change the cache.properties file or
> use the webtools cache management page to clear it, or the entries page to
> clear the individual entry.
>
> -David
>
>
>
> On Oct 15, 2005, at 9:21 AM, Ian Gilbert wrote:
>
>
>> We have tried to duplicate the permissions in the security group
>> called 'viewadmin' in our own security group and then tried to log in
>> resulting in an error message 'not enough permissions'.  We then revert
>> to the 'viewadmin' and it then works ok.  This is not a consistent error
>>  and we have noticed that if it is left for a bit then it seems to start
>>  working.
>>
>> Do security group permissions and party group permissions take place
>> immediately?
>>
>> Thanks and very best wishes
>>
>>
>> Ian
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David Garrett]

Ian,

Permissions ...

Take a look at the login: ltdadmin and the category: TSTLTDADMIN
Plus
Security group: CATALOGADMIN_LTD
And permissions CATALOG_ROLE_UPDATE, CATALOG_ROLE_CREATE,
CATALOG_ROLE_DELETE

I would suggest one category for each Person containing the products they
can edit eg CAT_FOR_PTY_XXX and apply the catalogRole for PartyId: XXX and
Role: LTD_ADMIN(??or similar)

My recollection is that when editing a product you need either
CATALOG_ADMIN/UPDATE or CATALOG_ROLE_UPDATE on the **Category**

I'm not sure how this works on a Catalog basis ... But if you look at the
Test Catalog, it has the "Admin Allow(One)" Type.
 
David G

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Ian Gilbert
Sent: Sunday, 16 October 2005 1:34 AM
To: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Users - Application for industry regulator ...

Thanks very much to everyone who responded to this.  It has been very
helpful and I've decided to have one 'retailer' whose products are split up
and managed by a number of 'Producers'.  This will, in effect, work the way
that David has suggested I think and I'm just playing with the latest
Sequoia build to see if I can realise this.

I would like to find out more about how the permissions work as this will be
central to this project.  In particular the existing 'limited catalog'
permissions as you mention below do, indeed, seem to be the way to go here
but I'm having a hard time trying to work out how these are set.

Is there any way to restrict access to individual catalogs using the
security groups?

Thanks and very best wishes

Ian


On Tue, October 11, 2005 3:51 am, David E. Jones wrote:
>

> Ian,
>
>
> It seems like it all you are trying to do is gather information from
> them, or rather, have them maintain their own information, then maybe
> it is best to do a little customization of UI and/or permissions and
> let them login and create/update products (using the existing role
> limited catalog admin permissions), and use something like the
> ecommerce profile pages (perhaps in a new app, ie throw references/
> view-maps to the screens in a new controller.xml file).
>
> If they are going to be running other parts of their business or doing
> _anything_ other than entering this very specific information then you
> would probably want separate instances. If you might want to encourage
> them to run their own instances in the future, then maybe building a
> data push bridge with remote service calls as well as manual entry
> might be needed.
>
> Best of luck, or as would be said there, cheers!
> -David
>
>
>
> On Oct 10, 2005, at 5:42 PM, Ian Gilbert wrote:
>
>
>> Good evening list :)
>>
>>
>> I am hoping to use Ofbiz as a base for an industry regulator.  It has
>> the following characteristics.
>>
>> 1.  There are 100 member companies.  80 of these are unique whilst
>> the others are 'branches' of other members. These are nearly all
>> importer
>%

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users


 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Ian Gilbert]

Hi again,

Thanks for the responses on this.  I have had some time to look at these
but am still curious to know if it is possible to restrict access to
'catalogs' based on username?  It is not neccessary for the users of this
system to have access to any other components (at this time) other than
'party', 'catalog' and 'ecommerce' but in each case their views will have
to be dependent of their usernames.  Although all users (once logged in)
will have 'view' rights over all the products, we have to ensure that
amendments and additions can only be carried out by the specific company
representatives.

Given a successful launch we see scope for expanding this so each company
would have their own instance but at the moment this is unaffordable and,
I suspect, more complex than the situation requires.

I am investigating the documentation about security permissions over the
next couple of days.  Forgive me if this is detailed there.

Thanks and very best wishes

Ian Gilbert


 On Tue, October 11, 2005 3:51 am, David E. Jones wrote:
>

> Ian,
>
>
> It seems like it all you are trying to do is gather information from
> them, or rather, have them maintain their own information, then maybe it is
> best to do a little customization of UI and/or permissions and let them
> login and create/update products (using the existing role limited catalog
> admin permissions), and use something like the ecommerce profile pages
> (perhaps in a new app, ie throw references/
> view-maps to the screens in a new controller.xml file).
>
> If they are going to be running other parts of their business or
> doing _anything_ other than entering this very specific information then
> you would probably want separate instances. If you might want to encourage
> them to run their own instances in the future, then maybe building a data
> push bridge with remote service calls as well as manual entry might be
> needed.
>
> Best of luck, or as would be said there, cheers!
> -David
>
>
>
> On Oct 10, 2005, at 5:42 PM, Ian Gilbert wrote:
>
>
>> Good evening list :)
>>
>>
>> I am hoping to use Ofbiz as a base for an industry regulator.  It
>> has the following characteristics.
>>
>> 1.  There are 100 member companies.  80 of these are unique whilst the
>> others are 'branches' of other members. These are nearly all importer
>> organisations. 2.  The requirement is to allow 'members' to add product
>> and company information for the production of a 'catalog'.  Historically
>> this catalog has been printed out once a year and sent to members.  It is
>> more a list of members information than a list of product information but
>> they would like to include some of this information in the printed
>> catalog and allow access to the other information through the website. 3.
>> Access to this information would be via subscription (I think that
>> this might work in the same way as the subscription service to access the
>>  Ofbiz docs) which is all the 'ecommerce' portion of the site would
>> sell (i.e. it would not sell the products from all the different
>> companies). 4.  It is possible, although is not an initial requirement,
>> that the member companies might employ other functional business modules
>> of Ofbiz.
>> 5.  Although many of these companies source unique items, there are a
>> number of products that are shared amongst member stores.  In addition to
>>  this, items are traded between stores.  In some cases the suppliers of
>>  these stores have inventory that they would like displayed (and will
>> pay for this).
>>
>> I am aware that support for Multi-companies in Ofbiz is not
>> supported out of the box and I agree with this position.
>>
>> Is Ofbiz the correct choice for this deployment?  I have run Ofbiz
>> for a couple of small orgs in single company mode for some time but am
>> having some problems working out the implications.  There seem to be
>> several options that I could adopt.  I would like to get the opinions of
>>  those on the list before starting.
>>
>> The options that I see are:
>> 1.  Use multiple instances of Ofbiz, one for each company, draw the
>> company contact information as well as any product information from
>> separate databases (probably going in 'above' Ofbiz).  Allow the
>> proprietors of the stores to maintain their own information (there is a
>> definite UI implication here). 2.  Use multiple instances of Ofbiz, one
>> for each company, but store only company information in this.  Have
>> another instance - 'Industry Regulator'
>> which contains the product information.  In the future populate the
>> websites of the companies with products drawn from the 'Regulator'
>> instance (probably using WS).  Give each 'proprietor' access to their
>> own products and maybe separate these using categories.  Advantage is
>> that products are centralised making reporting easier.  Disadvantage is
>> that this seems a complex method of doing it and would require careful
>> analysis of the 'roles' allocated to proprietors (this is probably
>> unavoidable though).  In this case the actual company specific instances
>> could be gradually made available by module as the subscription model is
>>  developed (e.g. For the lowest level of subs you would just be able to
>> add people to your system through the 'Party Manager' thereby giving them
>> the ability to add/modify/delete product info in the main instance whilst
>> a higher level might give you a trading site etc.,).  There remains
>> issues with the UI as NONE of these proprietors will be happy with conf
>> file maintenance.  I am happy to do this for three instances but 100?
>> This may cause
>> maintenance problems. 3.  Store the company details in a separate database
>> and manage everything through one 'Regulator' instance.  This would have
>> the advantage of being very simple but wouldn't be able to exploit the
>> other elements of the system unless we made a large number of mods which
>> would, inevitably, permanently fork our setup - something I am not keen
>> to do as we lack resource to support this even in the medium term.
>>
>> Writing this has been useful.  I am now favouring number two but would
>> value other opinions and comment.  I will be happy to provide further
>> information on our setup if this would be considered helpful.
>>
>> Thanks and very best wishes
>>
>>
>> Ian
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users