Passport Component for OAuth2

[Jacques Le Roux]

Hi,

Shi Jinghai contributed a Passport Component for OAuth2 at https://issues.apache.org/jira/browse/OFBIZ-6135

It seems to me an interesting specialpurpose component to add. I will do so if nobody is against.

Jacques

[Pierre Smits]

Might indeed be interesting for a increase in the consumer area and not the
back end (but with market places and that tendency might shift).


It seems there are some security concerns. See here:
https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of providers is
impressive.
And I have look over the issue and wonder if we really need the gson and
paypal jars.

Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
[hidden email]> wrote:

> Hi,
>
> Shi Jinghai contributed a Passport Component for OAuth2 at
> https://issues.apache.org/jira/browse/OFBIZ-6135
>
> It seems to me an interesting specialpurpose component to add. I will do
> so if nobody is against.
>
> Jacques
>

[Gavin Mabie-2]

Hi Jacques

I know that there's been quite a bit of discussion about this and I don't
want to rehash stuff that's been dealt with and agreed upon in the past -
but is this really a special purpose component? It appears to be a
tool/utility. Special purpose components should really be for special
applications of the Ofbiz Framework, i.e. applying the framework in a
special user or industry way.  So for example, ecommerce is a special
purpose component - it implements ofbiz in a user specific way.  Ofiz Healh
Care/Communications/Hospitality/Government/ etc would be industry special
purpose components.

Gavin

On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <[hidden email]>
wrote:

> Might indeed be interesting for a increase in the consumer area and not the
> back end (but with market places and that tendency might shift).
>
>
> It seems there are some security concerns. See here:
> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of providers
> is
> impressive.
> And I have look over the issue and wonder if we really need the gson and
> paypal jars.
>
> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Hi,
> >
> > Shi Jinghai contributed a Passport Component for OAuth2 at
> > https://issues.apache.org/jira/browse/OFBIZ-6135
> >
> > It seems to me an interesting specialpurpose component to add. I will do
> > so if nobody is against.
> >
> > Jacques
> >
>

[Jacques Le Roux]

Hi Gavin,

Interesting, so you would suggest to create a new tools folder at the same level of dependency than specialpurpose and to add this new passport
Component to it.
Then we could also move ldap. I thought about jetty also, but I will rather open a new thread for that since we decided to discuss to move it to Attic

Do you (everybody ;)) see other components which could me moved to this new tools folder? Maybe bi, birt, oagis, even lucene?

Jacques


Le 21/03/2015 08:32, Gavin Mabie a écrit :

> Hi Jacques
>
> I know that there's been quite a bit of discussion about this and I don't
> want to rehash stuff that's been dealt with and agreed upon in the past -
> but is this really a special purpose component? It appears to be a
> tool/utility. Special purpose components should really be for special
> applications of the Ofbiz Framework, i.e. applying the framework in a
> special user or industry way.  So for example, ecommerce is a special
> purpose component - it implements ofbiz in a user specific way.  Ofiz Healh
> Care/Communications/Hospitality/Government/ etc would be industry special
> purpose components.
>
> Gavin
>
> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <[hidden email]>
> wrote:
>
>> Might indeed be interesting for a increase in the consumer area and not the
>> back end (but with market places and that tendency might shift).
>>
>>
>> It seems there are some security concerns. See here:
>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of providers
>> is
>> impressive.
>> And I have look over the issue and wonder if we really need the gson and
>> paypal jars.
>>
>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> Hi,
>>>
>>> Shi Jinghai contributed a Passport Component for OAuth2 at
>>> https://issues.apache.org/jira/browse/OFBIZ-6135
>>>
>>> It seems to me an interesting specialpurpose component to add. I will do
>>> so if nobody is against.
>>>
>>> Jacques
>>>

[Gavin Mabie-2]

Hi Jacques

My concern is about the proper use of the specialpurpose folder.  Birt is
IMO not a special purpose application, but rather a tool that can be used
across applications, and so is Lucene. Additionally, these are optional
functionalities and therefore non-core. My thinking is that if something is
optional, non-core and not a special implementation of the framework, then
it should go into this folder.  So I agree that BIRT and Lucene are
candidates for inclusion in this folder (my knowledge of OAGIS is sketchy
at best).  BTW  I'm not to sure about calling it "Tools". "Plugins" is the
term that is widely used for this sort of thing.

Gavin



On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
[hidden email]> wrote:

> Hi Gavin,
>
> Interesting, so you would suggest to create a new tools folder at the same
> level of dependency than specialpurpose and to add this new passport
> Component to it.
> Then we could also move ldap. I thought about jetty also, but I will
> rather open a new thread for that since we decided to discuss to move it to
> Attic
>
> Do you (everybody ;)) see other components which could me moved to this
> new tools folder? Maybe bi, birt, oagis, even lucene?
>
> Jacques
>
>
> Le 21/03/2015 08:32, Gavin Mabie a écrit :
>
>  Hi Jacques
>>
>> I know that there's been quite a bit of discussion about this and I don't
>> want to rehash stuff that's been dealt with and agreed upon in the past -
>> but is this really a special purpose component? It appears to be a
>> tool/utility. Special purpose components should really be for special
>> applications of the Ofbiz Framework, i.e. applying the framework in a
>> special user or industry way.  So for example, ecommerce is a special
>> purpose component - it implements ofbiz in a user specific way.  Ofiz
>> Healh
>> Care/Communications/Hospitality/Government/ etc would be industry special
>> purpose components.
>>
>> Gavin
>>
>> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <[hidden email]>
>> wrote:
>>
>>  Might indeed be interesting for a increase in the consumer area and not
>>> the
>>> back end (but with market places and that tendency might shift).
>>>
>>>
>>> It seems there are some security concerns. See here:
>>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of providers
>>> is
>>> impressive.
>>> And I have look over the issue and wonder if we really need the gson and
>>> paypal jars.
>>>
>>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>  Hi,
>>>>
>>>> Shi Jinghai contributed a Passport Component for OAuth2 at
>>>> https://issues.apache.org/jira/browse/OFBIZ-6135
>>>>
>>>> It seems to me an interesting specialpurpose component to add. I will do
>>>> so if nobody is against.
>>>>
>>>> Jacques
>>>>
>>>>

[Pierre Smits]

The passport component is an optional. So is the e-commerce component and
almost everything else is. There are some dependencies from components in
the applications and framework stacks to specifics in the special purpose
stack (birt, ldap - when applied and lucene?). But those are few, and we
can live with as these few enhance the functionality of the lower level
components and thus user experience.

Where apps should be placed is matter of viewpoint. And we have viewpoints
aplenty. Some regard e-commerce to be a core (framework + application
stack) extension. In its current state it is part of a vertical to. Retail
in particular, as it isn't a complete front-end solution for B2B (multiple
verticals), B2G (ambiguous vertical) and marketplaces (again multiple
verticals). If you don't do manufacturing, shouldn't  the same named
component not be an optional and thus not in applications. If you do HRM
but don't use the humanres component, shouldn't that component be better of
in the special purpose stack stack without being referenced in the
component-load.xml file.

The special purpose stack is a good place for any application/component but
the base registers in the applications stack. We should consider to make as
many as possible optional in that stack, by removing its reference in the
aforementioned component-load.xml. As it would surely reduce server load.
And we would give adopters a choice. Not only before adopting, but also
during the lifespan.

Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]> wrote:

