Re: Welcome to Devanshu Vyas as new committer!

2020-09-03 Thread Devanshu Vyas
Thank you all for your support and wishes.

Thanks & Regards,
Devanshu Vyas.


On Sat, Aug 22, 2020 at 11:22 AM Chandan Khandelwal <
chandan.khandel...@hotwaxsystems.com> wrote:

> Many congratulations Devanshu!
>
> Kind Regards,
> Chandan Khandelwal
>
>
>
> On Fri, Aug 21, 2020 at 2:49 PM Ankit Joshi  >
> wrote:
>
> > Many Congratulations Devanshu 
> >
> > Thanks & Regards,
> > Ankit Joshi
> > Sr. Technical Consultant
> >
> > *HotWax Systems*
> > *Enterprise open source experts*
> > cell: +91-8989267238
> > office: 0731-409-3684
> > http://www.hotwaxsystems.com
> >
> >
> > On Wed, Aug 19, 2020 at 2:32 PM Pawan Verma  wrote:
> >
> > > The OFBiz PMC has invited Devanshu Vyas to become a new committer and
> we
> > > are happy to announce that he has accepted this role.
> > >
> > > Some of the reasons for inviting Devanshu Vyas include:
> > >
> > > - He is invested in the OFBiz project and has been a member for many
> > years
> > > - He is taking an initiative towards improving the system
> > > - He has functional experience in various areas of the framework
> > > - He enjoys working with the community and collaborating with others
> > >
> > > Please join me in welcoming and congratulating Devanshu!
> > >
> > > Cheers
> > > Pawan Verma
> > > ofbiz.apache.org
> > >
> >
>


RE: Welcome Aditya Sharma as new PMC member

2020-09-03 Thread Development
I was unaware of "brainstorming sessions" what platform are they on and when 
are they?

From: Rishi Solanki [rishisolan...@gmail.com]
Sent: Monday, August 24, 2020 6:22 AM
To: dev@ofbiz.apache.org
Subject: Re: Welcome Aditya Sharma as new PMC member

Thank you Jacques, Now I have secured some time for the community and will
be active in general. Actually I was missing all the brainstorming sessions
from here.

Best Regards,
--
Rishi Solanki
*CTO, Mindpath Technology*
Intelligent Solutions
cell: +91-98932-87847
LinkedIn 


On Wed, Aug 12, 2020 at 12:02 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Good to see you back Rishi :)
>
> Jacques
>
> Le 12/08/2020 à 06:36, Rishi Solanki a écrit :
> > I missed the celebration. Congratulations Aditya!!
> >
> > Best Regards,
> > --
> > Rishi Solanki
> > *CTO, Mindpath Technology*
> > Intelligent Solutions
> > cell: +91-98932-87847
> > LinkedIn 
> >
> >
> > On Sun, Jul 12, 2020 at 4:16 PM Sharan Foga  wrote:
> >
> >> Congratulations and welcome Aditya :-)
> >>
> >> Thanks
> >> Sharan
> >>
> >> On 2020/07/05 16:53:22, Jacques Le Roux 
> >> wrote:
> >>> The OFBiz PMC has invited Aditya Sharma to become member of the
> >> committee and we are glad to announce that he has accepted the
> nomination.
> >>> On behalf of the OFBiz PMC, welcome on board Aditya!
> >>>
> >>>
>


CONFIDENTIALITY NOTICE: This message is intended only for the use of the person 
or organization to which it is addressed or was intended to be addressed, and 
may contain information that is privileged, confidential and exempt from 
disclosure under applicable law. If the reader of this message is not the 
intended recipient, or responsible for delivering the message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify the sender immediately by email and 
delete the original message immediately . The sender, its subsidiaries and 
affiliates, do not accept liability for any errors, omissions, corruption or 
virus in the contents of this message or any attachments that arise as a result 
of e-mail transmission. Thank you.


