Planning the next releases

[Jacopo Cappellato-4]

Hi all,

I would like to discuss with you the short term plans for the upcoming releases.

Here is my proposal:

11.04:
* start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)

12.04:
* as originally planned, the new 12.04.03 can be released in the next month (March)

13.07:
* I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer? Should we issue a release earlier?

What do you think?

Regards,

Jacopo

[Jacques Le Roux]

I agree for 11 and 12. I have no clear ideas on 13, I see nothing blocking on my side
For the next freeze, I'd like to merge the SEO branch and hopefully commit the Solr component before we freeze

Jacques

On Monday, February 10, 2014 9:32 AM, [hidden email] wrote

> Hi all,
>
> I would like to discuss with you the short term plans for the upcoming releases.
>
> Here is my proposal:
>
> 11.04:
> * start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)
>
> 12.04:
> * as originally planned, the new 12.04.03 can be released in the next month (March)
>
> 13.07:
> * I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer?
> Should we issue a release earlier?
>
> What do you think?
>
> Regards,
>
> Jacopo

[Adrian Crum-3]

That all sounds good to me. I don't see any need to wait on 13. From my
perspective, the sooner we release it, the sooner users will (hopefully)
upgrade from the older versions.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:

> Hi all,
>
> I would like to discuss with you the short term plans for the upcoming releases.
>
> Here is my proposal:
>
> 11.04:
> * start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)
>
> 12.04:
> * as originally planned, the new 12.04.03 can be released in the next month (March)
>
> 13.07:
> * I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer? Should we issue a release earlier?
>
> What do you think?
>
> Regards,
>
> Jacopo
>

[Jacopo Cappellato-4]

Ok, thank you for the feedback.
I'd say we can start the process with 11.04 and afterward with 12.04 and finally 13.07: in a few weeks we will have three new releases.

Jacopo

On Feb 10, 2014, at 3:51 PM, Adrian Crum <[hidden email]> wrote:

> That all sounds good to me. I don't see any need to wait on 13. From my perspective, the sooner we release it, the sooner users will (hopefully) upgrade from the older versions.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:
>> Hi all,
>>
>> I would like to discuss with you the short term plans for the upcoming releases.
>>
>> Here is my proposal:
>>
>> 11.04:
>> * start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)
>>
>> 12.04:
>> * as originally planned, the new 12.04.03 can be released in the next month (March)
>>
>> 13.07:
>> * I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer? Should we issue a release earlier?
>>
>> What do you think?
>>
>> Regards,
>>
>> Jacopo
>>

[Jacopo Cappellato-4]

Or actually, just to follow a bit more closely our tentative plan we can follow the order:
11.04
13.07
12.04

Jacopo

On Feb 12, 2014, at 11:09 AM, Jacopo Cappellato <[hidden email]> wrote:

> Ok, thank you for the feedback.
> I'd say we can start the process with 11.04 and afterward with 12.04 and finally 13.07: in a few weeks we will have three new releases.
>
> Jacopo
>
> On Feb 10, 2014, at 3:51 PM, Adrian Crum <[hidden email]> wrote:
>
>> That all sounds good to me. I don't see any need to wait on 13. From my perspective, the sooner we release it, the sooner users will (hopefully) upgrade from the older versions.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:
>>> Hi all,
>>>
>>> I would like to discuss with you the short term plans for the upcoming releases.
>>>
>>> Here is my proposal:
>>>
>>> 11.04:
>>> * start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)
>>>
>>> 12.04:
>>> * as originally planned, the new 12.04.03 can be released in the next month (March)
>>>
>>> 13.07:
>>> * I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer? Should we issue a release earlier?
>>>
>>> What do you think?
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>

[Jacopo Cappellato-4]

Are we ready to start the preparation of the first 13.07 release and then vote for it? Let me know your opinions, I personally don't have a strong preference.

Jacopo

On Feb 12, 2014, at 11:38 AM, Jacopo Cappellato <[hidden email]> wrote:

> Or actually, just to follow a bit more closely our tentative plan we can follow the order:
> 11.04
> 13.07
> 12.04
>
> Jacopo
>
> On Feb 12, 2014, at 11:09 AM, Jacopo Cappellato <[hidden email]> wrote:
>
>> Ok, thank you for the feedback.
>> I'd say we can start the process with 11.04 and afterward with 12.04 and finally 13.07: in a few weeks we will have three new releases.
>>
>> Jacopo
>>
>> On Feb 10, 2014, at 3:51 PM, Adrian Crum <[hidden email]> wrote:
>>
>>> That all sounds good to me. I don't see any need to wait on 13. From my perspective, the sooner we release it, the sooner users will (hopefully) upgrade from the older versions.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:
>>>> Hi all,
>>>>
>>>> I would like to discuss with you the short term plans for the upcoming releases.
>>>>
>>>> Here is my proposal:
>>>>
>>>> 11.04:
>>>> * start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)
>>>>
>>>> 12.04:
>>>> * as originally planned, the new 12.04.03 can be released in the next month (March)
>>>>
>>>> 13.07:
>>>> * I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer? Should we issue a release earlier?
>>>>
>>>> What do you think?
>>>>
>>>> Regards,
>>>>
>>>> Jacopo
>>>>
>>
>

[Pierre Smits]

As issues OFBIZ-4130 <https://issues.apache.org/jira/browse/OFBIZ-4130> and
OFBIZ-5319 <https://issues.apache.org/jira/browse/OFBIZ-5319> aren't
resolved I am not in favour of releasing it, given the implications
regarding the multi-tenancy aspect.

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Jacques Le Roux]

I'm neutral as well.

I'm only concerned by the next freeze, where I'd like to merge the SEO branch and hopefully commit the Solr component before we freeze (and maybe some
other stuff I don't remember at the moment)

Jacques

Le 24/02/2014 16:51, Jacopo Cappellato a écrit :

> Are we ready to start the preparation of the first 13.07 release and then vote for it? Let me know your opinions, I personally don't have a strong preference.
>
> Jacopo
>
> On Feb 12, 2014, at 11:38 AM, Jacopo Cappellato <[hidden email]> wrote:
>
>> Or actually, just to follow a bit more closely our tentative plan we can follow the order:
>> 11.04
>> 13.07
>> 12.04
>>
>> Jacopo
>>
>> On Feb 12, 2014, at 11:09 AM, Jacopo Cappellato <[hidden email]> wrote:
>>
>>> Ok, thank you for the feedback.
>>> I'd say we can start the process with 11.04 and afterward with 12.04 and finally 13.07: in a few weeks we will have three new releases.
>>>
>>> Jacopo
>>>
>>> On Feb 10, 2014, at 3:51 PM, Adrian Crum <[hidden email]> wrote:
>>>
>>>> That all sounds good to me. I don't see any need to wait on 13. From my perspective, the sooner we release it, the sooner users will (hopefully) upgrade from the older versions.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:
>>>>> Hi all,
>>>>>
>>>>> I would like to discuss with you the short term plans for the upcoming releases.
>>>>>
>>>>> Here is my proposal:
>>>>>
>>>>> 11.04:
>>>>> * start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)
>>>>>
>>>>> 12.04:
>>>>> * as originally planned, the new 12.04.03 can be released in the next month (March)
>>>>>
>>>>> 13.07:
>>>>> * I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer? Should we issue a release earlier?
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jacopo
>>>>>
>
>

[Jacques Le Roux]

Hi Pierre,

OFBIZ-4130 is a (still disputed, at least by Hans) bug so it could be committed after the release in the branch and be part of a minor release
For OFBIZ-5319 it's the same, we can't wait to release if we have no patch...

Jacques

Le 25/02/2014 09:24, Pierre Smits a écrit :

> As issues OFBIZ-4130 <https://issues.apache.org/jira/browse/OFBIZ-4130> and
> OFBIZ-5319 <https://issues.apache.org/jira/browse/OFBIZ-5319> aren't
> resolved I am not in favour of releasing it, given the implications
> regarding the multi-tenancy aspect.
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

[Jacopo Cappellato-4]