> Hi Jacques
>
> My concern is about the proper use of the specialpurpose folder.  Birt is
> IMO not a special purpose application, but rather a tool that can be used
> across applications, and so is Lucene. Additionally, these are optional
> functionalities and therefore non-core. My thinking is that if something is
> optional, non-core and not a special implementation of the framework, then
> it should go into this folder.  So I agree that BIRT and Lucene are
> candidates for inclusion in this folder (my knowledge of OAGIS is sketchy
> at best).  BTW  I'm not to sure about calling it "Tools". "Plugins" is the
> term that is widely used for this sort of thing.
>
> Gavin
>
>
>
> On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Hi Gavin,
> >
> > Interesting, so you would suggest to create a new tools folder at the
> same
> > level of dependency than specialpurpose and to add this new passport
> > Component to it.
> > Then we could also move ldap. I thought about jetty also, but I will
> > rather open a new thread for that since we decided to discuss to move it
> to
> > Attic
> >
> > Do you (everybody ;)) see other components which could me moved to this
> > new tools folder? Maybe bi, birt, oagis, even lucene?
> >
> > Jacques
> >
> >
> > Le 21/03/2015 08:32, Gavin Mabie a écrit :
> >
> >  Hi Jacques
> >>
> >> I know that there's been quite a bit of discussion about this and I
> don't
> >> want to rehash stuff that's been dealt with and agreed upon in the past
> -
> >> but is this really a special purpose component? It appears to be a
> >> tool/utility. Special purpose components should really be for special
> >> applications of the Ofbiz Framework, i.e. applying the framework in a
> >> special user or industry way.  So for example, ecommerce is a special
> >> purpose component - it implements ofbiz in a user specific way.  Ofiz
> >> Healh
> >> Care/Communications/Hospitality/Government/ etc would be industry
> special
> >> purpose components.
> >>
> >> Gavin
> >>
> >> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <[hidden email]>
> >> wrote:
> >>
> >>  Might indeed be interesting for a increase in the consumer area and not
> >>> the
> >>> back end (but with market places and that tendency might shift).
> >>>
> >>>
> >>> It seems there are some security concerns. See here:
> >>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
> providers
> >>> is
> >>> impressive.
> >>> And I have look over the issue and wonder if we really need the gson
> and
> >>> paypal jars.
> >>>
> >>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
> >>> [hidden email]> wrote:
> >>>
> >>>  Hi,
> >>>>
> >>>> Shi Jinghai contributed a Passport Component for OAuth2 at
> >>>> https://issues.apache.org/jira/browse/OFBIZ-6135
> >>>>
> >>>> It seems to me an interesting specialpurpose component to add. I will
> do
> >>>> so if nobody is against.
> >>>>
> >>>> Jacques
> >>>>
> >>>>
>

[Pierre Smits]

Addendum. The passport component is currently not in the special purpose
stack. It is available as a patch in a JIRA issue for evaluation.

Pierre Smits

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

On Sat, Mar 21, 2015 at 3:58 PM, Pierre Smits <[hidden email]>
wrote:

> The passport component is an optional. So is the e-commerce component and
> almost everything else is. There are some dependencies from components in
> the applications and framework stacks to specifics in the special purpose
> stack (birt, ldap - when applied and lucene?). But those are few, and we
> can live with as these few enhance the functionality of the lower level
> components and thus user experience.
>
> Where apps should be placed is matter of viewpoint. And we have viewpoints
> aplenty. Some regard e-commerce to be a core (framework + application
> stack) extension. In its current state it is part of a vertical to. Retail
> in particular, as it isn't a complete front-end solution for B2B (multiple
> verticals), B2G (ambiguous vertical) and marketplaces (again multiple
> verticals). If you don't do manufacturing, shouldn't  the same named
> component not be an optional and thus not in applications. If you do HRM
> but don't use the humanres component, shouldn't that component be better of
> in the special purpose stack stack without being referenced in the
> component-load.xml file.
>
> The special purpose stack is a good place for any application/component
> but the base registers in the applications stack. We should consider to
> make as many as possible optional in that stack, by removing its reference
> in the aforementioned component-load.xml. As it would surely reduce server
> load. And we would give adopters a choice. Not only before adopting, but
> also during the lifespan.
>
> Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]> wrote:
>
>> Hi Jacques
>>
>> My concern is about the proper use of the specialpurpose folder.  Birt is
>> IMO not a special purpose application, but rather a tool that can be used
>> across applications, and so is Lucene. Additionally, these are optional
>> functionalities and therefore non-core. My thinking is that if something
>> is
>> optional, non-core and not a special implementation of the framework, then
>> it should go into this folder.  So I agree that BIRT and Lucene are
>> candidates for inclusion in this folder (my knowledge of OAGIS is sketchy
>> at best).  BTW  I'm not to sure about calling it "Tools". "Plugins" is the
>> term that is widely used for this sort of thing.
>>
>> Gavin
>>
>>
>>
>> On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> > Hi Gavin,
>> >
>> > Interesting, so you would suggest to create a new tools folder at the
>> same
>> > level of dependency than specialpurpose and to add this new passport
>> > Component to it.
>> > Then we could also move ldap. I thought about jetty also, but I will
>> > rather open a new thread for that since we decided to discuss to move
>> it to
>> > Attic
>> >
>> > Do you (everybody ;)) see other components which could me moved to this
>> > new tools folder? Maybe bi, birt, oagis, even lucene?
>> >
>> > Jacques
>> >
>> >
>> > Le 21/03/2015 08:32, Gavin Mabie a écrit :
>> >
>> >  Hi Jacques
>> >>
>> >> I know that there's been quite a bit of discussion about this and I
>> don't
>> >> want to rehash stuff that's been dealt with and agreed upon in the
>> past -
>> >> but is this really a special purpose component? It appears to be a
>> >> tool/utility. Special purpose components should really be for special
>> >> applications of the Ofbiz Framework, i.e. applying the framework in a
>> >> special user or industry way.  So for example, ecommerce is a special
>> >> purpose component - it implements ofbiz in a user specific way.  Ofiz
>> >> Healh
>> >> Care/Communications/Hospitality/Government/ etc would be industry
>> special
>> >> purpose components.
>> >>
>> >> Gavin
>> >>
>> >> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <[hidden email]>
>> >> wrote:
>> >>
>> >>  Might indeed be interesting for a increase in the consumer area and
>> not
>> >>> the
>> >>> back end (but with market places and that tendency might shift).
>> >>>
>> >>>
>> >>> It seems there are some security concerns. See here:
>> >>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
>> providers
>> >>> is
>> >>> impressive.
>> >>> And I have look over the issue and wonder if we really need the gson
>> and
>> >>> paypal jars.
>> >>>
>> >>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
>> >>> [hidden email]> wrote:
>> >>>
>> >>>  Hi,
>> >>>>
>> >>>> Shi Jinghai contributed a Passport Component for OAuth2 at
>> >>>> https://issues.apache.org/jira/browse/OFBIZ-6135
>> >>>>
>> >>>> It seems to me an interesting specialpurpose component to add. I
>> will do
>> >>>> so if nobody is against.
>> >>>>
>> >>>> Jacques
>> >>>>
>> >>>>
>>
>
>

[Gavin Mabie-2]

>
> The passport component is an optional. So is the e-commerce component and
> almost everything else is.


Not sure about this.

Where apps should be placed is matter of viewpoint. And we have viewpoints
> aplenty. Some regard e-commerce to be a core (framework + application
> stack) extension


Should it be a matter of viewpoint? Clearly, there must be a standard
approach.  Ofbiz is an ERP system first and foremost and as such should
have the typical ERP functionalities as applications (as it does now).
*Application Stack*: Accounting, Manufacturing and or Distribution, CRM, HR
and Payroll, Inventory, Marketing and Sales etc. should be under the
application stack as a minimum.  These aren't optional.
*Technology Stack*: Technologies without which these cannot be implemented
go under the Framework/Technology stack.
*Special Purpose*: Project Management, e-Commerce, Hospitality, Brewing?
IMHO special purpose should not be used for third party
technologies/integration.
*Tools/Plugins*: BIRT, DotNet, eBay, OAuth2, Lucene, Solr etc.