RE: varchar(255) in fieldtypepostgres.xml

2020-09-03 Thread Development
Thanks for the reply.  The link essentially says "to make postgres consistent 
with the other databases".  I researched it out, and found that *every single* 
supported database has a text type that goes over 255 char! (and gets used for 
type "very-long")

I know I do, and I would imagine people could easily go over 255 char when 
writing things like a comment or description about something. Would it make 
sense to change description and comment field types for all databases to be 
whatever that database has for type "very-long"?  If so, do I submit this as a 
JIRA issue?
 

From: Jacques Le Roux [jacques.le.r...@les7arts.com]
Sent: Tuesday, August 11, 2020 6:30 AM
To: dev@ofbiz.apache.org
Subject: Re: varchar(255) in fieldtypepostgres.xml

Hi,

Please check https://svn.apache.org/viewvc?view=revision=1697590

This is also related https://markmail.org/message/xuwhnbmum3evejwk

Jacques

Le 10/08/2020 à 20:30, Development a écrit :
> In /framework/entity/fieldtype/fieldtypepostgres.xml I saw some lines like:
>
>   java-type="String"/>
>   java-type="String"/>
>   java-type="String"/>
>
>
> In postgres, using "VARCHAR(255)" saves no space in the database over using 
> "VARCHAR" (with no number) or "TEXT", the only difference is that the 255 
> slows it down with error checking.
>
> Is there any reason on the ofbiz side to not just change this to plain 
> "VARCHAR" or "TEXT"?  Like perhaps the forms would only display the first 255 
> characters of it or something?
>
> Obviously I can do this for my own installation.  I'm asking here cause it 
> feels like something that should be pushed upstream.
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This message is intended only for the use of the 
> person or organization to which it is addressed or was intended to be 
> addressed, and may contain information that is privileged, confidential and 
> exempt from disclosure under applicable law. If the reader of this message is 
> not the intended recipient, or responsible for delivering the message to the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. If you 
> have received this communication in error, please notify the sender 
> immediately by email and delete the original message immediately . The 
> sender, its subsidiaries and affiliates, do not accept liability for any 
> errors, omissions, corruption or virus in the contents of this message or any 
> attachments that arise as a result of e-mail transmission. Thank you.



CONFIDENTIALITY NOTICE: This message is intended only for the use of the person 
or organization to which it is addressed or was intended to be addressed, and 
may contain information that is privileged, confidential and exempt from 
disclosure under applicable law. If the reader of this message is not the 
intended recipient, or responsible for delivering the message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify the sender immediately by email and 
delete the original message immediately . The sender, its subsidiaries and 
affiliates, do not accept liability for any errors, omissions, corruption or 
virus in the contents of this message or any attachments that arise as a result 
of e-mail transmission. Thank you.


Re: Behavior of Groovy vs JUnit tests with test data

2020-09-03 Thread Carsten Schinzer
Hi all,


I did find and try the following from google search:

- wrap all the tests in a class
- tag the class with @RunWith(SpringRunner.class)
- tag every method that manipulates the entity data with 
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)

This has NOT been successful, hence a strong indication that running the cases 
in Groovy will make entity data manipulations to be sticky and not reverted for 
the subsequent test case run.
I am going to rework my cases to run as JUnit test cases in a Java class.

Warm regards


Carsten

> Am 03.09.2020 um 13:13 schrieb Carsten Schinzer 
> :
> 
> Hi everyone,
> 
> 
> Recently, I did find that test cases actually are much easier to write in 
> Groovy and hence I started doing that, but now I stumble across the fact that 
> some of the Groovy tests seem to find changes applied to entities from 
> previous tests. The behavior is the following:
> 
> - I load the test data with instructions given in the tested XML
> - I manipulate data in the first test data, e.g. a status on an entity
> - when I run the next test case I do not get the originally loaded entity but 
> the manipulated one from the previous test
> 
> This is different from JUnit in Java where the entities seem to exist as 
> loaded from the testdata XML with every new test case.
> It would obviously mean that I we need to implement my testing in JUnit 
> (Java) rather when we want extensive testing of the services and need to 
> start from the loaded data every time. 
> 
> Can anyone confirm this behavior of Groovy over JUnit?
> Warm regards
> 
> 
> Carsten
> 



