Re: Update Gradle in trunk

[Jacques Le Roux]

Thanks Nicolas,

I'll try again and get back to you if I can't

Jacques

Le 31/07/2020 à 15:08, Nicolas Malin a écrit :

Hello Jacques,

I tried to load a new gradle wapper version on bintray without problem.

Maybe we can realize it together to be sure we talk on the same subject.

Nicolas

On 23/07/2020 10:29, Jacques Le Roux wrote:

Thanks Nicolas!

Le 21/07/2020 à 14:20, Nicolas Malin a écrit :

Hi Jacques,

Thanks for your alert, I will take some time to check the new UI dans
correct the process.

Nicolas

On 21/07/2020 10:15, Jacques Le Roux wrote:

Hi Nicolas, All,

I tried to update Gradle in trunk following
https://cwiki.apache.org/confluence/display/OFBIZ/Load+new+gradle+wrapper+version+on+bintray

rather than doing it by hand, mostly to test the process by my own.

But the UI has changed. There is no longer an "*Upload* link, hidden
on the header bar". I see only a Link button and it does not seem to
be the same thing.

Any idea?

TIA

Jacques

Re: Update Gradle in trunk

[Nicolas Malin]

Hello Jacques,

I tried to load a new gradle wapper version on bintray without problem.

Maybe we can realize it together to be sure we talk on the same subject.

Nicolas

On 23/07/2020 10:29, Jacques Le Roux wrote:
> Thanks Nicolas!
>
> Le 21/07/2020 à 14:20, Nicolas Malin a écrit :
>> Hi Jacques,
>>
>> Thanks for your alert, I will take some time to check the new UI dans
>> correct the process.
>>
>> Nicolas
>>
>> On 21/07/2020 10:15, Jacques Le Roux wrote:
>>> Hi Nicolas, All,
>>>
>>> I tried to update Gradle in trunk following
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Load+new+gradle+wrapper+version+on+bintray
>>>
>>> rather than doing it by hand, mostly to test the process by my own.
>>>
>>> But the UI has changed. There is no longer an "*Upload* link, hidden
>>> on the header bar". I see only a Link button and it does not seem to
>>> be the same thing.
>>>
>>> Any idea?
>>>
>>> TIA
>>>
>>> Jacques
>>>
>>>


pEpkey.asc
Description: application/pgp-keys

Re: Move 'SecurityPermission' data to seed data files

[Pawan Verma]

Hi Priya,

I opinion would be to move SG, SP, SGP data to seed data files.
-- 
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Fri, Jul 31, 2020 at 5:43 PM Priya Sharma 
wrote:

> Hello All,
>
> As per discussion on
> https://issues.apache.org/jira/browse/OFBIZ-10575, we would like to
> confirm whether all security data (i.e SecurityPermission,
> SecurityGroupPermission and hence SecurityGroup) be moved to seed data
> files or only SecurityPermission data.
>
> Is there any particular use-case that may be harmed or any other
> potential security threat that may arise with this change?
>
> Please provide your feedback, concerns, or suggestions.
>
> --
> Best Regards,
> Priya
>

Move 'SecurityPermission' data to seed data files

[Priya Sharma]

Hello All,

As per discussion on
https://issues.apache.org/jira/browse/OFBIZ-10575, we would like to
confirm whether all security data (i.e SecurityPermission,
SecurityGroupPermission and hence SecurityGroup) be moved to seed data
files or only SecurityPermission data.

Is there any particular use-case that may be harmed or any other
potential security threat that may arise with this change?

Please provide your feedback, concerns, or suggestions.

--
Best Regards,
Priya

Re: buildbot failure in on ofbizTrunkFramework

[Pawan Verma]

Thanks Jacques!

Best
Pawan

Re: REST implementation

[Girish Vasmatkar]

Greetings!

I have created a PR to add a REST component -
https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
and let me know what you think and let me know if you face any issues. I
intend to merge it in a week from now.

With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
"action" attribute to the service definition now merged, this above
component should be able to expose exportable (export=true) and
actionable(action=GET|POST) services via REST.

Once the changes for nested attributes (OFBIZ-11902
) are done, I will also
be making corresponding changes in the GraphQL plugin to account for nested
attributes. OFBIZ-11902
 will
help in defining complex GraphQL mutations.

I am parallelly also working on designing an XML DSL for REST that should
allow tying up REST resources with OFBiz services.

Best,
Girish



On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai  wrote:

> Hi Girish,
>
> Yes, you got it.
>
> Web browser will popup a login dialog when response code is 401:
> setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
> required\"");
>
> The popup is skipped and then react/vue/angular can handle the response:
> setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
> required\"");
>
>
> 发件人: Girish Vasmatkar
> 发送时间: 2020年7月9日 14:54
> 收件人: dev@ofbiz.apache.org
> 主题: Re: REST implementation
>
> Hi Shi
>
> Thanks for taking a look at it. I have a question on "WWW-Authenticate"
> header so please clarify and I can make appropriate changes accordingly -
>
> All I am finding is that to prevent the pop-up, either return 403 (which I
> do not want to do) or not include "WWW-Authenticate" header at all (not
> inclined to do this as well because then we would be violating the spec).
> Do you mean to NOT start the value of the header with "Bearer" ?
> so instead of below
>
> *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
>
> should we change it to
>
> *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
>
> I did not test it, but I can just change it like this without testing if
> you can please confirm it will prevent the browser dialog.
>
> Thanks again for the review.
>
> Best,
> Girish
>
> On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai  wrote:
>
> > Hi Girish,
> >
> > Excellent.
> >
> > Only one suggestion from my quick view, when response code is 401, the
> > "WWW-Authenticate" header should be set to start with a word NOT “Bearer
> > …”, this can prevent web browser from popping up a login dialog.
> >
> > Kind Regards,
> >
> > Shi Jinghai
> >
> > 发件人: Girish Vasmatkar
> > 发送时间: 2020年7月8日 20:47
> > 收件人: dev@ofbiz.apache.org
> > 主题: Re: REST implementation
> >
> > Hi Folks
> >
> > I have added support for OpenApi Integration. The updated code can be
> found
> > here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
> > through the changes and test at your end and let me know your thoughts.
> >
> > I am planning to do some refactoring and then raise initial PR for the
> > plug-in if the changes look good to everyone.
> >
> > Best,
> > Girish
> >
> >
> > On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> > cars...@dcs-verkaufssysteme.de> wrote:
> >
> > > Hi Girish,
> > >
> > > Thanks to clarify :)
> > > What caught me on the OpenAPI integration is the snippet quoted below
> and
> > > I realize I should have read it in context. Actually then it is aligned
> > > with my view.
> > >
> > > Warm regards
> > >
> > > Carsten
> > >
> > > > Initial implementation does not contain OpenApi integration yet.
> > And
> > >
> > >
> >
> >
>
>

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

I confirm it's OK

Le 31/07/2020 à 09:48, Jacques Le Roux a écrit :

I guess it's only an unrelated data load issue:


loadQuoteTestData 
 Error A 
transaction error occurred reading data

|org.xml.sax.SAXException: A transaction error occurred reading data
org.apache.ofbiz.entity.GenericEntityException: 
org.apache.ofbiz.entity.GenericEntityException: |

I check locally...

Le 31/07/2020 à 09:18, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbizTrunkFramework while 
building ofbiz-framework. Full details are available at:
https://ci.apache.org/builders/ofbizTrunkFramework/builds/1750

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf947_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
triggered this build
Build Source Stamp: [branch trunk] d962777c771285683737795a0c6db9c55e9d7823
Blamelist: Pawan Verma 

BUILD FAILED: failed testIntegration

Sincerely,
  -The Buildbot

Re: Open Source - Vertical Applications

[Jacques Le Roux]

Hi Neetan,

Your message has been moderated, else it would not have reached this Mailing 
List.

Please subscribe to the user ML for such questions and then use your email 
client.
See why here http://ofbiz.apache.org/mailing-lists.html.

You will get a better support, people can answer you on the ML.
The wider the audience the better the answers you might get.

Also it's more work for moderators who have to accept your messages as long as 
you have not subscribed.
I'll personally no longer accept them (other moderators still could).

Thanks

This said Nicolas answered you on the user ML, please check 
https://markmail.org/message/wapyrrohrnlx62su

Jacques

Le 30/07/2020 à 22:05, Neetan Chopra a écrit :

Hi there

This is Neetan. I am a Group CTO working in Dubai.
Having worked in the Airline industry for 23 years (with Emirates) I have
been thinking about open sourcing one of the core aviation applications.
However there does not seem to be any example of a vertical OSS
application which has made an impact.

I just wanted to reach out to you to seek your advice on how the journey
with ofbiz has been and the lessons learnt for other open source enterprise
software endeavours.
Thank you and would be most grateful for any advice you can offer.

warm regards
Neetan Chopra

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

I guess it's only an unrelated data load issue:


loadQuoteTestData 
Error   A 
transaction error occurred reading data

|org.xml.sax.SAXException: A transaction error occurred reading data
org.apache.ofbiz.entity.GenericEntityException: 
org.apache.ofbiz.entity.GenericEntityException: |

I check locally...

Le 31/07/2020 à 09:18, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbizTrunkFramework while 
building ofbiz-framework. Full details are available at:
 https://ci.apache.org/builders/ofbizTrunkFramework/builds/1750

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf947_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
triggered this build
Build Source Stamp: [branch trunk] d962777c771285683737795a0c6db9c55e9d7823
Blamelist: Pawan Verma 

BUILD FAILED: failed testIntegration

Sincerely,
  -The Buildbot

Re: Repository Management For Third-Party Plugins

[Nicolas Malin]

Hi,

I have the feeling that the first approch is a step to move on second.

Create a tree structure for plugins would be necessary and implement it
the resolve installed plugins without framework change for each new sub
directory seems a mandatory way to keep it simple.

Nicolas