Regards

Gavin



On Sat, Mar 21, 2015 at 4:58 PM, Pierre Smits <[hidden email]>
wrote:

> The passport component is an optional. So is the e-commerce component and
> almost everything else is. There are some dependencies from components in
> the applications and framework stacks to specifics in the special purpose
> stack (birt, ldap - when applied and lucene?). But those are few, and we
> can live with as these few enhance the functionality of the lower level
> components and thus user experience.
>
> Where apps should be placed is matter of viewpoint. And we have viewpoints
> aplenty. Some regard e-commerce to be a core (framework + application
> stack) extension. In its current state it is part of a vertical to. Retail
> in particular, as it isn't a complete front-end solution for B2B (multiple
> verticals), B2G (ambiguous vertical) and marketplaces (again multiple
> verticals). If you don't do manufacturing, shouldn't  the same named
> component not be an optional and thus not in applications. If you do HRM
> but don't use the humanres component, shouldn't that component be better of
> in the special purpose stack stack without being referenced in the
> component-load.xml file.
>
> The special purpose stack is a good place for any application/component but
> the base registers in the applications stack. We should consider to make as
> many as possible optional in that stack, by removing its reference in the
> aforementioned component-load.xml. As it would surely reduce server load.
> And we would give adopters a choice. Not only before adopting, but also
> during the lifespan.
>
> Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]> wrote:
>
> > Hi Jacques
> >
> > My concern is about the proper use of the specialpurpose folder.  Birt is
> > IMO not a special purpose application, but rather a tool that can be used
> > across applications, and so is Lucene. Additionally, these are optional
> > functionalities and therefore non-core. My thinking is that if something
> is
> > optional, non-core and not a special implementation of the framework,
> then
> > it should go into this folder.  So I agree that BIRT and Lucene are
> > candidates for inclusion in this folder (my knowledge of OAGIS is sketchy
> > at best).  BTW  I'm not to sure about calling it "Tools". "Plugins" is
> the
> > term that is widely used for this sort of thing.
> >
> > Gavin
> >
> >
> >
> > On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> > > Hi Gavin,
> > >
> > > Interesting, so you would suggest to create a new tools folder at the
> > same
> > > level of dependency than specialpurpose and to add this new passport
> > > Component to it.
> > > Then we could also move ldap. I thought about jetty also, but I will
> > > rather open a new thread for that since we decided to discuss to move
> it
> > to
> > > Attic
> > >
> > > Do you (everybody ;)) see other components which could me moved to this
> > > new tools folder? Maybe bi, birt, oagis, even lucene?
> > >
> > > Jacques
> > >
> > >
> > > Le 21/03/2015 08:32, Gavin Mabie a écrit :
> > >
> > >  Hi Jacques
> > >>
> > >> I know that there's been quite a bit of discussion about this and I
> > don't
> > >> want to rehash stuff that's been dealt with and agreed upon in the
> past
> > -
> > >> but is this really a special purpose component? It appears to be a
> > >> tool/utility. Special purpose components should really be for special
> > >> applications of the Ofbiz Framework, i.e. applying the framework in a
> > >> special user or industry way.  So for example, ecommerce is a special
> > >> purpose component - it implements ofbiz in a user specific way.  Ofiz
> > >> Healh
> > >> Care/Communications/Hospitality/Government/ etc would be industry
> > special
> > >> purpose components.
> > >>
> > >> Gavin
> > >>
> > >> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <[hidden email]
> >
> > >> wrote:
> > >>
> > >>  Might indeed be interesting for a increase in the consumer area and
> not
> > >>> the
> > >>> back end (but with market places and that tendency might shift).
> > >>>
> > >>>
> > >>> It seems there are some security concerns. See here:
> > >>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
> > providers
> > >>> is
> > >>> impressive.
> > >>> And I have look over the issue and wonder if we really need the gson
> > and
> > >>> paypal jars.
> > >>>
> > >>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>  Hi,
> > >>>>
> > >>>> Shi Jinghai contributed a Passport Component for OAuth2 at
> > >>>> https://issues.apache.org/jira/browse/OFBIZ-6135
> > >>>>
> > >>>> It seems to me an interesting specialpurpose component to add. I
> will
> > do
> > >>>> so if nobody is against.
> > >>>>
> > >>>> Jacques
> > >>>>
> > >>>>
> >
>

[Pierre Smits]

How we have it now is a viewpoint. A viewpoint that you may not or may
agree with.

If you don't have anything to do with manufacturing or fixed assets or
workefforts or calendars, because you're operating a (fairly) simple retail
shop and use OFBiz, you currently don't have the option disable these
without developer work.

If you use a 3rd party crm solution you wouldn't use the sfa application.
If you use a 3rd party HRM solution, you wouldn't use humanres.

In other threads it has been said or implied that OFBiz isn't a single
vertical solution. The total package reflects that. But we have to offer
more optionality. Manufacturing is not core to all. SFA is not core to all.
Humanres is not core to all. Having these in the applications folder
implies that is not optional.

Best 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 Sat, Mar 21, 2015 at 4:28 PM, Gavin Mabie <[hidden email]> wrote:

> >
> > The passport component is an optional. So is the e-commerce component and
> > almost everything else is.
>
>
> Not sure about this.
>
> Where apps should be placed is matter of viewpoint. And we have viewpoints
> > aplenty. Some regard e-commerce to be a core (framework + application
> > stack) extension
>
>
> Should it be a matter of viewpoint? Clearly, there must be a standard
> approach.  Ofbiz is an ERP system first and foremost and as such should
> have the typical ERP functionalities as applications (as it does now).
> *Application Stack*: Accounting, Manufacturing and or Distribution, CRM, HR
> and Payroll, Inventory, Marketing and Sales etc. should be under the
> application stack as a minimum.  These aren't optional.
> *Technology Stack*: Technologies without which these cannot be implemented
> go under the Framework/Technology stack.
> *Special Purpose*: Project Management, e-Commerce, Hospitality, Brewing?
> IMHO special purpose should not be used for third party
> technologies/integration.
> *Tools/Plugins*: BIRT, DotNet, eBay, OAuth2, Lucene, Solr etc.
>
> Regards
>
> Gavin
>
>
>
> On Sat, Mar 21, 2015 at 4:58 PM, Pierre Smits <[hidden email]>
> wrote:
>
> > The passport component is an optional. So is the e-commerce component and
> > almost everything else is. There are some dependencies from components in
> > the applications and framework stacks to specifics in the special purpose
> > stack (birt, ldap - when applied and lucene?). But those are few, and we
> > can live with as these few enhance the functionality of the lower level
> > components and thus user experience.
> >
> > Where apps should be placed is matter of viewpoint. And we have
> viewpoints
> > aplenty. Some regard e-commerce to be a core (framework + application
> > stack) extension. In its current state it is part of a vertical to.
> Retail
> > in particular, as it isn't a complete front-end solution for B2B
> (multiple
> > verticals), B2G (ambiguous vertical) and marketplaces (again multiple
> > verticals). If you don't do manufacturing, shouldn't  the same named
> > component not be an optional and thus not in applications. If you do HRM
> > but don't use the humanres component, shouldn't that component be better
> of
> > in the special purpose stack stack without being referenced in the
> > component-load.xml file.
> >
> > The special purpose stack is a good place for any application/component
> but
> > the base registers in the applications stack. We should consider to make
> as
> > many as possible optional in that stack, by removing its reference in the
> > aforementioned component-load.xml. As it would surely reduce server load.
> > And we would give adopters a choice. Not only before adopting, but also
> > during the lifespan.
> >
> > Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]>
> wrote:
> >
> > > Hi Jacques
> > >
> > > My concern is about the proper use of the specialpurpose folder.  Birt
> is
> > > IMO not a special purpose application, but rather a tool that can be
> used
> > > across applications, and so is Lucene. Additionally, these are optional
> > > functionalities and therefore non-core. My thinking is that if
> something
> > is
> > > optional, non-core and not a special implementation of the framework,
> > then
> > > it should go into this folder.  So I agree that BIRT and Lucene are
> > > candidates for inclusion in this folder (my knowledge of OAGIS is
> sketchy
> > > at best).  BTW  I'm not to sure about calling it "Tools". "Plugins" is
> > the
> > > term that is widely used for this sort of thing.
> > >
> > > Gavin
> > >
> > >
> > >
> > > On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
> > > [hidden email]> wrote:
> > >
> > > > Hi Gavin,
> > > >
> > > > Interesting, so you would suggest to create a new tools folder at the
> > > same
> > > > level of dependency than specialpurpose and to add this new passport
> > > > Component to it.
> > > > Then we could also move ldap. I thought about jetty also, but I will
> > > > rather open a new thread for that since we decided to discuss to move
> > it
> > > to
> > > > Attic
> > > >
> > > > Do you (everybody ;)) see other components which could me moved to
> this
> > > > new tools folder? Maybe bi, birt, oagis, even lucene?
> > > >
> > > > Jacques
> > > >
> > > >
> > > > Le 21/03/2015 08:32, Gavin Mabie a écrit :
> > > >
> > > >  Hi Jacques
> > > >>
> > > >> I know that there's been quite a bit of discussion about this and I
> > > don't
> > > >> want to rehash stuff that's been dealt with and agreed upon in the
> > past
> > > -
> > > >> but is this really a special purpose component? It appears to be a
> > > >> tool/utility. Special purpose components should really be for
> special
> > > >> applications of the Ofbiz Framework, i.e. applying the framework in
> a
> > > >> special user or industry way.  So for example, ecommerce is a
> special
> > > >> purpose component - it implements ofbiz in a user specific way.
> Ofiz
> > > >> Healh
> > > >> Care/Communications/Hospitality/Government/ etc would be industry
> > > special
> > > >> purpose components.
> > > >>
> > > >> Gavin
> > > >>
> > > >> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <
> [hidden email]
> > >
> > > >> wrote:
> > > >>
> > > >>  Might indeed be interesting for a increase in the consumer area and
> > not
> > > >>> the
> > > >>> back end (but with market places and that tendency might shift).
> > > >>>
> > > >>>
> > > >>> It seems there are some security concerns. See here:
> > > >>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
> > > providers
> > > >>> is
> > > >>> impressive.
> > > >>> And I have look over the issue and wonder if we really need the
> gson
> > > and
> > > >>> paypal jars.
> > > >>>
> > > >>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
> > > >>> [hidden email]> wrote:
> > > >>>
> > > >>>  Hi,
> > > >>>>
> > > >>>> Shi Jinghai contributed a Passport Component for OAuth2 at
> > > >>>> https://issues.apache.org/jira/browse/OFBIZ-6135
> > > >>>>
> > > >>>> It seems to me an interesting specialpurpose component to add. I
> > will
> > > do
> > > >>>> so if nobody is against.
> > > >>>>
> > > >>>> Jacques
> > > >>>>
> > > >>>>
> > >
> >
>

[Jacques Le Roux]

Le 21/03/2015 16:28, Gavin Mabie a écrit :
>> The passport component is an optional. So is the e-commerce component and
>> almost everything else is.
>
> Not sure about this.

Nothing depend on the ecommerce component to work, but the ecommerce component depends on other lower level components, so the the ecommerce component
is optional

No I wanted to fund my explanation on the good work Ron did at https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
But the infra just broke it (see msg in yellow at top: "THIS WIKI HAS MOVED TO A NEW HOME - REPORT ANY ISSUES WITH AN JIRA TICKET !!!")
When you try to modify the page you will find the Graphviz definition. I checked the Graphviz plugin is not missing.
When you try to edit the Graphviz definition it says there is an error.

Before I create an infra Jira for that, could you please Ron check if you can fix the Graphviz definition? Thanks!

>
> Where apps should be placed is matter of viewpoint. And we have viewpoints
>> aplenty. Some regard e-commerce to be a core (framework + application
>> stack) extension
>
> Should it be a matter of viewpoint? Clearly, there must be a standard
> approach.  Ofbiz is an ERP system first and foremost and as such should
> have the typical ERP functionalities as applications (as it does now).
> *Application Stack*: Accounting, Manufacturing and or Distribution, CRM, HR
> and Payroll, Inventory, Marketing and Sales etc. should be under the
> application stack as a minimum.  These aren't optional.
> *Technology Stack*: Technologies without which these cannot be implemented
> go under the Framework/Technology stack.
> *Special Purpose*: Project Management, e-Commerce, Hospitality, Brewing?
> IMHO special purpose should not be used for third party
> technologies/integration.
> *Tools/Plugins*: BIRT, DotNet, eBay, OAuth2, Lucene, Solr etc.

I tend to agree, it clarifies things, we have too much things mixed in specialpurpose, good idea!

Jacques

>
> Regards
>
> Gavin
>
>
>
> On Sat, Mar 21, 2015 at 4:58 PM, Pierre Smits <[hidden email]>
> wrote:
>
>> The passport component is an optional. So is the e-commerce component and
>> almost everything else is. There are some dependencies from components in
>> the applications and framework stacks to specifics in the special purpose
>> stack (birt, ldap - when applied and lucene?). But those are few, and we
>> can live with as these few enhance the functionality of the lower level
>> components and thus user experience.
>>
>> Where apps should be placed is matter of viewpoint. And we have viewpoints
>> aplenty. Some regard e-commerce to be a core (framework + application
>> stack) extension. In its current state it is part of a vertical to. Retail
>> in particular, as it isn't a complete front-end solution for B2B (multiple
>> verticals), B2G (ambiguous vertical) and marketplaces (again multiple
>> verticals). If you don't do manufacturing, shouldn't  the same named
>> component not be an optional and thus not in applications. If you do HRM
>> but don't use the humanres component, shouldn't that component be better of
>> in the special purpose stack stack without being referenced in the
>> component-load.xml file.
>>
>> The special purpose stack is a good place for any application/component but
>> the base registers in the applications stack. We should consider to make as
>> many as possible optional in that stack, by removing its reference in the
>> aforementioned component-load.xml. As it would surely reduce server load.
>> And we would give adopters a choice. Not only before adopting, but also
>> during the lifespan.
>>
>> Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]> wrote:
>>
>>> Hi Jacques
>>>
>>> My concern is about the proper use of the specialpurpose folder.  Birt is
>>> IMO not a special purpose application, but rather a tool that can be used
>>> across applications, and so is Lucene. Additionally, these are optional
>>> functionalities and therefore non-core. My thinking is that if something
>> is
>>> optional, non-core and not a special implementation of the framework,
>> then
>>> it should go into this folder.  So I agree that BIRT and Lucene are
>>> candidates for inclusion in this folder (my knowledge of OAGIS is sketchy
>>> at best).  BTW  I'm not to sure about calling it "Tools". "Plugins" is
>> the
>>> term that is widely used for this sort of thing.
>>>
>>> Gavin
>>>
>>>
>>>
>>> On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> Hi Gavin,
>>>>
>>>> Interesting, so you would suggest to create a new tools folder at the
>>> same
>>>> level of dependency than specialpurpose and to add this new passport
>>>> Component to it.
>>>> Then we could also move ldap. I thought about jetty also, but I will
>>>> rather open a new thread for that since we decided to discuss to move
>> it
>>> to
>>>> Attic
>>>>
>>>> Do you (everybody ;)) see other components which could me moved to this
>>>> new tools folder? Maybe bi, birt, oagis, even lucene?
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 21/03/2015 08:32, Gavin Mabie a écrit :
>>>>
>>>>   Hi Jacques
>>>>> I know that there's been quite a bit of discussion about this and I
>>> don't
>>>>> want to rehash stuff that's been dealt with and agreed upon in the
>> past
>>> -
>>>>> but is this really a special purpose component? It appears to be a
>>>>> tool/utility. Special purpose components should really be for special
>>>>> applications of the Ofbiz Framework, i.e. applying the framework in a
>>>>> special user or industry way.  So for example, ecommerce is a special
>>>>> purpose component - it implements ofbiz in a user specific way.  Ofiz
>>>>> Healh
>>>>> Care/Communications/Hospitality/Government/ etc would be industry
>>> special
>>>>> purpose components.
>>>>>
>>>>> Gavin
>>>>>
>>>>> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <[hidden email]
>>>>> wrote:
>>>>>
>>>>>   Might indeed be interesting for a increase in the consumer area and
>> not
>>>>>> the
>>>>>> back end (but with market places and that tendency might shift).
>>>>>>
>>>>>>
>>>>>> It seems there are some security concerns. See here:
>>>>>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
>>> providers
>>>>>> is
>>>>>> impressive.
>>>>>> And I have look over the issue and wonder if we really need the gson
>>> and
>>>>>> paypal jars.
>>>>>>
>>>>>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>   Hi,
>>>>>>> Shi Jinghai contributed a Passport Component for OAuth2 at
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6135
>>>>>>>
>>>>>>> It seems to me an interesting specialpurpose component to add. I
>> will
>>> do
>>>>>>> so if nobody is against.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>