Behavior of Groovy vs JUnit tests with test data

2020-09-03 Thread Carsten Schinzer
Hi everyone,


Recently, I did find that test cases actually are much easier to write in 
Groovy and hence I started doing that, but now I stumble across the fact that 
some of the Groovy tests seem to find changes applied to entities from previous 
tests. The behavior is the following:

- I load the test data with instructions given in the tested XML
- I manipulate data in the first test data, e.g. a status on an entity
- when I run the next test case I do not get the originally loaded entity but 
the manipulated one from the previous test

This is different from JUnit in Java where the entities seem to exist as loaded 
from the testdata XML with every new test case.
It would obviously mean that I we need to implement my testing in JUnit (Java) 
rather when we want extensive testing of the services and need to start from 
the loaded data every time. 

Can anyone confirm this behavior of Groovy over JUnit?
Warm regards


Carsten



Re: OFBiz site and [ CVE-2017-16011] Cross-Site Scripting in jQuery

2020-09-03 Thread Jacques Le Roux

Great!

Le 03/09/2020 à 11:37, Aditya Sharma a écrit :

Indeed that makes sense Jacques. I checked we no longer use
bootstrap-select plugin so removed it as an initial step.

https://github.com/apache/ofbiz-site/commit/eec3090d837d6e931271596a48dca6e6c4a9aedb

ofbiz-site passes the checks now
https://github.com/apache/ofbiz-site/network/alerts
https://github.com/apache/ofbiz-site

I further plan to check and upgrade libraries to more recent versions
further.

Thanks and Regards,
Aditya Sharma

On Thu, Sep 3, 2020 at 2:34 PM Jacques Le Roux 
wrote:


Thanks Aditya,

We could think that it's not a big deal since it's only a static site. But
if we were defaced that would not look great ;)

Jacques

Le 03/09/2020 à 08:24, Aditya Sharma a écrit :

Hi Jacques,

I think the dependency is related to bootstrap-select plugin.


https://github.com/apache/ofbiz-site/network/alert/js/plugins/bootstrap-select/package.json/jquery/open

We might not be affected, though I will have a deeper look into it soon.

Thanks and regards,
Aditya Sharma


On Wed, Sep 2, 2020 at 10:53 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

I received an alert from GitHub Advisory 

Re: OFBiz site and [ CVE-2017-16011] Cross-Site Scripting in jQuery

2020-09-03 Thread Aditya Sharma
Indeed that makes sense Jacques. I checked we no longer use
bootstrap-select plugin so removed it as an initial step.

https://github.com/apache/ofbiz-site/commit/eec3090d837d6e931271596a48dca6e6c4a9aedb

ofbiz-site passes the checks now
https://github.com/apache/ofbiz-site/network/alerts
https://github.com/apache/ofbiz-site

I further plan to check and upgrade libraries to more recent versions
further.

Thanks and Regards,
Aditya Sharma

On Thu, Sep 3, 2020 at 2:34 PM Jacques Le Roux 
wrote:

> Thanks Aditya,
>
> We could think that it's not a big deal since it's only a static site. But
> if we were defaced that would not look great ;)
>
> Jacques
>
> Le 03/09/2020 à 08:24, Aditya Sharma a écrit :
> > Hi Jacques,
> >
> > I think the dependency is related to bootstrap-select plugin.
> >
> https://github.com/apache/ofbiz-site/network/alert/js/plugins/bootstrap-select/package.json/jquery/open
> >
> > We might not be affected, though I will have a deeper look into it soon.
> >
> > Thanks and regards,
> > Aditya Sharma
> >
> >
> > On Wed, Sep 2, 2020 at 10:53 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Hi,
> >>
> >> I received an alert from GitHub Advisory  >
> >> about OFBiz site and [CVE-2017-16011] "Cross-Site Scripting in jQuery"
> >>
> >> Could someone test if updating to jQuery 1.9 would work?
> >>
> >> I could then, or anyone ready for that, upgrade the OFBiz site to use
> >> jQuery 1.9
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >>
>