On 30/07/2020 18:53, Pawan Verma wrote:
> Thanks Mridul and Jacques for the valuable feedback.
>
> I also agree with your proposition. My vote is also for approach #1.
>
> Best
> Pawan
>
> On Thu, Jul 30, 2020, 9:32 PM Jacques Le Roux 
> wrote:
>
>> Hi,
>>
>> Like Mridul, I also suggested  the 2nd approach. I eventually tend to
>> agree with Mridul. Having clearly separated packages, even with a bit of
>> redundancy, simplifies and consolidate things.
>>
>> Jacques
>>
>> Le 30/07/2020 à 17:37, Mridul Pathak a écrit :
>>> Hi Pawan,
>>>
>>> Though few years ago I was advocate of the approach #2 that you have
>> suggested here, now I think that #1 is the best approach. In real time
>> implementations the idea of plugins is to be able to use only what you
>> need. Like for payment integrations you selectively use the gateways,
>> mostly one. So it should be as easy to drop the plugin for your preferred
>> gateway and use it, you shouldn’t need to unnecessarily have to code of all
>> other payment integrations that you don’t need. Also, from maintenance
>> perspective even though some of these third party integrations could be
>> categorised but still each of them have their own API specification,
>> configurations and they need to be maintained separately. So, my vote would
>> be to #1 that is to create separate plugins for each third party
>> integration.
>>> Thanks.
>>> --
>>> Mridul Pathak
>>>
>>>
 On 30-Jul-2020, at 8:34 PM, Pawan Verma 
>> wrote:
 Hi Pritam,

 I am also more inclined to not create a different repository for
 third-party-plugins. As we can have any number of plugins in OFBiz and
 Users can set up required plugins as per their need.

 I would suggest creating separate plugins for each third-party
>> integration
 like ups, firstdatapaymentgateway, etc that way if the user wants only a
 specific gateway or plugins can have only that one.

 I suggest two approaches:
 #1: Create a separate plugin for each integration and put them into the
 plugins directory.

 #2: Club all the related plugins into one directory and can add that
>> parent
 directory in base/config/component-load.xml. The benefit of this
>> approach
 is we can have all payment or other gateways in one place and also don't
 need to create a separate repository for the third-party-plugins.
 Example for shipping gateways:

1. Club all shipping gateways into the plugins/shipping-gateway
>> directory
2. Add this shipping-gateway into base/config/component-load.xml
as 

 If we follow the #2 approach we may need to improve our plugin setup
>> Gradle
 target i.e. pullPluginSource.

 Please let me know your thoughts and I can provide more detail if
>> needed.
 Best
 Pawan
>>


pEpkey.asc
Description: application/pgp-keys

Re: Organize OFBiz Wiki

[Jacques Le Roux]

Hi Devanshu,

Please see my answer to Priya today in "Update 'How-to articles' wiki page" 
thread

HTH

Jacques

Le 30/07/2020 à 07:16, Devanshu Vyas a écrit :

Hello Devs,

We have discussed the need to clean our Wiki for a long time and we did
some work as well. But, with recent opinion shared on the user list, I feel
we should make our priority to clear the haystack of documentation
specially for the need of new OFBiz adaptors.

I would suggest aligning the documentation in such a way that a new person
visiting/exploring OFBiz has a seamless experience in identifying and
learning the traits of OFBiz.

@Jacques, It would be great if you could share more thoughts on the
concern, as you have been very vocal on this effort.

Wating for your thoughts.

Thanks & Regards,
Devanshu Vyas.

Re: Update 'How-to articles' wiki page

[Jacques Le Roux]

Hi Priya,

This page has been moved to Attic. But it still referenced by OFBiz End User Guide - WIP 
: 
https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=70258169


There is no way in Confluence to know who, when and why it was done: 
https://jira.atlassian.com/browse/CONFSERVER-5231

Actually I know, I did it: https://markmail.org/message/pzwa7ffoj7srjbsr, but 
forgot about the in and out links...

The problem with the documentation in the wiki is to keep things up to date, 
notably with in and out links.
That's why we (I don't think it's me only ;)) want to move all but very generic 
things not related to a version into AsciiDoc.
And refer to https://ci.apache.org/projects/ofbiz/site/ for and up to date 
documentation limited to 3 versions which is already ambitious but possible...

Jacques

Le 31/07/2020 à 07:39, Priya Sharma a écrit :

Hello All,

I recently stumbled upon this wiki page
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Install+OFBiz+without+the+Demo+Datand
it still refers to release 16.11 while
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+install+OFBiz+with+the+Demo+Data
has been updated as per 17.12.

Was it intentional or should we update it?

Best Regards,
Priya

Open Source - Vertical Applications

[Neetan Chopra]

Hi there

This is Neetan. I am a Group CTO working in Dubai.
Having worked in the Airline industry for 23 years (with Emirates) I have
been thinking about open sourcing one of the core aviation applications.
However there does not seem to be any example of a vertical OSS
application which has made an impact.

I just wanted to reach out to you to seek your advice on how the journey
with ofbiz has been and the lessons learnt for other open source enterprise
software endeavours.
Thank you and would be most grateful for any advice you can offer.

warm regards
Neetan Chopra