[Jacques Le Roux]

Le 21/03/2015 17:02, Pierre Smits a écrit :

> How we have it now is a viewpoint. A viewpoint that you may not or may
> agree with.
>
> If you don't have anything to do with manufacturing or fixed assets or
> workefforts or calendars, because you're operating a (fairly) simple retail
> shop and use OFBiz, you currently don't have the option disable these
> without developer work.
>
> If you use a 3rd party crm solution you wouldn't use the sfa application.
> If you use a 3rd party HRM solution, you wouldn't use humanres.
>
> In other threads it has been said or implied that OFBiz isn't a single
> vertical solution. The total package reflects that. But we have to offer
> more optionality. Manufacturing is not core to all. SFA is not core to all.
> Humanres is not core to all. Having these in the applications folder
> implies that is not optional.

I think you have a theoretical point here Pierre. I wanted to check what this would entail in term of changes by reviewing the component dependencies,
but it's not currently available (see my other message)
Now from a pragmatic POV, I believe we are not ready to engage a such effort if there are dependencies to fix. This could be discussed in the light of
the currently missing graph

Jacques

>
> Best 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 Sat, Mar 21, 2015 at 4:28 PM, Gavin Mabie <[hidden email]> wrote:
>
>>> The passport component is an optional. So is the e-commerce component and
>>> almost everything else is.
>>
>> Not sure about this.
>>
>> Where apps should be placed is matter of viewpoint. And we have viewpoints
>>> aplenty. Some regard e-commerce to be a core (framework + application
>>> stack) extension
>>
>> Should it be a matter of viewpoint? Clearly, there must be a standard
>> approach.  Ofbiz is an ERP system first and foremost and as such should
>> have the typical ERP functionalities as applications (as it does now).
>> *Application Stack*: Accounting, Manufacturing and or Distribution, CRM, HR
>> and Payroll, Inventory, Marketing and Sales etc. should be under the
>> application stack as a minimum.  These aren't optional.
>> *Technology Stack*: Technologies without which these cannot be implemented
>> go under the Framework/Technology stack.
>> *Special Purpose*: Project Management, e-Commerce, Hospitality, Brewing?
>> IMHO special purpose should not be used for third party
>> technologies/integration.
>> *Tools/Plugins*: BIRT, DotNet, eBay, OAuth2, Lucene, Solr etc.
>>
>> Regards
>>
>> Gavin
>>
>>
>>
>> On Sat, Mar 21, 2015 at 4:58 PM, Pierre Smits <[hidden email]>
>> wrote:
>>
>>> The passport component is an optional. So is the e-commerce component and
>>> almost everything else is. There are some dependencies from components in
>>> the applications and framework stacks to specifics in the special purpose
>>> stack (birt, ldap - when applied and lucene?). But those are few, and we
>>> can live with as these few enhance the functionality of the lower level
>>> components and thus user experience.
>>>
>>> Where apps should be placed is matter of viewpoint. And we have
>> viewpoints
>>> aplenty. Some regard e-commerce to be a core (framework + application
>>> stack) extension. In its current state it is part of a vertical to.
>> Retail
>>> in particular, as it isn't a complete front-end solution for B2B
>> (multiple
>>> verticals), B2G (ambiguous vertical) and marketplaces (again multiple
>>> verticals). If you don't do manufacturing, shouldn't  the same named
>>> component not be an optional and thus not in applications. If you do HRM
>>> but don't use the humanres component, shouldn't that component be better
>> of
>>> in the special purpose stack stack without being referenced in the
>>> component-load.xml file.
>>>
>>> The special purpose stack is a good place for any application/component
>> but
>>> the base registers in the applications stack. We should consider to make
>> as
>>> many as possible optional in that stack, by removing its reference in the
>>> aforementioned component-load.xml. As it would surely reduce server load.
>>> And we would give adopters a choice. Not only before adopting, but also
>>> during the lifespan.
>>>
>>> Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]>
>> wrote:
>>>> Hi Jacques
>>>>
>>>> My concern is about the proper use of the specialpurpose folder.  Birt
>> is
>>>> IMO not a special purpose application, but rather a tool that can be
>> used
>>>> across applications, and so is Lucene. Additionally, these are optional
>>>> functionalities and therefore non-core. My thinking is that if
>> something
>>> is
>>>> optional, non-core and not a special implementation of the framework,
>>> then
>>>> it should go into this folder.  So I agree that BIRT and Lucene are
>>>> candidates for inclusion in this folder (my knowledge of OAGIS is
>> sketchy
>>>> at best).  BTW  I'm not to sure about calling it "Tools". "Plugins" is
>>> the
>>>> term that is widely used for this sort of thing.
>>>>
>>>> Gavin
>>>>
>>>>
>>>>
>>>> On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>> Hi Gavin,
>>>>>
>>>>> Interesting, so you would suggest to create a new tools folder at the
>>>> same
>>>>> level of dependency than specialpurpose and to add this new passport
>>>>> Component to it.
>>>>> Then we could also move ldap. I thought about jetty also, but I will
>>>>> rather open a new thread for that since we decided to discuss to move
>>> it
>>>> to
>>>>> Attic
>>>>>
>>>>> Do you (everybody ;)) see other components which could me moved to
>> this
>>>>> new tools folder? Maybe bi, birt, oagis, even lucene?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 21/03/2015 08:32, Gavin Mabie a écrit :
>>>>>
>>>>>   Hi Jacques
>>>>>> I know that there's been quite a bit of discussion about this and I
>>>> don't
>>>>>> want to rehash stuff that's been dealt with and agreed upon in the
>>> past
>>>> -
>>>>>> but is this really a special purpose component? It appears to be a
>>>>>> tool/utility. Special purpose components should really be for
>> special
>>>>>> applications of the Ofbiz Framework, i.e. applying the framework in
>> a
>>>>>> special user or industry way.  So for example, ecommerce is a
>> special
>>>>>> purpose component - it implements ofbiz in a user specific way.
>> Ofiz
>>>>>> Healh
>>>>>> Care/Communications/Hospitality/Government/ etc would be industry
>>>> special
>>>>>> purpose components.
>>>>>>
>>>>>> Gavin
>>>>>>
>>>>>> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <
>> [hidden email]
>>>>>> wrote:
>>>>>>
>>>>>>   Might indeed be interesting for a increase in the consumer area and
>>> not
>>>>>>> the
>>>>>>> back end (but with market places and that tendency might shift).
>>>>>>>
>>>>>>>
>>>>>>> It seems there are some security concerns. See here:
>>>>>>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
>>>> providers
>>>>>>> is
>>>>>>> impressive.
>>>>>>> And I have look over the issue and wonder if we really need the
>> gson
>>>> and
>>>>>>> paypal jars.
>>>>>>>
>>>>>>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>   Hi,
>>>>>>>> Shi Jinghai contributed a Passport Component for OAuth2 at
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6135
>>>>>>>>
>>>>>>>> It seems to me an interesting specialpurpose component to add. I
>>> will
>>>> do
>>>>>>>> so if nobody is against.
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>