Considering that the last release branch (13.07) was created in July 2013, and after that we also backported a series of refactoring, we will probably wait for a few months before creating the new one: this could happen sometimes during the summer or early autumn.
As regards the Solr component: even if we will decide to commit it it will go in the specialpurpose folder and then will not be part of the release branch.

Jacopo

On Feb 25, 2014, at 10:03 AM, Jacques Le Roux <[hidden email]> wrote:

> I'm neutral as well.
>
> I'm only concerned by the next freeze, where I'd like to merge the SEO branch and hopefully commit the Solr component before we freeze (and maybe some other stuff I don't remember at the moment)
>
> Jacques
>
> Le 24/02/2014 16:51, Jacopo Cappellato a écrit :
>> Are we ready to start the preparation of the first 13.07 release and then vote for it? Let me know your opinions, I personally don't have a strong preference.
>>
>> Jacopo
>>
>> On Feb 12, 2014, at 11:38 AM, Jacopo Cappellato <[hidden email]> wrote:
>>
>>> Or actually, just to follow a bit more closely our tentative plan we can follow the order:
>>> 11.04
>>> 13.07
>>> 12.04
>>>
>>> Jacopo
>>>
>>> On Feb 12, 2014, at 11:09 AM, Jacopo Cappellato <[hidden email]> wrote:
>>>
>>>> Ok, thank you for the feedback.
>>>> I'd say we can start the process with 11.04 and afterward with 12.04 and finally 13.07: in a few weeks we will have three new releases.
>>>>
>>>> Jacopo
>>>>
>>>> On Feb 10, 2014, at 3:51 PM, Adrian Crum <[hidden email]> wrote:
>>>>
>>>>> That all sounds good to me. I don't see any need to wait on 13. From my perspective, the sooner we release it, the sooner users will (hopefully) upgrade from the older versions.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I would like to discuss with you the short term plans for the upcoming releases.
>>>>>>
>>>>>> Here is my proposal:
>>>>>>
>>>>>> 11.04:
>>>>>> * start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)
>>>>>>
>>>>>> 12.04:
>>>>>> * as originally planned, the new 12.04.03 can be released in the next month (March)
>>>>>>
>>>>>> 13.07:
>>>>>> * I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer? Should we issue a release earlier?
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>
>>

[Pierre Smits]

Jacques,

As I have stated in the comments regarding OFBIZ-4130, Hans has is own
solution in his own environment (growerp). Based on that he is stating that
there is no issue. Which is shortsighted, as many will not have that with a
default OFBiz implementation.

His setup is not OFBiz!

Furthermore, it seems he is not that keen (anymore) on addressing issues
raised in the community.

As for OFBIZ-5319, this will be resolved when the patch provided in
OFBiz-4130 has been committed.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Tue, Feb 25, 2014 at 10:22 AM, Jacopo Cappellato <
[hidden email]> wrote:

> Considering that the last release branch (13.07) was created in July 2013,
> and after that we also backported a series of refactoring, we will probably
> wait for a few months before creating the new one: this could happen
> sometimes during the summer or early autumn.
> As regards the Solr component: even if we will decide to commit it it will
> go in the specialpurpose folder and then will not be part of the release
> branch.
>
> Jacopo
>
> On Feb 25, 2014, at 10:03 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > I'm neutral as well.
> >
> > I'm only concerned by the next freeze, where I'd like to merge the SEO
> branch and hopefully commit the Solr component before we freeze (and maybe
> some other stuff I don't remember at the moment)
> >
> > Jacques
> >
> > Le 24/02/2014 16:51, Jacopo Cappellato a écrit :
> >> Are we ready to start the preparation of the first 13.07 release and
> then vote for it? Let me know your opinions, I personally don't have a
> strong preference.
> >>
> >> Jacopo
> >>
> >> On Feb 12, 2014, at 11:38 AM, Jacopo Cappellato <
> [hidden email]> wrote:
> >>
> >>> Or actually, just to follow a bit more closely our tentative plan we
> can follow the order:
> >>> 11.04
> >>> 13.07
> >>> 12.04
> >>>
> >>> Jacopo
> >>>
> >>> On Feb 12, 2014, at 11:09 AM, Jacopo Cappellato <
> [hidden email]> wrote:
> >>>
> >>>> Ok, thank you for the feedback.
> >>>> I'd say we can start the process with 11.04 and afterward with 12.04
> and finally 13.07: in a few weeks we will have three new releases.
> >>>>
> >>>> Jacopo
> >>>>
> >>>> On Feb 10, 2014, at 3:51 PM, Adrian Crum <
> [hidden email]> wrote:
> >>>>
> >>>>> That all sounds good to me. I don't see any need to wait on 13. From
> my perspective, the sooner we release it, the sooner users will (hopefully)
> upgrade from the older versions.
> >>>>>
> >>>>> Adrian Crum
> >>>>> Sandglass Software
> >>>>> www.sandglass-software.com
> >>>>>
> >>>>> On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I would like to discuss with you the short term plans for the
> upcoming releases.
> >>>>>>
> >>>>>> Here is my proposal:
> >>>>>>
> >>>>>> 11.04:
> >>>>>> * start the process of releasing the new bug fix release (11.04.04)
> now with the goal of releasing it during this month (February)
> >>>>>>
> >>>>>> 12.04:
> >>>>>> * as originally planned, the new 12.04.03 can be released in the
> next month (March)
> >>>>>>
> >>>>>> 13.07:
> >>>>>> * I don't have a strong preference: should we wait a few more
> months of stabilization and issue the first release in the summer? Should
> we issue a release earlier?
> >>>>>>
> >>>>>> What do you think?
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Jacopo
> >>>>>>
> >>
> >>
>
>

[Jacques Le Roux]

Ha yes, sorry Pierre, did not spot the patch. I will have a look at it

Jacques

Le 25/02/2014 12:11, Pierre Smits a écrit :

> Jacques,
>
> As I have stated in the comments regarding OFBIZ-4130, Hans has is own
> solution in his own environment (growerp). Based on that he is stating that
> there is no issue. Which is shortsighted, as many will not have that with a
> default OFBiz implementation.
>
> His setup is not OFBiz!
>
> Furthermore, it seems he is not that keen (anymore) on addressing issues
> raised in the community.
>
> As for OFBIZ-5319, this will be resolved when the patch provided in
> OFBiz-4130 has been committed.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Tue, Feb 25, 2014 at 10:22 AM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Considering that the last release branch (13.07) was created in July 2013,
>> and after that we also backported a series of refactoring, we will probably
>> wait for a few months before creating the new one: this could happen
>> sometimes during the summer or early autumn.
>> As regards the Solr component: even if we will decide to commit it it will
>> go in the specialpurpose folder and then will not be part of the release
>> branch.
>>
>> Jacopo
>>
>> On Feb 25, 2014, at 10:03 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> I'm neutral as well.
>>>
>>> I'm only concerned by the next freeze, where I'd like to merge the SEO
>> branch and hopefully commit the Solr component before we freeze (and maybe
>> some other stuff I don't remember at the moment)
>>> Jacques
>>>
>>> Le 24/02/2014 16:51, Jacopo Cappellato a écrit :
>>>> Are we ready to start the preparation of the first 13.07 release and
>> then vote for it? Let me know your opinions, I personally don't have a
>> strong preference.
>>>> Jacopo
>>>>
>>>> On Feb 12, 2014, at 11:38 AM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>>>> Or actually, just to follow a bit more closely our tentative plan we
>> can follow the order:
>>>>> 11.04
>>>>> 13.07
>>>>> 12.04
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Feb 12, 2014, at 11:09 AM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>>>>> Ok, thank you for the feedback.
>>>>>> I'd say we can start the process with 11.04 and afterward with 12.04
>> and finally 13.07: in a few weeks we will have three new releases.
>>>>>> Jacopo
>>>>>>
>>>>>> On Feb 10, 2014, at 3:51 PM, Adrian Crum <
>> [hidden email]> wrote:
>>>>>>> That all sounds good to me. I don't see any need to wait on 13. From
>> my perspective, the sooner we release it, the sooner users will (hopefully)
>> upgrade from the older versions.
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>> On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I would like to discuss with you the short term plans for the
>> upcoming releases.
>>>>>>>> Here is my proposal:
>>>>>>>>
>>>>>>>> 11.04:
>>>>>>>> * start the process of releasing the new bug fix release (11.04.04)
>> now with the goal of releasing it during this month (February)
>>>>>>>> 12.04:
>>>>>>>> * as originally planned, the new 12.04.03 can be released in the
>> next month (March)
>>>>>>>> 13.07:
>>>>>>>> * I don't have a strong preference: should we wait a few more
>> months of stabilization and issue the first release in the summer? Should
>> we issue a release earlier?
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>
>>

[Jacques Le Roux]

Sounds good to me, thanks for the specialpurpose folder not being part of the release branches reminder, I tend to forget it. This simplifies things
and was a good idea...

Jacques

Le 25/02/2014 10:22, Jacopo Cappellato a écrit :

> Considering that the last release branch (13.07) was created in July 2013, and after that we also backported a series of refactoring, we will probably wait for a few months before creating the new one: this could happen sometimes during the summer or early autumn.
> As regards the Solr component: even if we will decide to commit it it will go in the specialpurpose folder and then will not be part of the release branch.
>
> Jacopo
>
> On Feb 25, 2014, at 10:03 AM, Jacques Le Roux <[hidden email]> wrote:
>
>> I'm neutral as well.
>>
>> I'm only concerned by the next freeze, where I'd like to merge the SEO branch and hopefully commit the Solr component before we freeze (and maybe some other stuff I don't remember at the moment)
>>
>> Jacques
>>
>> Le 24/02/2014 16:51, Jacopo Cappellato a écrit :
>>> Are we ready to start the preparation of the first 13.07 release and then vote for it? Let me know your opinions, I personally don't have a strong preference.
>>>
>>> Jacopo
>>>
>>> On Feb 12, 2014, at 11:38 AM, Jacopo Cappellato <[hidden email]> wrote:
>>>
>>>> Or actually, just to follow a bit more closely our tentative plan we can follow the order:
>>>> 11.04
>>>> 13.07
>>>> 12.04
>>>>
>>>> Jacopo
>>>>
>>>> On Feb 12, 2014, at 11:09 AM, Jacopo Cappellato <[hidden email]> wrote:
>>>>
>>>>> Ok, thank you for the feedback.
>>>>> I'd say we can start the process with 11.04 and afterward with 12.04 and finally 13.07: in a few weeks we will have three new releases.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Feb 10, 2014, at 3:51 PM, Adrian Crum <[hidden email]> wrote:
>>>>>
>>>>>> That all sounds good to me. I don't see any need to wait on 13. From my perspective, the sooner we release it, the sooner users will (hopefully) upgrade from the older versions.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 2/10/2014 12:32 AM, Jacopo Cappellato wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I would like to discuss with you the short term plans for the upcoming releases.
>>>>>>>
>>>>>>> Here is my proposal:
>>>>>>>
>>>>>>> 11.04:
>>>>>>> * start the process of releasing the new bug fix release (11.04.04) now with the goal of releasing it during this month (February)
>>>>>>>
>>>>>>> 12.04:
>>>>>>> * as originally planned, the new 12.04.03 can be released in the next month (March)
>>>>>>>
>>>>>>> 13.07:
>>>>>>> * I don't have a strong preference: should we wait a few more months of stabilization and issue the first release in the summer? Should we issue a release earlier?
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>
>
>

[Jacopo Cappellato-4]

On Feb 25, 2014, at 12:11 PM, Pierre Smits <[hidden email]> wrote:

> As for OFBIZ-5319, this will be resolved when the patch provided in
> OFBiz-4130 has been committed.

I have tried to stay out of this because I am not particularly interested in the specific feature and I didn't want to be involved in a fight; however I see it is a long standing discussion and I would like to give it a try to resolve it.
Pierre, I see that your patch removes the configuration that assigns the Tenant* entities to the special org.ofbiz.tenant entity group; I have to admit that I don't fully understand the design that led to the creation of this group, but if we decide to get rid of it (as your patch implies) then we should also remove the check in GenericDelegator line 479:

        // to avoid infinite recursion, and to behave right for shared org.ofbiz.tenant entities, do nothing with the tenantId if the entityGroupName=org.ofbiz.tenant
        if (UtilValidate.isNotEmpty(this.delegatorTenantId) && !"org.ofbiz.tenant".equals(entityGroupName)) {

but before we do, I would like to understand the comment "to avoid infinite recursion, and to behave right for shared org.ofbiz.tenant entities...".
Pierre, have you been able to recreate the infinite recursion? under what conditions?

Jacopo

[Pierre Smits]

Jacopo,

I also would like to understand what that means. And what I don't
understand I can't recreate it also.

As far as conditions go, I will elaborate here under what conditions we
have tested the patch.

We created a virtual test setup consisting of 1 webserver (Apache HTTP) and
1 app server (consisting of Apache OFBiz, set up against derby) whereby the
connection and traffic between the 2 servers was with and through the AJP
protocol.

In that setup we created 5 tenants (with ./ant create-tenant).
And without the patch we tested all tenants accessing various apps and
components with Apache JMeter (and scripts). This included accessing
various functions in webtools as well.

Subsequently, we implemented the patch and ran the same tests again. Again
we had no problems accessing the various apps and components. The only
thing we didn't succeed in was accessing Tenant and TenantDataSource, when
being logged in as a tenant super-user.
However, when logged in as the admin of the master (without tenantId) we
were abel to access those entities and its data.

Both situations, being able to access the two entities and the data when
logged in as master admin and not being able to when logged in as a
tenant-admin, are as to be expected.

Now, I don't know what that means when having set up the domain name for a
tenant as the means to access the tenant environment. Apparently that has
been developed to have a unique uri per tenant. But we never have had any
use for that as we in our 3-tier productions setups have it as described as
above. This avoids us having to set up internal dns records to point to
specific tenants to connect to the app server.


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[hans_bakker]

On 26/02/14 04:48, Pierre Smits wrote:
> Jacopo,
>
> Now, I don't know what that means when having set up the domain name for a
> tenant as the means to access the tenant environment. Apparently that has
> been developed to have a unique uri per tenant.
this is an essential feature if you want run seperate domainnames
assigned to different tenants. Tenant delegator get selected
automatically dependent on the incoming domainname. Nice for frontend
e-commerce and backend, no need to specify the delegator) We even
extended this feature here to not only have a single domainname per
tenant but  to have multiple.
All these tenant patches are public and available in a seperate tenant
component where you can manage tenants in screens and add and delete and
refresh tenants whitout restarting the ofbiz system.
Check our gerrit system at http://gerrit.antwebsystems.com and
http://growerp.com which we are currently implementing for ourselves and
customers.

I did not yet try to add this to ofbiz seeing the extended discussion
which is required, to get it in. See the accounting ledger segments i
started last year august and is still not in the base ofbiz system.

So sorry i do not understand what this patch is supposed to do, for us
the system is working fine. On the other hand if this feature is not
blocking any existing system functions (like ledger segments also not
do) then i am fine with it.

Regards,
Hans

[Pierre Smits]

That is nice.... As a committer not being able to assess the issue unbiased
and not review the patch, but being against implementation of a correction
because the committer has no issues in his own modified setup...

I wonder how the community should interpret such actions...

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Wed, Feb 26, 2014 at 2:12 AM, Hans Bakker
<[hidden email]>wrote:

> On 26/02/14 04:48, Pierre Smits wrote:
>
>> Jacopo,
>>
>>
>> Now, I don't know what that means when having set up the domain name for a
>> tenant as the means to access the tenant environment. Apparently that has
>> been developed to have a unique uri per tenant.
>>
> this is an essential feature if you want run seperate domainnames assigned
> to different tenants. Tenant delegator get selected automatically dependent
> on the incoming domainname. Nice for frontend e-commerce and backend, no
> need to specify the delegator) We even extended this feature here to not
> only have a single domainname per tenant but  to have multiple.
> All these tenant patches are public and available in a seperate tenant
> component where you can manage tenants in screens and add and delete and
> refresh tenants whitout restarting the ofbiz system.
> Check our gerrit system at http://gerrit.antwebsystems.com and
> http://growerp.com which we are currently implementing for ourselves and
> customers.
>
> I did not yet try to add this to ofbiz seeing the extended discussion
> which is required, to get it in. See the accounting ledger segments i
> started last year august and is still not in the base ofbiz system.
>
> So sorry i do not understand what this patch is supposed to do, for us the
> system is working fine. On the other hand if this feature is not blocking
> any existing system functions (like ledger segments also not do) then i am
> fine with it.
>
> Regards,
> Hans
>
>
>

[Pierre Smits]

Furthermore, if and when a committer believes that he can use the
development branches of the project as his personal dumping ground of code
- as part of a means to sell his proposition to prospective customers -
without scrutiny by the members of the community he should have his sanity
checked.

And the community should decide whether it want such members to be
committers or even in the PMC.

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Wed, Feb 26, 2014 at 10:20 AM, Pierre Smits <[hidden email]>wrote:

> That is nice.... As a committer not being able to assess the issue
> unbiased and not review the patch, but being against implementation of a
> correction because the committer has no issues in his own modified setup...
>
> I wonder how the community should interpret such actions...
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Wed, Feb 26, 2014 at 2:12 AM, Hans Bakker <
> [hidden email]> wrote:
>
>> On 26/02/14 04:48, Pierre Smits wrote:
>>
>>> Jacopo,
>>>
>>>
>>> Now, I don't know what that means when having set up the domain name for
>>> a
>>> tenant as the means to access the tenant environment. Apparently that has
>>> been developed to have a unique uri per tenant.
>>>
>> this is an essential feature if you want run seperate domainnames
>> assigned to different tenants. Tenant delegator get selected automatically
>> dependent on the incoming domainname. Nice for frontend e-commerce and
>> backend, no need to specify the delegator) We even extended this feature
>> here to not only have a single domainname per tenant but  to have multiple.
>> All these tenant patches are public and available in a seperate tenant
>> component where you can manage tenants in screens and add and delete and
>> refresh tenants whitout restarting the ofbiz system.
>> Check our gerrit system at http://gerrit.antwebsystems.com and
>> http://growerp.com which we are currently implementing for ourselves and
>> customers.
>>
>> I did not yet try to add this to ofbiz seeing the extended discussion
>> which is required, to get it in. See the accounting ledger segments i
>> started last year august and is still not in the base ofbiz system.
>>
>> So sorry i do not understand what this patch is supposed to do, for us
>> the system is working fine. On the other hand if this feature is not
>> blocking any existing system functions (like ledger segments also not do)
>> then i am fine with it.
>>
>> Regards,
>> Hans
>>
>>
>>
>

[Jacopo Cappellato-4]

I have spent some time reviewing a part of the code and I have a few comments inline:

On Feb 25, 2014, at 10:48 PM, Pierre Smits <[hidden email]> wrote:

> Jacopo,
>
> I also would like to understand what that means. And what I don't
> understand I can't recreate it also.

the main design around the entities in the org.ofbiz.tenant group is the following: one separate small database is created to host all and only the org.ofbiz.tenant entities: these entities contain meta-data information for all tenants (url, db user and password to get access to each tenant db).
The patch you have proposed, by removing the org.ofbiz.tenant group, has the effect of moving these entities to the main OFBiz database: could you please check if you see these entities in your local box (with your patch applied)? Also, could you please check the content of these entities in the tenant specific databases and in the main database?

>
> As far as conditions go, I will elaborate here under what conditions we
> have tested the patch.
>
> We created a virtual test setup consisting of 1 webserver (Apache HTTP) and
> 1 app server (consisting of Apache OFBiz, set up against derby) whereby the
> connection and traffic between the 2 servers was with and through the AJP
> protocol.
>
> In that setup we created 5 tenants (with ./ant create-tenant).
> And without the patch we tested all tenants accessing various apps and
> components with Apache JMeter (and scripts). This included accessing
> various functions in webtools as well.

Are you saying that when you log in into Webtools with a tenantId you actually see the data from the main database rather than the data from the tenant specific db only? Is this happening for all the entities or just (as I suspect) for the entities in the org.ofbiz.tenant group?

Jacopo

>
> Subsequently, we implemented the patch and ran the same tests again. Again
> we had no problems accessing the various apps and components. The only
> thing we didn't succeed in was accessing Tenant and TenantDataSource, when
> being logged in as a tenant super-user.
> However, when logged in as the admin of the master (without tenantId) we
> were abel to access those entities and its data.
>
> Both situations, being able to access the two entities and the data when
> logged in as master admin and not being able to when logged in as a
> tenant-admin, are as to be expected.
>
> Now, I don't know what that means when having set up the domain name for a
> tenant as the means to access the tenant environment. Apparently that has
> been developed to have a unique uri per tenant. But we never have had any
> use for that as we in our 3-tier productions setups have it as described as
> above. This avoids us having to set up internal dns records to point to
> specific tenants to connect to the app server.
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com

[Pierre Smits]

Jacopo,

Jou said:

the main design around the entities in the org.ofbiz.tenant group is the
following: one separate small database is created to host all and only the
org.ofbiz.tenant entities: these entities contain meta-data information for
all tenants (url, db user and password to get access to each tenant db).


That is what I am saying. The database containing the details about each
tenant should only be accessible from the master, and not from each tenant.

Without the patch the super user of any tenant can see the details (of
every other tenant) in the tables tenant and tenantdatasource of that
database. And this shouldn't be.

The patch will ensure that only through the master the db and these tables
are accessible.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Fri, Feb 28, 2014 at 5:10 PM, Jacopo Cappellato <
[hidden email]> wrote:

> I have spent some time reviewing a part of the code and I have a few
> comments inline:
>
> On Feb 25, 2014, at 10:48 PM, Pierre Smits <[hidden email]> wrote:
>
> > Jacopo,
> >
> > I also would like to understand what that means. And what I don't
> > understand I can't recreate it also.
>
> the main design around the entities in the org.ofbiz.tenant group is the
> following: one separate small database is created to host all and only the
> org.ofbiz.tenant entities: these entities contain meta-data information for
> all tenants (url, db user and password to get access to each tenant db).
> The patch you have proposed, by removing the org.ofbiz.tenant group, has
> the effect of moving these entities to the main OFBiz database: could you
> please check if you see these entities in your local box (with your patch
> applied)? Also, could you please check the content of these entities in the
> tenant specific databases and in the main database?
>
> >
> > As far as conditions go, I will elaborate here under what conditions we
> > have tested the patch.
> >
> > We created a virtual test setup consisting of 1 webserver (Apache HTTP)
> and
> > 1 app server (consisting of Apache OFBiz, set up against derby) whereby
> the
> > connection and traffic between the 2 servers was with and through the AJP
> > protocol.
> >
> > In that setup we created 5 tenants (with ./ant create-tenant).
> > And without the patch we tested all tenants accessing various apps and
> > components with Apache JMeter (and scripts). This included accessing
> > various functions in webtools as well.
>
> Are you saying that when you log in into Webtools with a tenantId you
> actually see the data from the main database rather than the data from the
> tenant specific db only? Is this happening for all the entities or just (as
> I suspect) for the entities in the org.ofbiz.tenant group?
>
> Jacopo
>
> >
> > Subsequently, we implemented the patch and ran the same tests again.
> Again
> > we had no problems accessing the various apps and components. The only
> > thing we didn't succeed in was accessing Tenant and TenantDataSource,
> when
> > being logged in as a tenant super-user.
> > However, when logged in as the admin of the master (without tenantId) we
> > were abel to access those entities and its data.
> >
> > Both situations, being able to access the two entities and the data when
> > logged in as master admin and not being able to when logged in as a
> > tenant-admin, are as to be expected.
> >
> > Now, I don't know what that means when having set up the domain name for
> a
> > tenant as the means to access the tenant environment. Apparently that has
> > been developed to have a unique uri per tenant. But we never have had any
> > use for that as we in our 3-tier productions setups have it as described
> as
> > above. This avoids us having to set up internal dns records to point to
> > specific tenants to connect to the app server.
> >
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
>
>