Re: OFBiz site and [ CVE-2017-16011] Cross-Site Scripting in jQuery

2020-09-03 Thread Jacques Le Roux

Thanks Aditya,

We could think that it's not a big deal since it's only a static site. But if 
we were defaced that would not look great ;)

Jacques

Le 03/09/2020 à 08:24, Aditya Sharma a écrit :

Hi Jacques,

I think the dependency is related to bootstrap-select plugin.
https://github.com/apache/ofbiz-site/network/alert/js/plugins/bootstrap-select/package.json/jquery/open

We might not be affected, though I will have a deeper look into it soon.

Thanks and regards,
Aditya Sharma


On Wed, Sep 2, 2020 at 10:53 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

I received an alert from GitHub Advisory 
about OFBiz site and [CVE-2017-16011] "Cross-Site Scripting in jQuery"

Could someone test if updating to jQuery 1.9 would work?

I could then, or anyone ready for that, upgrade the OFBiz site to use
jQuery 1.9

Thanks

Jacques




Re: OFBiz site and [ CVE-2017-16011] Cross-Site Scripting in jQuery

2020-09-03 Thread Jacques Le Roux

HI Pierre,

We have it already: https://github.com/apache/ofbiz-site

I subscribed to receive alerts by email

Jacques

Le 03/09/2020 à 08:03, Pierre Smits a écrit :

Hi Jacques,

Why don't we use CI and sonarcloud analysis to test these ante- and
post-upgrade scenarios?

Best regards

Pierre

Op wo 2 sep. 2020 19:23 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:


Hi,

I received an alert from GitHub Advisory 
about OFBiz site and [CVE-2017-16011] "Cross-Site Scripting in jQuery"

Could someone test if updating to jQuery 1.9 would work?

I could then, or anyone ready for that, upgrade the OFBiz site to use
jQuery 1.9

Thanks

Jacques




Re: OFBiz site and [ CVE-2017-16011] Cross-Site Scripting in jQuery

2020-09-03 Thread Aditya Sharma
Hi Jacques,

I think the dependency is related to bootstrap-select plugin.
https://github.com/apache/ofbiz-site/network/alert/js/plugins/bootstrap-select/package.json/jquery/open

We might not be affected, though I will have a deeper look into it soon.

Thanks and regards,
Aditya Sharma


On Wed, Sep 2, 2020 at 10:53 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> I received an alert from GitHub Advisory 
> about OFBiz site and [CVE-2017-16011] "Cross-Site Scripting in jQuery"
>
> Could someone test if updating to jQuery 1.9 would work?
>
> I could then, or anyone ready for that, upgrade the OFBiz site to use
> jQuery 1.9
>
> Thanks
>
> Jacques
>
>


Re: OFBiz site and [ CVE-2017-16011] Cross-Site Scripting in jQuery

2020-09-03 Thread Pierre Smits
Hi Jacques,

Why don't we use CI and sonarcloud analysis to test these ante- and
post-upgrade scenarios?

Best regards

Pierre

Op wo 2 sep. 2020 19:23 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:

> Hi,
>
> I received an alert from GitHub Advisory 
> about OFBiz site and [CVE-2017-16011] "Cross-Site Scripting in jQuery"
>
> Could someone test if updating to jQuery 1.9 would work?
>
> I could then, or anyone ready for that, upgrade the OFBiz site to use
> jQuery 1.9
>
> Thanks
>
> Jacques
>
>