[Gavin Mabie-2]

Hi Pierre

If you use a 3rd party crm solution you wouldn't use the sfa application.
> If you use a 3rd party HRM solution, you wouldn't use humanres.


Following this line of thinking, let's consider this ridiculous
hypothetical scenario:

   - 3rd Party Accounting App;
   - 3rd Party HR;
   - 3rd Party SFA;
   - 3rd Party Catalog Management;
   - 3rd Party CMS;
   - etc

What would be Ofbiz's Value Proposition in this case?  There are core
applications that users expect to find in an ERP OOTB.

Gavin


On Sat, Mar 21, 2015 at 6:02 PM, Pierre Smits <[hidden email]>
wrote:

> How we have it now is a viewpoint. A viewpoint that you may not or may
> agree with.
>
> If you don't have anything to do with manufacturing or fixed assets or
> workefforts or calendars, because you're operating a (fairly) simple retail
> shop and use OFBiz, you currently don't have the option disable these
> without developer work.
>
> If you use a 3rd party crm solution you wouldn't use the sfa application.
> If you use a 3rd party HRM solution, you wouldn't use humanres.
>
> In other threads it has been said or implied that OFBiz isn't a single
> vertical solution. The total package reflects that. But we have to offer
> more optionality. Manufacturing is not core to all. SFA is not core to all.
> Humanres is not core to all. Having these in the applications folder
> implies that is not optional.
>
> Best 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 Sat, Mar 21, 2015 at 4:28 PM, Gavin Mabie <[hidden email]> wrote:
>
> > >
> > > The passport component is an optional. So is the e-commerce component
> and
> > > almost everything else is.
> >
> >
> > Not sure about this.
> >
> > Where apps should be placed is matter of viewpoint. And we have
> viewpoints
> > > aplenty. Some regard e-commerce to be a core (framework + application
> > > stack) extension
> >
> >
> > Should it be a matter of viewpoint? Clearly, there must be a standard
> > approach.  Ofbiz is an ERP system first and foremost and as such should
> > have the typical ERP functionalities as applications (as it does now).
> > *Application Stack*: Accounting, Manufacturing and or Distribution, CRM,
> HR
> > and Payroll, Inventory, Marketing and Sales etc. should be under the
> > application stack as a minimum.  These aren't optional.
> > *Technology Stack*: Technologies without which these cannot be
> implemented
> > go under the Framework/Technology stack.
> > *Special Purpose*: Project Management, e-Commerce, Hospitality, Brewing?
> > IMHO special purpose should not be used for third party
> > technologies/integration.
> > *Tools/Plugins*: BIRT, DotNet, eBay, OAuth2, Lucene, Solr etc.
> >
> > Regards
> >
> > Gavin
> >
> >
> >
> > On Sat, Mar 21, 2015 at 4:58 PM, Pierre Smits <[hidden email]>
> > wrote:
> >
> > > The passport component is an optional. So is the e-commerce component
> and
> > > almost everything else is. There are some dependencies from components
> in
> > > the applications and framework stacks to specifics in the special
> purpose
> > > stack (birt, ldap - when applied and lucene?). But those are few, and
> we
> > > can live with as these few enhance the functionality of the lower level
> > > components and thus user experience.
> > >
> > > Where apps should be placed is matter of viewpoint. And we have
> > viewpoints
> > > aplenty. Some regard e-commerce to be a core (framework + application
> > > stack) extension. In its current state it is part of a vertical to.
> > Retail
> > > in particular, as it isn't a complete front-end solution for B2B
> > (multiple
> > > verticals), B2G (ambiguous vertical) and marketplaces (again multiple
> > > verticals). If you don't do manufacturing, shouldn't  the same named
> > > component not be an optional and thus not in applications. If you do
> HRM
> > > but don't use the humanres component, shouldn't that component be
> better
> > of
> > > in the special purpose stack stack without being referenced in the
> > > component-load.xml file.
> > >
> > > The special purpose stack is a good place for any application/component
> > but
> > > the base registers in the applications stack. We should consider to
> make
> > as
> > > many as possible optional in that stack, by removing its reference in
> the
> > > aforementioned component-load.xml. As it would surely reduce server
> load.
> > > And we would give adopters a choice. Not only before adopting, but also
> > > during the lifespan.
> > >
> > > Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]>
> > wrote:
> > >
> > > > Hi Jacques
> > > >
> > > > My concern is about the proper use of the specialpurpose folder.
> Birt
> > is
> > > > IMO not a special purpose application, but rather a tool that can be
> > used
> > > > across applications, and so is Lucene. Additionally, these are
> optional
> > > > functionalities and therefore non-core. My thinking is that if
> > something
> > > is
> > > > optional, non-core and not a special implementation of the framework,
> > > then
> > > > it should go into this folder.  So I agree that BIRT and Lucene are
> > > > candidates for inclusion in this folder (my knowledge of OAGIS is
> > sketchy
> > > > at best).  BTW  I'm not to sure about calling it "Tools". "Plugins"
> is
> > > the
> > > > term that is widely used for this sort of thing.
> > > >
> > > > Gavin
> > > >
> > > >
> > > >
> > > > On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
> > > > [hidden email]> wrote:
> > > >
> > > > > Hi Gavin,
> > > > >
> > > > > Interesting, so you would suggest to create a new tools folder at
> the
> > > > same
> > > > > level of dependency than specialpurpose and to add this new
> passport
> > > > > Component to it.
> > > > > Then we could also move ldap. I thought about jetty also, but I
> will
> > > > > rather open a new thread for that since we decided to discuss to
> move
> > > it
> > > > to
> > > > > Attic
> > > > >
> > > > > Do you (everybody ;)) see other components which could me moved to
> > this
> > > > > new tools folder? Maybe bi, birt, oagis, even lucene?
> > > > >
> > > > > Jacques
> > > > >
> > > > >
> > > > > Le 21/03/2015 08:32, Gavin Mabie a écrit :
> > > > >
> > > > >  Hi Jacques
> > > > >>
> > > > >> I know that there's been quite a bit of discussion about this and
> I
> > > > don't
> > > > >> want to rehash stuff that's been dealt with and agreed upon in the
> > > past
> > > > -
> > > > >> but is this really a special purpose component? It appears to be a
> > > > >> tool/utility. Special purpose components should really be for
> > special
> > > > >> applications of the Ofbiz Framework, i.e. applying the framework
> in
> > a
> > > > >> special user or industry way.  So for example, ecommerce is a
> > special
> > > > >> purpose component - it implements ofbiz in a user specific way.
> > Ofiz
> > > > >> Healh
> > > > >> Care/Communications/Hospitality/Government/ etc would be industry
> > > > special
> > > > >> purpose components.
> > > > >>
> > > > >> Gavin
> > > > >>
> > > > >> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <
> > [hidden email]
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>  Might indeed be interesting for a increase in the consumer area
> and
> > > not
> > > > >>> the
> > > > >>> back end (but with market places and that tendency might shift).
> > > > >>>
> > > > >>>
> > > > >>> It seems there are some security concerns. See here:
> > > > >>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
> > > > providers
> > > > >>> is
> > > > >>> impressive.
> > > > >>> And I have look over the issue and wonder if we really need the
> > gson
> > > > and
> > > > >>> paypal jars.
> > > > >>>
> > > > >>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
> > > > >>> [hidden email]> wrote:
> > > > >>>
> > > > >>>  Hi,
> > > > >>>>
> > > > >>>> Shi Jinghai contributed a Passport Component for OAuth2 at
> > > > >>>> https://issues.apache.org/jira/browse/OFBIZ-6135
> > > > >>>>
> > > > >>>> It seems to me an interesting specialpurpose component to add. I
> > > will
> > > > do
> > > > >>>> so if nobody is against.
> > > > >>>>
> > > > >>>> Jacques
> > > > >>>>
> > > > >>>>
> > > >
> > >
> >
>

[Jacques Le Roux]

Le 22/03/2015 08:46, Gavin Mabie a écrit :

> Hi Pierre
>
> If you use a 3rd party crm solution you wouldn't use the sfa application.
>> If you use a 3rd party HRM solution, you wouldn't use humanres.
>
> Following this line of thinking, let's consider this ridiculous
> hypothetical scenario:
>
>     - 3rd Party Accounting App;
>     - 3rd Party HR;
>     - 3rd Party SFA;
>     - 3rd Party Catalog Management;
>     - 3rd Party CMS;
>     - etc
>
> What would be Ofbiz's Value Proposition in this case?  There are core
> applications that users expect to find in an ERP OOTB.

Good point Gavin :D

Jacques

>
> Gavin
>
>
> On Sat, Mar 21, 2015 at 6:02 PM, Pierre Smits <[hidden email]>
> wrote:
>
>> How we have it now is a viewpoint. A viewpoint that you may not or may
>> agree with.
>>
>> If you don't have anything to do with manufacturing or fixed assets or
>> workefforts or calendars, because you're operating a (fairly) simple retail
>> shop and use OFBiz, you currently don't have the option disable these
>> without developer work.
>>
>> If you use a 3rd party crm solution you wouldn't use the sfa application.
>> If you use a 3rd party HRM solution, you wouldn't use humanres.
>>
>> In other threads it has been said or implied that OFBiz isn't a single
>> vertical solution. The total package reflects that. But we have to offer
>> more optionality. Manufacturing is not core to all. SFA is not core to all.
>> Humanres is not core to all. Having these in the applications folder
>> implies that is not optional.
>>
>> Best 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 Sat, Mar 21, 2015 at 4:28 PM, Gavin Mabie <[hidden email]> wrote:
>>
>>>> The passport component is an optional. So is the e-commerce component
>> and
>>>> almost everything else is.
>>>
>>> Not sure about this.
>>>
>>> Where apps should be placed is matter of viewpoint. And we have
>> viewpoints
>>>> aplenty. Some regard e-commerce to be a core (framework + application
>>>> stack) extension
>>>
>>> Should it be a matter of viewpoint? Clearly, there must be a standard
>>> approach.  Ofbiz is an ERP system first and foremost and as such should
>>> have the typical ERP functionalities as applications (as it does now).
>>> *Application Stack*: Accounting, Manufacturing and or Distribution, CRM,
>> HR
>>> and Payroll, Inventory, Marketing and Sales etc. should be under the
>>> application stack as a minimum.  These aren't optional.
>>> *Technology Stack*: Technologies without which these cannot be
>> implemented
>>> go under the Framework/Technology stack.
>>> *Special Purpose*: Project Management, e-Commerce, Hospitality, Brewing?
>>> IMHO special purpose should not be used for third party
>>> technologies/integration.
>>> *Tools/Plugins*: BIRT, DotNet, eBay, OAuth2, Lucene, Solr etc.
>>>
>>> Regards
>>>
>>> Gavin
>>>
>>>
>>>
>>> On Sat, Mar 21, 2015 at 4:58 PM, Pierre Smits <[hidden email]>
>>> wrote:
>>>
>>>> The passport component is an optional. So is the e-commerce component
>> and
>>>> almost everything else is. There are some dependencies from components
>> in
>>>> the applications and framework stacks to specifics in the special
>> purpose
>>>> stack (birt, ldap - when applied and lucene?). But those are few, and
>> we
>>>> can live with as these few enhance the functionality of the lower level
>>>> components and thus user experience.
>>>>
>>>> Where apps should be placed is matter of viewpoint. And we have
>>> viewpoints
>>>> aplenty. Some regard e-commerce to be a core (framework + application
>>>> stack) extension. In its current state it is part of a vertical to.
>>> Retail
>>>> in particular, as it isn't a complete front-end solution for B2B
>>> (multiple
>>>> verticals), B2G (ambiguous vertical) and marketplaces (again multiple
>>>> verticals). If you don't do manufacturing, shouldn't  the same named
>>>> component not be an optional and thus not in applications. If you do
>> HRM
>>>> but don't use the humanres component, shouldn't that component be
>> better
>>> of
>>>> in the special purpose stack stack without being referenced in the
>>>> component-load.xml file.
>>>>
>>>> The special purpose stack is a good place for any application/component
>>> but
>>>> the base registers in the applications stack. We should consider to
>> make
>>> as
>>>> many as possible optional in that stack, by removing its reference in
>> the
>>>> aforementioned component-load.xml. As it would surely reduce server
>> load.
>>>> And we would give adopters a choice. Not only before adopting, but also
>>>> during the lifespan.
>>>>
>>>> Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]>
>>> wrote:
>>>>> Hi Jacques
>>>>>
>>>>> My concern is about the proper use of the specialpurpose folder.
>> Birt
>>> is
>>>>> IMO not a special purpose application, but rather a tool that can be
>>> used
>>>>> across applications, and so is Lucene. Additionally, these are
>> optional
>>>>> functionalities and therefore non-core. My thinking is that if
>>> something
>>>> is
>>>>> optional, non-core and not a special implementation of the framework,
>>>> then
>>>>> it should go into this folder.  So I agree that BIRT and Lucene are
>>>>> candidates for inclusion in this folder (my knowledge of OAGIS is
>>> sketchy
>>>>> at best).  BTW  I'm not to sure about calling it "Tools". "Plugins"
>> is
>>>> the
>>>>> term that is widely used for this sort of thing.
>>>>>
>>>>> Gavin
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> Hi Gavin,
>>>>>>
>>>>>> Interesting, so you would suggest to create a new tools folder at
>> the
>>>>> same
>>>>>> level of dependency than specialpurpose and to add this new
>> passport
>>>>>> Component to it.
>>>>>> Then we could also move ldap. I thought about jetty also, but I
>> will
>>>>>> rather open a new thread for that since we decided to discuss to
>> move
>>>> it
>>>>> to
>>>>>> Attic
>>>>>>
>>>>>> Do you (everybody ;)) see other components which could me moved to
>>> this
>>>>>> new tools folder? Maybe bi, birt, oagis, even lucene?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 21/03/2015 08:32, Gavin Mabie a écrit :
>>>>>>
>>>>>>   Hi Jacques
>>>>>>> I know that there's been quite a bit of discussion about this and
>> I
>>>>> don't
>>>>>>> want to rehash stuff that's been dealt with and agreed upon in the
>>>> past
>>>>> -
>>>>>>> but is this really a special purpose component? It appears to be a
>>>>>>> tool/utility. Special purpose components should really be for
>>> special
>>>>>>> applications of the Ofbiz Framework, i.e. applying the framework
>> in
>>> a
>>>>>>> special user or industry way.  So for example, ecommerce is a
>>> special
>>>>>>> purpose component - it implements ofbiz in a user specific way.
>>> Ofiz
>>>>>>> Healh
>>>>>>> Care/Communications/Hospitality/Government/ etc would be industry
>>>>> special
>>>>>>> purpose components.
>>>>>>>
>>>>>>> Gavin
>>>>>>>
>>>>>>> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <
>>> [hidden email]
>>>>>>> wrote:
>>>>>>>
>>>>>>>   Might indeed be interesting for a increase in the consumer area
>> and
>>>> not
>>>>>>>> the
>>>>>>>> back end (but with market places and that tendency might shift).
>>>>>>>>
>>>>>>>>
>>>>>>>> It seems there are some security concerns. See here:
>>>>>>>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
>>>>> providers
>>>>>>>> is
>>>>>>>> impressive.
>>>>>>>> And I have look over the issue and wonder if we really need the
>>> gson
>>>>> and
>>>>>>>> paypal jars.
>>>>>>>>
>>>>>>>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
>>>>>>>> [hidden email]> wrote:
>>>>>>>>
>>>>>>>>   Hi,
>>>>>>>>> Shi Jinghai contributed a Passport Component for OAuth2 at
>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6135
>>>>>>>>>
>>>>>>>>> It seems to me an interesting specialpurpose component to add. I
>>>> will
>>>>> do
>>>>>>>>> so if nobody is against.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>

[Pierre Smits]

Having spent quite some time on configurability, I would say that there are
lot of applications (solutions/functionality sets) ingrained in our core
apps that could be regarded as optionals, all depending on one's viewpoint
of course. Consider all the 3rd party solution integrations regarding
payment and shipment. Consider facility in product. Consider budget and
agreements in accounting. Consider request, quote and requirements in
ordermgr.

Having them ingrained in our releases makes it harder to 'sell' OFBiz to
all variants of potential adopters, as opposed to the situation where we
can say: 'Do you need X? We have it! And you can opt for that'.

Best 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 Sat, Mar 21, 2015 at 4:00 PM, Pierre Smits <[hidden email]>
wrote:

> Addendum. The passport component is currently not in the special purpose
> stack. It is available as a patch in a JIRA issue for evaluation.
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sat, Mar 21, 2015 at 3:58 PM, Pierre Smits <[hidden email]>
> wrote:
>
>> The passport component is an optional. So is the e-commerce component and
>> almost everything else is. There are some dependencies from components in
>> the applications and framework stacks to specifics in the special purpose
>> stack (birt, ldap - when applied and lucene?). But those are few, and we
>> can live with as these few enhance the functionality of the lower level
>> components and thus user experience.
>>
>> Where apps should be placed is matter of viewpoint. And we have
>> viewpoints aplenty. Some regard e-commerce to be a core (framework +
>> application stack) extension. In its current state it is part of a vertical
>> to. Retail in particular, as it isn't a complete front-end solution for B2B
>> (multiple verticals), B2G (ambiguous vertical) and marketplaces (again
>> multiple verticals). If you don't do manufacturing, shouldn't  the same
>> named component not be an optional and thus not in applications. If you do
>> HRM but don't use the humanres component, shouldn't that component be
>> better of in the special purpose stack stack without being referenced in
>> the component-load.xml file.
>>
>> The special purpose stack is a good place for any application/component
>> but the base registers in the applications stack. We should consider to
>> make as many as possible optional in that stack, by removing its reference
>> in the aforementioned component-load.xml. As it would surely reduce server
>> load. And we would give adopters a choice. Not only before adopting, but
>> also during the lifespan.
>>
>> Best 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 Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <[hidden email]> wrote:
>>
>>> Hi Jacques
>>>
>>> My concern is about the proper use of the specialpurpose folder.  Birt is
>>> IMO not a special purpose application, but rather a tool that can be used
>>> across applications, and so is Lucene. Additionally, these are optional
>>> functionalities and therefore non-core. My thinking is that if something
>>> is
>>> optional, non-core and not a special implementation of the framework,
>>> then
>>> it should go into this folder.  So I agree that BIRT and Lucene are
>>> candidates for inclusion in this folder (my knowledge of OAGIS is sketchy
>>> at best).  BTW  I'm not to sure about calling it "Tools". "Plugins" is
>>> the
>>> term that is widely used for this sort of thing.
>>>
>>> Gavin
>>>
>>>
>>>
>>> On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>> > Hi Gavin,
>>> >
>>> > Interesting, so you would suggest to create a new tools folder at the
>>> same
>>> > level of dependency than specialpurpose and to add this new passport
>>> > Component to it.
>>> > Then we could also move ldap. I thought about jetty also, but I will
>>> > rather open a new thread for that since we decided to discuss to move
>>> it to
>>> > Attic
>>> >
>>> > Do you (everybody ;)) see other components which could me moved to this
>>> > new tools folder? Maybe bi, birt, oagis, even lucene?
>>> >
>>> > Jacques
>>> >
>>> >
>>> > Le 21/03/2015 08:32, Gavin Mabie a écrit :
>>> >
>>> >  Hi Jacques
>>> >>
>>> >> I know that there's been quite a bit of discussion about this and I
>>> don't
>>> >> want to rehash stuff that's been dealt with and agreed upon in the
>>> past -
>>> >> but is this really a special purpose component? It appears to be a
>>> >> tool/utility. Special purpose components should really be for special
>>> >> applications of the Ofbiz Framework, i.e. applying the framework in a
>>> >> special user or industry way.  So for example, ecommerce is a special
>>> >> purpose component - it implements ofbiz in a user specific way.  Ofiz
>>> >> Healh
>>> >> Care/Communications/Hospitality/Government/ etc would be industry
>>> special
>>> >> purpose components.
>>> >>
>>> >> Gavin
>>> >>
>>> >> On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <[hidden email]
>>> >
>>> >> wrote:
>>> >>
>>> >>  Might indeed be interesting for a increase in the consumer area and
>>> not
>>> >>> the
>>> >>> back end (but with market places and that tendency might shift).
>>> >>>
>>> >>>
>>> >>> It seems there are some security concerns. See here:
>>> >>> https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
>>> providers
>>> >>> is
>>> >>> impressive.
>>> >>> And I have look over the issue and wonder if we really need the gson
>>> and
>>> >>> paypal jars.
>>> >>>
>>> >>> Best 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 Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
>>> >>> [hidden email]> wrote:
>>> >>>
>>> >>>  Hi,
>>> >>>>
>>> >>>> Shi Jinghai contributed a Passport Component for OAuth2 at
>>> >>>> https://issues.apache.org/jira/browse/OFBIZ-6135
>>> >>>>
>>> >>>> It seems to me an interesting specialpurpose component to add. I
>>> will do
>>> >>>> so if nobody is against.
>>> >>>>
>>> >>>> Jacques
>>> >>>>
>>> >>>>
>>>
>>
>>
>

[Hans Bakker]

On 21/03/15 23:02, Pierre Smits wrote:
> If you don't have anything to do with manufacturing or fixed assets or
> workefforts or calendars, because you're operating a (fairly) simple retail
> shop and use OFBiz, you currently don't have the option disable these
> without developer work.
>
Remove all priviledges from a userlogin to a certain component and it
will not show.....

[Jacques Le Roux]

It's now fixed after https://issues.apache.org/jira/browse/INFRA-9327

Jacques

Le 21/03/2015 17:54, Jacques Le Roux a écrit :
> No I wanted to fund my explanation on the good work Ron did at
> https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
> But the infra just broke it (see msg in yellow at top: "THIS WIKI HAS MOVED TO A NEW HOME - REPORT ANY ISSUES WITH AN JIRA TICKET !!!")
> When you try to modify the page you will find the Graphviz definition. I checked the Graphviz plugin is not missing.
> When you try to edit the Graphviz definition it says there is an error.
>
> Before I create an infra Jira for that, could you please Ron check if you can fix the Graphviz definition? Thanks!