Re: [jira] [Commented] (OFBIZ-12489) Product Prices - VIEW permissions

[Pierre Smits]

My thanks goes out to those members of the OFBiz PMC who recognised (and
agreed with me) that volunteers feeling attacked ("trolled") by feedback of
PMC and ASF Member Michael Brohl is detrimental to the health of the
project,.

His behaviour, as displayed in various comments on tickets and pull
requests over the past two months, has caused engagement of and healthy,
constructive discussions between collaborating volunteers to not only
decline, but also swing like a pendulum. Making it more difficult for
collaborating contributors to come to conclusions and consensus to move
forward.
Thanks for recognising, like me, that the heated and fruitless debates
caused by this behaviour is a waste of my and fellow contributors' precious
time.

I trust that talks within the PMC has shown Michael the error of his ways,
and can learn from this.. And I hope that, now this has been addressed, the
community can come back together and get healed. Leading to more happy
collaborations working towards a better community and its works with each
of the engaging interactions.

I also thank the members of the ASF who stepped up and advised the members
of the OFBiz PMC, regarding the inappropriate behaviour of Michael Brohl.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Mon, Feb 7, 2022 at 9:06 PM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:

> Pierre,
>
> The OFBiz PMC has reviewed your complaints and has received some advice
> from various ASF members: with this response we are implementing some of
> those.
> The PMC considers troublesome the fact that you feel attacked ("trolled")
> by the feedback you receive by Michael (and possibly others) and that you
> consider the feedback being "inappropriate", because it prevents any
> possibility to discuss your contributions in a constructive manner, it
> leads to heated and fruitless debates that may be unhealthy for the OFBiz
> community and a waste of time for its contributors.
>
> The PMC has thus decided to ask the project's volunteers (PMC members,
> committers and contributors) to put "on hold" or reject or disregard any
> of your contributions, such as code, documentation, mailing list
> discussions
> etc. and close Jira issues and pull requests that are not straightforward
> and require further interactions/discussions with you before they can be
> approved or accepted.
>
> On behalf of the Apache OFBiz PMC,
>
> Jacopo
>
>
> On Tue, Jan 25, 2022 at 2:01 AM Pierre Smits 
> wrote:
>
>> Michael,
>>
>> I told you before in (other) tickets to stop trolling me through your
>> complaints in the tickets I am working on. You continue to do this.
>> Your remarks about you not committing the code contributions of
>> unprivileged contributors are totally inappropriate.  Not appropriate in
>> ticket comments, nor in the mailing lists of the project. Nobody is
>> strong-arming you to commit or merge improvements. Nobody is expecting you
>> ever will.
>> Stop trying to pressure fellow contributors, collaborating to improve
>> OFBiz, to follow your dictate by your attempt to frame a narrative that
>> there is an agreement about how contributors are to contribute what, where
>> and when.
>> Such narrative is solely intended to dictate the direction of the project
>> for your self serving purposes, resulting in alienating fellow
>> contributors
>> from collaborating in the OFBiz project to get improvements into its
>> repositories.
>>
>> There has never been such an agreement on how, what, where and when to
>> contribute in the OFBiz community. Nor on the specific subject of what the
>> correct translation label that is to be used in OFBiz screens and forms.
>> No discussion on that latter subject has ever been started on the dev
>> mailing list, nor is there any series of postings on that list that could
>> lead to someone being able to claim that a kind of consensus could be
>> derived from such a thread.
>>
>> It appears, IMO, that you don't want what is for the good of the public
>> through the deliverables of the OFBiz project.
>> Your business needs and goals are not the concerns of the project, nor the
>> concerns of the contributors not paid by you(r company).
>> You keep your Ecomify rules re OFBiz to yourself and for your employees,
>> instead of presenting them as rules (or agreements) of the project. In
>> this
>> project there are no such 'contribution' rules.
&g

Re: [GitHub] [ofbiz-framework] mbrohl commented on pull request #496: Improved: List and Grid (OFBIZ-11345)

[Pierre Smits]

You don't get the point, Michael.

You DON'T get to dictate what is being contributed to the project for the
public good.

Should not be so hard to understand for a member of a project's PMC and the
ASF.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Mon, Feb 7, 2022 at 5:05 PM Michael Brohl 
wrote:

> You don't get the point, Pierre.
>
> You are actively REMOVING elements others have contributed and put
> effort in.
>
> Shouldn't be too hard to understand.
>
> Michael
>
>
> Am 07.02.22 um 16:52 schrieb Pierre Smits:
> > *Re: Other contributors have taken their time to structure the code into
> > readable blocks and comment them.*
> > Other contributors have taken their time to provide clean code without
> [...]
> >
>

Re: [GitHub] [ofbiz-framework] mbrohl commented on pull request #496: Improved: List and Grid (OFBIZ-11345)

[Pierre Smits]

*Re: Other contributors have taken their time to structure the code into
readable blocks and comment them.*
Other contributors have taken their time to provide clean code without
caring for readable blocks or commenting those, and their contributions
also went into the codebase.
Other contributors have collaborated to get to cleaner (code) files, and
the result of these collaborations also went into the codebase.

*Re: If you want the functional changes go in, either stop removing those
elements or, if that's the problem, learn how to configure your XML Editor
to leave blank lines and comments as-is*
Again? Extortion of compliance to* "your"* rules? Trying that 'approach'
again?
You, again, try to dictate what can be contributed, when, how and by whom.
I will not comport with your dictatorship.

Stop being an embarrassment to the project and the ASF. These actions of
yours result in nothing more than a hostile environment that chases
(potential) contributors away and hurts collaboration between contributors.

Re:
https://github.com/apache/ofbiz-framework/pull/496#issuecomment-1031457572
The changes committed in this pull request are in line with guidelines and
best practices established over the course of the project under the wings
of the ASF, which were applied on merged pull request as recent as 7 days
ago.

 If you want the guidelines changed, you are welcome to start a discussion
in dev@.

 You can **NOT** unilaterally decide what will and will not be merged by
other volunteers. That is **dictatorship**!

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Mon, Feb 7, 2022 at 4:05 PM GitBox  wrote:

>
> mbrohl commented on pull request #496:
> URL:
> https://github.com/apache/ofbiz-framework/pull/496#issuecomment-1031566131
>
>
>Other contributors have taken their time to structure the code into
> readable blocks and comment them.
>You are removing this work and make the code look worse than before at
> those locations, therefore it cannot be accepted.
>
>If you want the functional changes go in, either stop removing those
> elements or, if that's the problem, learn how to configure your XML Editor
> to leave blank lines and comments as-is.
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
>

Re: [GitHub] [ofbiz-framework] mbrohl commented on pull request #501: Improved: List and Grid (OFBIZ-11345)

[Pierre Smits]

It is not about that anymore, is it now?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Sun, Feb 6, 2022 at 1:06 PM GitBox  wrote:

>
> mbrohl commented on pull request #501:
> URL:
> https://github.com/apache/ofbiz-framework/pull/501#issuecomment-1030819296
>
>
>This again contains changes actively removing separating blank lines,
> which makes the files less readable.
>If you are really interested in getting the functional changes into the
> codebase, why do you still introduce those changes and mix it up with the
> functional changes?
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
>

Re: [ofbiz-framework] branch trunk updated: Fixed: Manufacturing Jobshop find screen by default does not show all production runs (OFBIZ-12550)

[Pierre Smits]

Due to this merge the PR regarding OFBIZ-12524 (
https://github.com/apache/ofbiz-framework/pull/475 of January 23rd) is now
useless due to merge conflicts, causing work to be redone.


Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Tue, Feb 1, 2022 at 8:59 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> jleroux pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>  new 418d6e0  Fixed: Manufacturing Jobshop find screen by default does
> not show all production runs (OFBIZ-12550)
> 418d6e0 is described below
>
> commit 418d6e03d45c3647f96dbc1f7630b348a60d11f1
> Author: Jacques Le Roux 
> AuthorDate: Tue Feb 1 08:57:29 2022 +0100
>
> Fixed: Manufacturing Jobshop find screen by default does not show all
> production runs (OFBIZ-12550)
>
> The manufacturing jobshop find screen has the seach date initialized
> to nowdate.
> if one wants to see all production runs, one has to clear the date
> which should
> be empty initially
>
> The same problem exists on the MRP log find where the date is filled
> by default.
>
> Thanks: Hans for report and patches
> ---
>  applications/manufacturing/template/mrp/FindInventoryEventPlan.ftl |
> 2 +-
>  applications/manufacturing/widget/manufacturing/ProductionRunForms.xml |
> 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/applications/manufacturing/template/mrp/FindInventoryEventPlan.ftl
> b/applications/manufacturing/template/mrp/FindInventoryEventPlan.ftl
> index 825afc1..d2ed694 100644
> --- a/applications/manufacturing/template/mrp/FindInventoryEventPlan.ftl
> +++ b/applications/manufacturing/template/mrp/FindInventoryEventPlan.ftl
> @@ -70,7 +70,7 @@ function lookupInventory() {
>   class="label">${uiLabelMap.CommonFromDate}
>  
>  
> -  <@htmlTemplate.renderDateTimeField name="eventDate"
> event="" action="" className="" alert="" title="Format: -MM-dd
> HH:mm:ss.SSS" value="${requestParameters.eventDate!nowTimestamp}" size="25"
> maxlength="30" id="fromDate_2" dateType="date" shortDateInput=false
> timeDropdownParamName="" defaultDateTimeString="" localizedIconTitle=""
> timeDropdown="" timeHourName="" classString="" hour1="" hour2=""
> timeMinutesName="" minutes="" isTwelveHour="" ampmName="" amSelected=" [...]
> +  <@htmlTemplate.renderDateTimeField name="eventDate"
> event="" action="" className="" alert="" title="Format: -MM-dd
> HH:mm:ss.SSS" value="" size="25" maxlength="30" id="fromDate_2"
> dateType="date" shortDateInput=false timeDropdownParamName=""
> defaultDateTimeString="" localizedIconTitle="" timeDropdown=""
> timeHourName="" classString="" hour1="" hour2="" timeMinutesName=""
> minutes="" isTwelveHour="" ampmName="" amSelected="" pmSelected=""
> compositeType="" formName=""/>
>  
>
>
> diff --git
> a/applications/manufacturing/widget/manufacturing/ProductionRunForms.xml
> b/applications/manufacturing/widget/manufacturing/ProductionRunForms.xml
> index c5674b8..73b42b6 100644
> ---
> a/applications/manufacturing/widget/manufacturing/ProductionRunForms.xml
> +++
> b/applications/manufacturing/widget/manufacturing/ProductionRunForms.xml
> @@ -80,7 +80,7 @@ under the License.
>  
>   title="${uiLabelMap.ProductProductId}"> target-form-name="LookupProduct"/>
>   title="${uiLabelMap.ManufacturingProductionRunName}">
> - title="${uiLabelMap.ManufacturingStartDate}"> default-value="${nowTimestamp}"/>
> + title="${uiLabelMap.ManufacturingStartDate}">
>  
>  
>   key-field-name="facilityId" description="${facilityName} [${facilityId}]">
>

Re: [jira] [Commented] (OFBIZ-11948) Remote Code Execution (File Upload) Vulnerability

[Pierre Smits]

Hi Jacques,

in a posting above, you stated:

* Adds "https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Fri, Feb 4, 2022 at 2:06 PM Jacques Le Roux 
wrote:

> Hi Pierre,
>
> How is your question related?
>
> Le 04/02/2022 à 12:53, Pierre Smits a écrit :
> > Hi Jacques,
> >
> > Wasn't there PHP code in the scrum application/ component to work with a
> > git repository?
> >
> > Or was that Python?
> >
> >
> > Op vr 4 feb. 2022 12:32 schreef ASF subversion and git services (Jira) <
> > j...@apache.org>:
> >
> >>  [
> >>
> https://issues.apache.org/jira/browse/OFBIZ-11948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487028#comment-17487028
> >> ]
> >>
> >> ASF subversion and git services commented on OFBIZ-11948:
> >> -
> >>
> >> Commit b0b02034eecf8d18ac7ea12f34469ec511269fa0 in ofbiz-framework's
> >> branch refs/heads/trunk from Jacques Le Roux
> >> [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b0b0203 ]
> >>
> >> Fixed: Remote Code Execution (File Upload) Vulnerability (OFBIZ-11948)
> >>
> >> Lion Tree  has reported us that
> >> "CVE-2020-1938 is not fully fixed".
> >>
> >> Though it was fixed by OFBIZ-11407, it still possible for an
> authenticated
> >> user
> >> to upload a webshell included in an image using one of the upload
> >> possibilities
> >> in OFBiz. That is not new and covered by OFBIZ-12080 "Secure the
> uploads",
> >> but
> >> was still incomplete.
> >>
> >> This enforces the secured uploads by
> >> * checking in SecuredUpload::isValidImageFile that a webshell is not
> >> embedded in
> >> an image.
> >> * Keeping only "<%" as a denied token for JSP webshells, instead of
> >> currently
> >> "<%@ page"
> >> * Adds "application/text/x-ruby" to SecuredUpload::isExecutable
> >>
> >> Also
> >> * Adds " >> it's often installed on servers.
> >> * Removes "import=\"java" and "runtime.getruntime().exec(". They are no
> >> longer useful since "<%" and " >> * Remove php token since I'll put " >> * Adds "#!", rather than adding other shebangs like perl,python and ruby
> >>
> >> This will make deniedWebShellTokens more understandable.
> >>
> >> But I'm conscious that despite SecuredUpload::isExecutableI I still
> need to
> >> better handle encoded webshells. I'll do that soon in a second approach.
> >>
> >> I'll also certainly more prune PHP related tokens.
> >>
> >> Thanks: Lion Tree for report
> >>
> >>
> >>> Remote Code Execution (File Upload) Vulnerability
> >>> -
> >>>
> >>>  Key: OFBIZ-11948
> >>>  URL:
> https://issues.apache.org/jira/browse/OFBIZ-11948
> >>>  Project: OFBiz
> >>>   Issue Type: Sub-task
> >>>   Components: product/catalog
> >>> Affects Versions: Trunk, 17.12.04, 18.12.01
> >>> Reporter: Jacques Le Roux
> >>> Assignee: Jacques Le Roux
> >>> Priority: Major
> >>>  Fix For: 17.12.05, 18.12.01
> >>>
> >>>
> >>> Harshit Shukla harshit.sh...@gmail.com reported this RCE vulnerability
> >> to the OFBiz security team, and we thank him for that.
> >>> I'll later quote here his email message when the vulnerability will be
> >> fixed. It's a post-auth vulnerability so we did not ask for a CVE.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian Jira
> >> (v8.20.1#820001)
> >>
>

Re: [jira] [Commented] (OFBIZ-11948) Remote Code Execution (File Upload) Vulnerability

[Pierre Smits]

Hi Jacques,

Wasn't there PHP code in the scrum application/ component to work with a
git repository?

Or was that Python?


Op vr 4 feb. 2022 12:32 schreef ASF subversion and git services (Jira) <
j...@apache.org>:

>
> [
> https://issues.apache.org/jira/browse/OFBIZ-11948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487028#comment-17487028
> ]
>
> ASF subversion and git services commented on OFBIZ-11948:
> -
>
> Commit b0b02034eecf8d18ac7ea12f34469ec511269fa0 in ofbiz-framework's
> branch refs/heads/trunk from Jacques Le Roux
> [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b0b0203 ]
>
> Fixed: Remote Code Execution (File Upload) Vulnerability (OFBIZ-11948)
>
> Lion Tree  has reported us that
> "CVE-2020-1938 is not fully fixed".
>
> Though it was fixed by OFBIZ-11407, it still possible for an authenticated
> user
> to upload a webshell included in an image using one of the upload
> possibilities
> in OFBiz. That is not new and covered by OFBIZ-12080 "Secure the uploads",
> but
> was still incomplete.
>
> This enforces the secured uploads by
> * checking in SecuredUpload::isValidImageFile that a webshell is not
> embedded in
> an image.
> * Keeping only "<%" as a denied token for JSP webshells, instead of
> currently
> "<%@ page"
> * Adds "application/text/x-ruby" to SecuredUpload::isExecutable
>
> Also
> * Adds " it's often installed on servers.
> * Removes "import=\"java" and "runtime.getruntime().exec(". They are no
> longer useful since "<%" and " * Remove php token since I'll put " * Adds "#!", rather than adding other shebangs like perl,python and ruby
>
> This will make deniedWebShellTokens more understandable.
>
> But I'm conscious that despite SecuredUpload::isExecutableI I still need to
> better handle encoded webshells. I'll do that soon in a second approach.
>
> I'll also certainly more prune PHP related tokens.
>
> Thanks: Lion Tree for report
>
>
> > Remote Code Execution (File Upload) Vulnerability
> > -
> >
> > Key: OFBIZ-11948
> > URL: https://issues.apache.org/jira/browse/OFBIZ-11948
> > Project: OFBiz
> >  Issue Type: Sub-task
> >  Components: product/catalog
> >Affects Versions: Trunk, 17.12.04, 18.12.01
> >Reporter: Jacques Le Roux
> >Assignee: Jacques Le Roux
> >Priority: Major
> > Fix For: 17.12.05, 18.12.01
> >
> >
> > Harshit Shukla harshit.sh...@gmail.com reported this RCE vulnerability
> to the OFBiz security team, and we thank him for that.
> > I'll later quote here his email message when the vulnerability will be
> fixed. It's a post-auth vulnerability so we did not ask for a CVE.
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.1#820001)
>

Re: [GitHub] [ofbiz-framework] mbrohl commented on pull request #498: Improved: WorkEffort - MainActionMenu (OFBIZ-12557)

[Pierre Smits]

Indeed, Michael. That was what you said  in comments regarding:

   1. https://github.com/apache/ofbiz-framework/pull/481
   2. https://github.com/apache/ofbiz-framework/pull/482
   3. https://github.com/apache/ofbiz-framework/pull/483

and now again in https://github.com/apache/ofbiz-framework/pull/498

What is this RULE of yours that fellow volunteering contributors MUST
comply with in order to have their improvements go into the codebase:

Is


it


single


line


spacing,


*or*


Is


ig


double


line


spacing?


It must surely feel very frustrating and annoying (even maybe painful?)
when YOU look at code in the OFBiz repositories and the majority of that
code not having the single or double line spacing that you want.
How unfortunate that all those contributors of code improvements over the
past 15 years of this project's existence (including you, contributing for
as long as that, as your claimed elsewhere) violated that RULE of yours
(that you brought forward just 11 days ago).

If the code of OFBiz (and improvements thereon) give you so much
difficulties to read, maybe there are some helpful tools available for you
to continue to bring your valuable contributions to improve this project
and its works? Or maybe it is time to call it quits?


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Thu, Feb 3, 2022 at 8:12 PM GitBox  wrote:

>
> mbrohl commented on pull request #498:
> URL:
> https://github.com/apache/ofbiz-framework/pull/498#issuecomment-1029313372
>
>
>As said before, the removal of blank lines between sections makes the
> files harder to read.
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
>

Re: [ofbiz-framework] branch trunk updated: Improved: no functional change, labels improvements

[Pierre Smits]

I'll not apologize either for following guidelines and practices
established, having the consensus.

Op do 3 feb. 2022 09:47 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:

> And again (again, again, again) all depend on context. Here it's quite
> obvious that there are no labels changes, only tabs replaced by spaces.
>
> I though agree that it should have been another commit, just that I missed
> that because I automate (too?) much things.
>
> I'll not apologize :p
>
> Le 03/02/2022 à 09:27, Michael Brohl a écrit :
> > I did not confirm that.
> >
> > My response was targeted to the wrong assumptions that the changes were
> only removes/same additions and the result of an unclean state of the
> > working copy.
> >
> > It is generally better to separate formatting / cleanup from real
> changes, which I did not mention here. For pull requests and patches,
> separation
> > helps the reviewer to see through and makes it possible to only merge
> commits which contain wanted changes.
> >
> > Not sure if this warrants a mail to dev, at least you were the one
> lately who complained to not play the blame game [1].
> >
> > Michael
> >
> > [1] https://lists.apache.org/thread/93ptk5nfrf2pjfwnl6ovm0lc6l42yb85
> >
> >
> > Am 03.02.22 um 08:18 schrieb Pierre Smits:
> >> Good to see that the two of you confirm that cleanup can be combined
> with
> >> other improvements .
> >>
> >> Op do 3 feb. 2022 07:15 schreef Jacques Le Roux <
> >> jacques.le.r...@les7arts.com>:
> >>
> >>> Yep, thanks Michael,
> >>>
> >>> Jacques
> >>>
> >>> Le 02/02/2022 à 23:33, Michael Brohl a écrit :
> >>>> If I see it right, he has corrected wrong indentations. Nothing wrong
> >>> with that...
> >>>> Michael
> >>>>
> >>>>
> >>>> Am 02.02.22 um 18:00 schrieb Pierre Smits:
> >>>>> Hi Jacques,
> >>>>>
> >>>>> With this commit 8a9596be849f6709cb17c24a598c4862e8df867c you deleted
> >>> and
> >>>>> reinserted a lot of german translations (without any changes in the
> >>>>> translation at first glance).
> >>>>>
> >>>>> Were these necessary, or an unfortunate combination of circumstances
> >>>>> leading to you not working with a clean dev branch? It is a pity this
> >>>>> happened. Luckily, the impact is trivial. But people tend to get
> >>> confused
> >>>>> by this, and it could lead to complaints or heated arguments.
> >>>>>
> >>>>> Can you be a bit more careful next time around?
> >>>>>
> >>>>> Atentamente
> >>>>> Met vriendelijke groet,
> >>>>>
> >>>>> Pierre Smits
> >>>>> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> >>> since
> >>>>> 2008 (without privileges)
> >>>>> Proud contributor to the ASF since 2006
> >>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>>
> >>>>> Anyone could have been you, whereas I've always been anyone.
> >>>>>
> >>>>>
> >>>>> On Sun, Jan 16, 2022 at 8:52 AM  wrote:
> >>>>>
> >>>>>> This is an automated email from the ASF dual-hosted git repository.
> >>>>>>
> >>>>>> jleroux pushed a commit to branch trunk
> >>>>>> in repository
> https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> >>>>>>
> >>>>>>
> >>>>>> The following commit(s) were added to refs/heads/trunk by this push:
> >>>>>>new 8a9596b  Improved: no functional change, labels
> improvements
> >>>>>> 8a9596b is described below
> >>>>>>
> >>>>>> commit 8a9596be849f6709cb17c24a598c4862e8df867c
> >>>>>> Author: Jacques Le Roux 
> >>>>>> AuthorDate: Sun Jan 16 08:51:03 2022 +0100
> >>>>>>
> >>>>>>   Improved: no functional change, labels improvements
> >>>>>>
> >>>>>>   In French, and maybe other languages, there is not only one
> word
> >>> for
> >>>>>> new.
> >>>>>>   There are nouveau (masculine), 

Re: [ofbiz-framework] branch trunk updated: Improved: no functional change, labels improvements

[Pierre Smits]

Good to see that the two of you confirm that cleanup can be combined with
other improvements .

Op do 3 feb. 2022 07:15 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:

> Yep, thanks Michael,
>
> Jacques
>
> Le 02/02/2022 à 23:33, Michael Brohl a écrit :
> > If I see it right, he has corrected wrong indentations. Nothing wrong
> with that...
> >
> > Michael
> >
> >
> > Am 02.02.22 um 18:00 schrieb Pierre Smits:
> >> Hi Jacques,
> >>
> >> With this commit 8a9596be849f6709cb17c24a598c4862e8df867c you deleted
> and
> >> reinserted a lot of german translations (without any changes in the
> >> translation at first glance).
> >>
> >> Were these necessary, or an unfortunate combination of circumstances
> >> leading to you not working with a clean dev branch? It is a pity this
> >> happened. Luckily, the impact is trivial. But people tend to get
> confused
> >> by this, and it could lead to complaints or heated arguments.
> >>
> >> Can you be a bit more careful next time around?
> >>
> >> Atentamente
> >> Met vriendelijke groet,
> >>
> >> Pierre Smits
> >> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> >> 2008 (without privileges)
> >> Proud contributor to the ASF since 2006
> >> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>
> >> Anyone could have been you, whereas I've always been anyone.
> >>
> >>
> >> On Sun, Jan 16, 2022 at 8:52 AM  wrote:
> >>
> >>> This is an automated email from the ASF dual-hosted git repository.
> >>>
> >>> jleroux pushed a commit to branch trunk
> >>> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> >>>
> >>>
> >>> The following commit(s) were added to refs/heads/trunk by this push:
> >>>   new 8a9596b  Improved: no functional change, labels improvements
> >>> 8a9596b is described below
> >>>
> >>> commit 8a9596be849f6709cb17c24a598c4862e8df867c
> >>> Author: Jacques Le Roux 
> >>> AuthorDate: Sun Jan 16 08:51:03 2022 +0100
> >>>
> >>>  Improved: no functional change, labels improvements
> >>>
> >>>  In French, and maybe other languages, there is not only one word
> for
> >>> new.
> >>>  There are nouveau (masculine), nouvelle (féminine) and nouvel
> >>> (masculine followed
> >>>  by a word starting with a vowel)
> >>>
> >>>  Here are few related changes with existing AccountingUiLabels,
> >>> HumanResUiLabel
> >>>  changes and a new CommonUiLabels French labels improvements and
> use of
> >>>  HumanResNew* labels in MainActionMenu of HumanresMenus.xml
> >>>
> >>>  Also alongside replaces tabs by spaces in HumanResUiLabel
> >>> ---
> >>>   .../accounting/config/AccountingUiLabels.xml   |   2 +-
> >>>   applications/humanres/config/HumanResUiLabels.xml  | 104
> >>> ++---
> >>>   applications/humanres/widget/HumanresMenus.xml |  10 +-
> >>>   framework/common/config/CommonUiLabels.xml |   1 +
> >>>   4 files changed, 59 insertions(+), 58 deletions(-)
> >>>
> >>> diff --git a/applications/accounting/config/AccountingUiLabels.xml
> >>> b/applications/accounting/config/AccountingUiLabels.xml
> >>> index 7c34628..b87f294 100644
> >>> --- a/applications/accounting/config/AccountingUiLabels.xml
> >>> +++ b/applications/accounting/config/AccountingUiLabels.xml
> >>> @@ -22296,7 +22296,7 @@
> >>>   Hauptbuch Transaktion
> >>>   a Gl Transaction
> >>>   uno Transaccione GL
> >>> -une opération comptable
> >>> +une transaction comptable
> >>>   GLトランザクション
> >>>   Transaçõe contábei
> >>>   
> >>> diff --git a/applications/humanres/config/HumanResUiLabels.xml
> >>> b/applications/humanres/config/HumanResUiLabels.xml
> >>> index 92d73e9..b77036a 100644
> >>> --- a/applications/humanres/config/HumanResUiLabels.xml
> >>> +++ b/applications/humanres/config/HumanResUiLabels.xml
> >>> @@ -856,7 +856,7 @@
> >>>   技能等級
> >>>   
> >>>   
> >>> -   

Re: [ofbiz-framework] branch trunk updated: Improved: no functional change, labels improvements

[Pierre Smits]

Hi Jacques,

With this commit 8a9596be849f6709cb17c24a598c4862e8df867c you deleted and
reinserted a lot of german translations (without any changes in the
translation at first glance).

Were these necessary, or an unfortunate combination of circumstances
leading to you not working with a clean dev branch? It is a pity this
happened. Luckily, the impact is trivial. But people tend to get confused
by this, and it could lead to complaints or heated arguments.

Can you be a bit more careful next time around?

Atentamente
Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Sun, Jan 16, 2022 at 8:52 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> jleroux pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>  new 8a9596b  Improved: no functional change, labels improvements
> 8a9596b is described below
>
> commit 8a9596be849f6709cb17c24a598c4862e8df867c
> Author: Jacques Le Roux 
> AuthorDate: Sun Jan 16 08:51:03 2022 +0100
>
> Improved: no functional change, labels improvements
>
> In French, and maybe other languages, there is not only one word for
> new.
> There are nouveau (masculine), nouvelle (féminine) and nouvel
> (masculine followed
> by a word starting with a vowel)
>
> Here are few related changes with existing AccountingUiLabels,
> HumanResUiLabel
> changes and a new CommonUiLabels French labels improvements and use of
> HumanResNew* labels in MainActionMenu of HumanresMenus.xml
>
> Also alongside replaces tabs by spaces in HumanResUiLabel
> ---
>  .../accounting/config/AccountingUiLabels.xml   |   2 +-
>  applications/humanres/config/HumanResUiLabels.xml  | 104
> ++---
>  applications/humanres/widget/HumanresMenus.xml |  10 +-
>  framework/common/config/CommonUiLabels.xml |   1 +
>  4 files changed, 59 insertions(+), 58 deletions(-)
>
> diff --git a/applications/accounting/config/AccountingUiLabels.xml
> b/applications/accounting/config/AccountingUiLabels.xml
> index 7c34628..b87f294 100644
> --- a/applications/accounting/config/AccountingUiLabels.xml
> +++ b/applications/accounting/config/AccountingUiLabels.xml
> @@ -22296,7 +22296,7 @@
>  Hauptbuch Transaktion
>  a Gl Transaction
>  uno Transaccione GL
> -une opération comptable
> +une transaction comptable
>  GLトランザクション
>  Transaçõe contábei
>  
> diff --git a/applications/humanres/config/HumanResUiLabels.xml
> b/applications/humanres/config/HumanResUiLabels.xml
> index 92d73e9..b77036a 100644
> --- a/applications/humanres/config/HumanResUiLabels.xml
> +++ b/applications/humanres/config/HumanResUiLabels.xml
> @@ -856,7 +856,7 @@
>  技能等級
>  
>  
> -   Fähigkeit Typ ID
> +Fähigkeit Typ ID
>  Skill Type ID
>  Id tipo de habilidad
>  Compétence
> @@ -882,7 +882,7 @@
>  技能掌握日期
>  
>  
> -   temporäres Kennzeichen
> +temporäres Kennzeichen
>  Temporary Flag
>  Indicador Principal
>  Balise temporaire
> @@ -895,7 +895,7 @@
>  是否為臨時
>  
>  
> -   Nummer des Kündigungsgrundes
> +Nummer des Kündigungsgrundes
>  Termination Reason ID
>  Id de razón de finiquito
>  Motif de la fin de contrat
> @@ -908,7 +908,7 @@
>  雇佣終止原因識別
>  
>  
> -   Kündigungsart ID
> +Kündigungsart ID
>  Termination Type ID
>  Id tipo de finiquito
>  Type de fin de contrat
> @@ -921,7 +921,7 @@
>  雇佣終止類型識別
>  
>  
> -   Titel
> +Titel
>  Title
>  Título
>  Titre
> @@ -931,7 +931,7 @@
>  標題
>  
>  
> -   Nummer der Schulungsklasse
> +Nummer der Schulungsklasse
>  Training Class Type ID
>  ID de tipo de clase de capacitación
>  Type de formation
> @@ -943,7 +943,7 @@
>  教育訓練課程類型識別
>  
>  
> -   Anfragenummer der Schulung
> +Anfragenummer der Schulung
>  Training Request ID
>  ID de solicitud de capacitación
>  Approbation
> @@ -953,7 +953,7 @@
>  教育訓練請求標識
>  
>  
> -   Datum des Arbeitslos

Re: [jira] [Updated] (OFBIZ-6349) Replace ViewQuoteItems.ftl with form widgets

[Pierre Smits]

Hi Nicolas, Christian,

Are you both still collaborating to get this issue successfully resolved?
It seems to me that the both of you, being privileged contributors, should
easily get this in play.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Fri, Sep 18, 2015 at 4:20 PM Michael Brohl (JIRA) 
wrote:

>
>  [
> https://issues.apache.org/jira/browse/OFBIZ-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Michael Brohl updated OFBIZ-6349:
> -
> Sprint: Community Day 2 - 2015, Community Day 3 - 2015  (was:
> Community Day 2 - 2015)
>
> > Replace ViewQuoteItems.ftl with form widgets
> > 
> >
> > Key: OFBIZ-6349
> > URL: https://issues.apache.org/jira/browse/OFBIZ-6349
> > Project: OFBiz
> >  Issue Type: Improvement
> >  Components: order
> >Affects Versions: Trunk
> >Reporter: Christian Carlow
> >Assignee: Nicolas Malin
> > Attachments: OFBIZ-6349.patch
> >
> >
>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: Guideline translation definition and the application there of in service functions and widget element, o.a.

[Pierre Smits]

ng up are thus not limited in their
choices. That is - without limitation-  the promise of Open Source
solutions from the ASF.

If users are not content with what contributors incorporate into the
codebase, they have no grounds for complaints. Because of the following
statement of each file included:

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.


The OFBiz project distributes code under that license. And because they can
modify the code they use as they see fit. So, please stop using that
argument.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Sun, Jan 30, 2022 at 12:09 PM Michael Brohl 
wrote:

> Thanks Pierre,
>
> the technical part looks good to me at first glance, I would though find
> it more appropriate to enhance the existing documentation set up by
> Adrian [1] instead of introducing another wiki page.
>
> The last part contains suggestions to the reader which do not adhere to
> the projects view, namely the intention to reuse labels from other
> applications instead of using context related specified labels in the
> application itself. This was discussed between us and with other
> contributors many times in the past and you still insist to do it
> otherwise.
>
> For reference, I point interested people to some of these discussions
> and issues from the past: [2] [3] [4]. There are more.
>
> Some of the arguments to use specified labels instead of common labels
> and/or labels from other applications are:
>
> - doing otherwise removes the flexibility for users to use different
> translations in different contexts. If you change the translation in
> this one place, it will also be changed anywhere else,
>
> - even in a single installation of OFBiz, the same field might be
> translated differently between applications because they are used by
> different departments with their own terminology (true especially for
> bigger companies),
>
> - in English, you often can use the same translation but in other
> languages, words are very different based on the context. Even the
> number of words differ,
>
> - you would have to reference UI label maps from other applications
> which should be avoided because of (circular) dependencies. If we
> already have those situations, we should not extend it further.
>
>
> So I propose that the project gives a clear understanding that
>
> - specific labels should be used instead of common labels or reusing
> labels from other applications,
>
> - new specific labels should be created instead of common labels be used,
>
> - common labels CAN be used for action widgets like buttons (search,
> edit, delete) etc. which are the same in every context. This has to be
> checked though against languages
>
> - changes in patches or pull requests, which do not align with those
> guidelines, should not be merged to the codebase.
>
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> [1]
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Internationalization?src=contextnavchildmode
>
> [2] https://issues.apache.org/jira/browse/OFBIZ-10772 (and subtasks)
>
> [3]
>
> https://issues.apache.org/jira/browse/OFBIZ-8110?jql=project%20%3D%20OFBIZ%20AND%20text%20~%20%22Maximise%20utilisation%20of%20common%20labels%22
>
> [4] https://lists.apache.org/thread/47lz9mytw2p7zzryddogt1283kkmkz2c
>
> Am 29.01.22 um 18:28 schrieb Pierre Smits:
> > Hi all,
> >
> > Over the years, contributions of translation definitions and
> contributions
> > to apply or change translation definitions in field and other widgets
> have
> > led to heated right-vs-wrong debates between contributors in tickets and
> > elsewhere. In order to unify the community, to decrease the number of
> these
> > heated debates and bring us back to happy collaborating to improve OFBiz,
> >   I have writtena guideline regarding this subject.
> >
> > This guideline can be found here:
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199533364
> >
> > I invite all to evaluate this guideline and provide feedback
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> > Proud contributor to the ASF since 2006
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> >
> > Anyone could have been you, whereas I've always been anyone.
>

Guideline translation definition and the application there of in service functions and widget element, o.a.

[Pierre Smits]

Hi all,

Over the years, contributions of translation definitions and contributions
to apply or change translation definitions in field and other widgets have
led to heated right-vs-wrong debates between contributors in tickets and
elsewhere. In order to unify the community, to decrease the number of these
heated debates and bring us back to happy collaborating to improve OFBiz,
 I have writtena guideline regarding this subject.

This guideline can be found here:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199533364

I invite all to evaluate this guideline and provide feedback

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Fri, Jan 28, 2022 at 4:24 PM Daniel Watford  wrote:

> Hi Michael,
>
> Yes, those labels were intentional. My view was that introducing common
> labels in cases where there were previously no labels at all was an
> improvement.
>
> Had there already been specific labels in place, these would have been left
> alone.
>
> Summary of my review approach:
> - Changing from application specific labels to common labels is unlikely to
> be committed without good reason because of the risk of losing the original
> application's intention when translated to different languages.
> - Changes from no label at all to a common label seem reasonable since we
> have the potential benefit of already existing generic translations from
> the common label set.
>
> Of course there will be exceptions to every rule, but in this case I
> thought the changes appropriate and an improvement.
>
> Thanks,
>
> Dan.
>
>
> On Fri, 28 Jan 2022 at 14:38, Michael Brohl 
> wrote:
>
> > Hi Dan,
> >
> > is this commit intentional?
> >
> > It still has unwanted changes introducing titles with common labels
> > instead of specific labels (e.g. CommonLocation for jobLocation).
> >
> > Regards,
> >
> > Michael
> >
> >
> > Am 28.01.22 um 08:49 schrieb danwatf...@apache.org:
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > danwatford pushed a commit to branch trunk
> > > in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/trunk by this push:
> > >   new b2dd912  Improved: Recruitment screens updated to use Grid
> > rather than list forms (OFBIZ-11345)
> > > b2dd912 is described below
> > >
> > > commit b2dd912794f083a6176dbd581967e2f97c3c183a
> > > Author: Pierre Smits 
> > > AuthorDate: Fri Jan 28 08:49:01 2022 +0100
> > >
> > >  Improved: Recruitment screens updated to use Grid rather than list
> > forms (OFBIZ-11345)
> > >
> > >
> > >  According to the definition in widget-form.xsd the
> > >  use of a combination of a form with type="list" is
> > >  deprecated in favour of a grid. Therefore refactored various
> > >  Recruitment forms to use grid and updated references from
> > >  relevant screens to forms.
> > >
> > >  Thanks: Pierre Smits for changes.
> > > ---
> > >   .../humanres/widget/RecruitmentScreens.xml | 12 +++
> > >   .../humanres/widget/forms/RecruitmentForms.xml | 42
> > +++---
> > >   2 files changed, 26 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/applications/humanres/widget/RecruitmentScreens.xml
> > b/applications/humanres/widget/RecruitmentScreens.xml
> > > index 7072f0a..2452265 100644
> > > --- a/applications/humanres/widget/RecruitmentScreens.xml
> > > +++ b/applications/humanres/widget/RecruitmentScreens.xml
> > > @@ -20,7 +20,7 @@ under the License.
> > >   http://www.w3.org/2001/XMLSchema-instance;
> > >   xmlns="http://ofbiz.apache.org/Widget-Screen;
> xsi:schemaLocation="
> > http://ofbiz.apache.org/Widget-Screen
> > http://ofbiz.apache.org/dtds/widget-screen.xsd;>
> > >   
> > > -
> > > +
> > >   
> > >> value="PageTitleFindJobRequisition"/>
> > >   
> > > @@ -54,7 +54,7 @@ under the License.
> > >> name="FindJobRequisiti

Re: [GitHub] [ofbiz-framework] JacquesLeRoux edited a comment on pull request #466: Improved: List and Grid (OFBIZ-11345)

[Pierre Smits]

Playing the 'blame' game is detrimental to the success of the project, and
thus to all using, contributing, making a living with...
Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Thu, Jan 27, 2022 at 3:55 PM Pierre Smits  wrote:

> Jacques,
>
> It is of lesser importance of from when it dated or who provided the code
> improvement and who merged it in the codebase. What is more important how
> many hulrdles are brought into play to get it improved.
>
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
> 2008 (without privileges)
> Proud contributor to the ASF since 2006
> *Apache Directory <https://directory.apache.org>, PMC Member*
>
> Anyone could have been you, whereas I've always been anyone.
>
>
> On Thu, Jan 27, 2022 at 3:21 PM GitBox  wrote:
>
>>
>> JacquesLeRoux edited a comment on pull request #466:
>> URL:
>> https://github.com/apache/ofbiz-framework/pull/466#issuecomment-1023259680
>>
>>
>>> >
>>That's indeed wrong in any cases (in RecruitmentForms.xml), and dates
>> from Jira OFBIZ-2205
>>
>>
>> --
>> This is an automated message from the Apache Git Service.
>> To respond to the message, please log on to GitHub and use the
>> URL above to go to the specific comment.
>>
>> To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org
>>
>> For queries about this service, please contact Infrastructure at:
>> us...@infra.apache.org
>>
>>
>>

Re: [GitHub] [ofbiz-framework] JacquesLeRoux edited a comment on pull request #466: Improved: List and Grid (OFBIZ-11345)

[Pierre Smits]

Jacques,

It is of lesser importance of from when it dated or who provided the code
improvement and who merged it in the codebase. What is more important how
many hulrdles are brought into play to get it improved.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Thu, Jan 27, 2022 at 3:21 PM GitBox  wrote:

>
> JacquesLeRoux edited a comment on pull request #466:
> URL:
> https://github.com/apache/ofbiz-framework/pull/466#issuecomment-1023259680
>
>
>> 
>That's indeed wrong in any cases (in RecruitmentForms.xml), and dates
> from Jira OFBIZ-2205
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
>

Re: [ofbiz-framework] branch trunk updated: Fixed: Upgrade Tomcat from 9.0.54 to 9.0.58 (OFBIZ-12539)

[Pierre Smits]

Jacques,

I don't know for a release from r18, but regarding a release from r22, you
could consider sharing your viewpoint in thread 'Time to cut the first
release of the R22 branch?' instead of here.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Wed, Jan 26, 2022 at 2:04 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pierre, All,
>
> Yes saw that, complications comes with me using Win7.
>
> As I said in the Jira: I'm not sure we need to make new releases (18 and
> 22).
> Because I doubt users persist sessions using advanced FileStore feature.
> So maybe simply a warning could be sufficient.
>
> Jacques
>
> Le 26/01/2022 à 12:42, Pierre Smits a écrit :
> > Hey Jacques,
> >
> > It seems to me that this commit does not address the issue described in
> the
> > referenced ticket: https://issues.apache.org/jira/browse/OFBIZ-12539.
> >
> > Should this not be corrected? E.g. having its own ticket?
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> > Proud contributor to the ASF since 2006
> >
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> >
> > Anyone could have been you, whereas I've always been anyone.
> >
> >
> > On Wed, Jan 26, 2022 at 12:34 PM  wrote:
> >
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> jleroux pushed a commit to branch trunk
> >> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/trunk by this push:
> >>   new 6ed30b7  Fixed: Upgrade Tomcat from 9.0.54 to 9.0.58
> (OFBIZ-12539)
> >> 6ed30b7 is described below
> >>
> >> commit 6ed30b76652e24162bcbc6efe4ca912ba0e31bc2
> >> Author: Jacques Le Roux 
> >> AuthorDate: Wed Jan 26 12:31:50 2022 +0100
> >>
> >>  Fixed: Upgrade Tomcat from 9.0.54 to 9.0.58 (OFBIZ-12539)
> >>
> >>  The fix for bug CVE-2020-9484 introduced a time of check, time of
> use
> >>  vulnerability that allowed a local attacker to perform actions
> with the
> >>  privileges of the user that the Tomcat process is using. This
> issue is
> >> only
> >>  exploitable when Tomcat is configured to persist sessions using the
> >> FileStore.
> >> ---
> >>   themes/common-theme/webapp/common/js/package.json | 33
> >> ---
> >>   1 file changed, 18 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/themes/common-theme/webapp/common/js/package.json
> >> b/themes/common-theme/webapp/common/js/package.json
> >> index 036a227..429ade6 100644
> >> --- a/themes/common-theme/webapp/common/js/package.json
> >> +++ b/themes/common-theme/webapp/common/js/package.json
> >> @@ -1,17 +1,20 @@
> >>   {
> >> -  "name": "ofbiz-framework",
> >> -  "description": "ofbiz-framework NPM dependencies configuration",
> >> -  "repository": "https://github.com/apache/ofbiz-framework.git;,
> >> -  "license": "Apache-2.0",
> >> -  "dependencies": {
> >> -"jquery": "^3.6.0",
> >> -"jquery-migrate": "^3.3.2",
> >> -"jquery-validation": "^1.19.3",
> >> -"jquery.browser": "^0.1.0",
> >> -"dompurify": "^2.3.4",
> >> -"jquery-ui-dist": "^1.13.0",
> >> -"trumbowyg": "^2.25.1",
> >> -"flot": "^4.2.2",
> >> -"@chinchilla-software/jquery-ui-timepicker-addon": "^1.6.3"
> >> -  }
> >> +"name": "ofbiz-framework",
> >> +"description": "ofbiz-framework NPM dependencies configuration",
> >> +"repository": "https://github.com/apache/ofbiz-framework.git;,
> >> +"license": "Apache-2.0",
> >> +"dependencies": {
> >> +"jquery": "^3.6.0",
> >> +"jquery-migrate": "^3.3.2",
> >> +"jquery-validation": "^1.19.3",
> >> +"jquery.browser": "^0.1.0",
> >> +"dompurify": "^2.3.4",
> >> +"jquery-ui-dist": "^1.13.0",
> >> +"trumbowyg": "^2.25.1",
> >> +"flot": "^4.2.2",
> >> +"@chinchilla-software/jquery-ui-timepicker-addon": "^1.6.3"
> >> +},
> >> +"scripts": {
> >> +"lint": "jshint **.js --reporter checkstyle > checkstyle.xml"
> >> +}
> >>   }
> >>
>

Time to cut the first release of the R22 branch?

[Pierre Smits]

Hi All,

it has been years since we cut the branch before the R22, and a lot of
improvements have gone into trunk and subsequently into the R22 branch.

As per https://issues.apache.org/jira/projects/OFBIZ/versions/12342403 it
seems all tickets related to the first release of that branch have been
concluded successfully.

Is it therefore now the moment to establish the first release of the branch
(being release 22.01.01)

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.

Re: [ofbiz-framework] branch trunk updated: Fixed: Upgrade Tomcat from 9.0.54 to 9.0.58 (OFBIZ-12539)

[Pierre Smits]

Hey Jacques,

It seems to me that this commit does not address the issue described in the
referenced ticket: https://issues.apache.org/jira/browse/OFBIZ-12539.

Should this not be corrected? E.g. having its own ticket?


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Wed, Jan 26, 2022 at 12:34 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> jleroux pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>  new 6ed30b7  Fixed: Upgrade Tomcat from 9.0.54 to 9.0.58 (OFBIZ-12539)
> 6ed30b7 is described below
>
> commit 6ed30b76652e24162bcbc6efe4ca912ba0e31bc2
> Author: Jacques Le Roux 
> AuthorDate: Wed Jan 26 12:31:50 2022 +0100
>
> Fixed: Upgrade Tomcat from 9.0.54 to 9.0.58 (OFBIZ-12539)
>
> The fix for bug CVE-2020-9484 introduced a time of check, time of use
> vulnerability that allowed a local attacker to perform actions with the
> privileges of the user that the Tomcat process is using. This issue is
> only
> exploitable when Tomcat is configured to persist sessions using the
> FileStore.
> ---
>  themes/common-theme/webapp/common/js/package.json | 33
> ---
>  1 file changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/themes/common-theme/webapp/common/js/package.json
> b/themes/common-theme/webapp/common/js/package.json
> index 036a227..429ade6 100644
> --- a/themes/common-theme/webapp/common/js/package.json
> +++ b/themes/common-theme/webapp/common/js/package.json
> @@ -1,17 +1,20 @@
>  {
> -  "name": "ofbiz-framework",
> -  "description": "ofbiz-framework NPM dependencies configuration",
> -  "repository": "https://github.com/apache/ofbiz-framework.git;,
> -  "license": "Apache-2.0",
> -  "dependencies": {
> -"jquery": "^3.6.0",
> -"jquery-migrate": "^3.3.2",
> -"jquery-validation": "^1.19.3",
> -"jquery.browser": "^0.1.0",
> -"dompurify": "^2.3.4",
> -"jquery-ui-dist": "^1.13.0",
> -"trumbowyg": "^2.25.1",
> -"flot": "^4.2.2",
> -"@chinchilla-software/jquery-ui-timepicker-addon": "^1.6.3"
> -  }
> +"name": "ofbiz-framework",
> +"description": "ofbiz-framework NPM dependencies configuration",
> +"repository": "https://github.com/apache/ofbiz-framework.git;,
> +"license": "Apache-2.0",
> +"dependencies": {
> +"jquery": "^3.6.0",
> +"jquery-migrate": "^3.3.2",
> +"jquery-validation": "^1.19.3",
> +"jquery.browser": "^0.1.0",
> +"dompurify": "^2.3.4",
> +"jquery-ui-dist": "^1.13.0",
> +"trumbowyg": "^2.25.1",
> +"flot": "^4.2.2",
> +"@chinchilla-software/jquery-ui-timepicker-addon": "^1.6.3"
> +},
> +"scripts": {
> +"lint": "jshint **.js --reporter checkstyle > checkstyle.xml"
> +}
>  }
>

Re: [jira] [Commented] (OFBIZ-7456) Introduce the option to add the new Customer/Supplier while placing the quotes in system if they don't exist already

[Pierre Smits]

Are we going to abandon the principles of KISS and YAGNI with this?

Are we going to allow that requests (tickets) for functionality, and code
improvements are done re e.g. to create/edit products, prices for products
and services, suppliers, customers, etc in e.g. accounting? Or facility? Or
work effort? Or what ever component in either ofbiz-framework or
ofbiz-plugins?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Apr 12, 2021 at 12:33 PM ASF subversion and git services (Jira) <
j...@apache.org> wrote:

>
> [
> https://issues.apache.org/jira/browse/OFBIZ-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319339#comment-17319339
> ]
>
> ASF subversion and git services commented on OFBIZ-7456:
> 
>
> Commit 9b4a4ad8d6cad55d508cac030396f5a0276c471c in ofbiz-framework's
> branch refs/heads/trunk from Joonas Hiltunen
> [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=9b4a4ad ]
>
> Implemented:  Add new party while placing quotes (OFBIZ-7456) (#294)
>
> Introduce the option to create a new party group while placing the quotes
> in the system.
>
> > Introduce the option to add the new Customer/Supplier while placing the
> quotes in system if they don't exist already
> >
> 
> >
> > Key: OFBIZ-7456
> > URL: https://issues.apache.org/jira/browse/OFBIZ-7456
> > Project: OFBiz
> >  Issue Type: New Feature
> >  Components: order
> >Affects Versions: 14.12.01, 15.12.01
> >Reporter: Swapnil Shah
> >Assignee: Pawan Verma
> >Priority: Major
> >
> > On numerous occasions while placing Sales or Purchase quote in system,
> the business is conducted first time with given party and its quite
> possible that given party don't pre-exist in system.
> > At that point of time user could be allowed to create the party in
> either Customer or Supplier role by asking few primary details as follows:
> > # Party Name
> > # Billing/Shipping Address
> > Rest of the details can be later added/update with respect to added
> party from Party screens.
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
>

Fwd: [jira] [Commented] (OFBIZ-12534) Comments on Commits in Github must go to a mailing list of the project

[Pierre Smits]

Forwarded to the dev@ofbiz mailing list of OFBiz for those community
members (and other participants) not subscribed to the notifications@ofbiz
mailing list.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


-- Forwarded message -
From: Pierre Smits (Jira) 
Date: Tue, Jan 25, 2022 at 2:49 PM
Subject: [jira] [Commented] (OFBIZ-12534) Comments on Commits in Github
must go to a mailing list of the project
To: 



[
https://issues.apache.org/jira/browse/OFBIZ-12534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481832#comment-17481832
]

Pierre Smits commented on OFBIZ-12534:
--

Hi Jacques,

I am, like I told you before else thread, NOT going to create anything in
JIRA for INFRA. Like I said then: I have tried that before to improve stuff
which required their involvement and have been shot down by various INFRA
members on several occasions that they won't consider my requests without
PMC approval/consensus.

Wit the posting of the ticket members of the PMC have been notified and can
take the appropriate actions to ensure than no unnecessary hurdles are
created/maintained for (new) contributors willing to contribute.



Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Tue, Jan 25, 2022 at 2:23 PM Jacques Le Roux (Jira) 



> Comments on Commits in Github must go to a mailing list of the project
> --
>
> Key: OFBIZ-12534
> URL: https://issues.apache.org/jira/browse/OFBIZ-12534
> Project: OFBiz
>  Issue Type: Improvement
>  Components: GitHub
>Reporter: Pierre Smits
>Priority: Major
>
> Currently, when a contributor posts a comment to a (merged) commit in
Github, this comment does not end up in one of the mailing lists of the
project, whereas comments to pull request in Github do.
> This not forwarding/sending of a comment to a mailing list of the project
should not happen, as per one of the ASF mottos: if it didn't land in a
mailing list, it didn't happen.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: [jira] [Commented] (OFBIZ-12489) Product Prices - VIEW permissions

[Pierre Smits]

Michael,

I told you before in (other) tickets to stop trolling me through your
complaints in the tickets I am working on. You continue to do this.
Your remarks about you not committing the code contributions of
unprivileged contributors are totally inappropriate.  Not appropriate in
ticket comments, nor in the mailing lists of the project. Nobody is
strong-arming you to commit or merge improvements. Nobody is expecting you
ever will.
Stop trying to pressure fellow contributors, collaborating to improve
OFBiz, to follow your dictate by your attempt to frame a narrative that
there is an agreement about how contributors are to contribute what, where
and when.
Such narrative is solely intended to dictate the direction of the project
for your self serving purposes, resulting in alienating fellow contributors
from collaborating in the OFBiz project to get improvements into its
repositories.

There has never been such an agreement on how, what, where and when to
contribute in the OFBiz community. Nor on the specific subject of what the
correct translation label that is to be used in OFBiz screens and forms.
No discussion on that latter subject has ever been started on the dev
mailing list, nor is there any series of postings on that list that could
lead to someone being able to claim that a kind of consensus could be
derived from such a thread.

It appears, IMO, that you don't want what is for the good of the public
through the deliverables of the OFBiz project.
Your business needs and goals are not the concerns of the project, nor the
concerns of the contributors not paid by you(r company).
You keep your Ecomify rules re OFBiz to yourself and for your employees,
instead of presenting them as rules (or agreements) of the project. In this
project there are no such 'contribution' rules.
There are only guidelines, and precedents established over time within the
project. And these indicate that anything goes.

If you want to change what the way is how contributions are done to the
project, you start a discussion on the dev mailing list of the project and
work that discussion towards a consensus. Alternatively you follow the lead
of what many of your fellow privileged contributors do in this project
nowadays.

Again: s*top trolling me*. You bring nothing new to the tickets I am
working. Keep your complaints to yourself, or use them to create a positive
change to the project that will make OFBiz more appealing, more
trustworthy, attracting a greater diversity of contributors instead of a
negative change.

If you want to improve OFBiz, go work the tickets that have your name as
the assignee to a successful conclusion (or take those of the contributors
paid by your company, or - if that is all done - take those that are
unassigned as there are plenty of possibilities there), instead of
harassing fellow contributors and me collaborating to improve OFBiz.



Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Jan 24, 2022 at 3:57 PM Michael Brohl (Jira) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/OFBIZ-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481153#comment-17481153
> ]
>
> Michael Brohl commented on OFBIZ-12489:
> ---
>
> Thanks Jacques.
>
> I think you misunderstood my point respectively I made myself not clear
> enough. I know that we agreed upon the use of common labels vs. specific
> labels and simply put a reminder to give context. I didn't meant to say
> that you don't care about labels and I'm sorry if it came across this way.
>
> I totally agree with your statement "I have always thought that example is
> better than commanding."
>
> In this case, I do not think the lack of example is the problem. We've
> spent a lot of energy together to explain the points with common vs.
> specific labels and quite a few issues were resolved as "Won't do" in this
> course.
>
> Being unfair was in no way targeted to you but to the contributor who
> seems to intentionally ignore past decisions and still tries to sneak in
> his point of view through contributions, often not even mentioning those
> changes in the commit messages.
>
> As a result, I won't commit those changes but insist that the contributor
> does the correction before the changes go to the codebase. Why should
> anyone else be bothered with this task than the contributor himself?
>
> Not sure if it will be a lesson because it had no consequences for the
> contributor. Where's the learning effect then?
>
> I will spent my time reviewing and commenting the PR's which I did the
> last days. I'm not sure if I am able or willing to 

Re: Remove Jira archived versions?

[Pierre Smits]

Hi Jacques,

I advise against the removal of archived versions. With the availability of
those, we can get

   - more/better insights in actual versions used when contributors asked
   to set the 'affected version(s) field;
   - contributors can then react quicker to such tickets with:
  - either a 'won't do', or
  - asking for further investigations (if branch is still current)

I would think that for this it would be best to follow the protocol we
apply to tags in the repository (we don't delete tags there).

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Fri, Jan 14, 2022 at 6:21 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> If nobody is against I'll made some cleaning Monday
>
> Jacques
>
> Le 11/01/2022 à 08:10, Jacques Le Roux a écrit :
> > Hi,
> >
> > Should we don't remove Jira archived versions and, as explained here*,
> "remove references to the version[s] to be deleted."
> >
> > Take this as an example: https://s.apache.org/qttp7 (OFBIZ-12479 is
> apart)
> >
> > *
> https://confluence.atlassian.com/adminjiraserver/managing-versions-938847201.html#Managingversions-Deleteaversion
> >
> > PS: maybe only versions referenced, or?
> >
> > Jacques
> >
>

Re: [VOTE] [RESULT] Apache OFBiz 17.12.09

[Pierre Smits]

Hi Jacopo,

Doing an announcement would bring the opportunity to increase the awareness
(as a reminder - again) that use of anything but the latest release is not
advised. And that existing users are invited/urged to migrate/upgrade.

Why forgo on such opportunities to communicate to the outside world?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Sat, Jan 15, 2022 at 1:24 PM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:

> The publish process is now complete.
> I am not going to send an announcement for this release since we are
> publishing it just to have it in our archives for the few that may
> want to use it after our announcement of the EOL of the 17.12. branch.
>
> Jacopo
>
> On Sat, Jan 15, 2022 at 1:04 PM Jacopo Cappellato
>  wrote:
> >
> > The vote is successful with 5 positive votes, all binding.
> >
> > I am going to publish the release.
> >
> > Jacopo
> >
> > On Mon, Jan 10, 2022 at 6:56 PM Jacopo Cappellato
> >  wrote:
> > >
> > > This is the vote thread to release a new bug fix release for the
> > > release17.12 branch. This new release, "Apache OFBiz 17.12.09"
> > > supersedes all the previous releases from the same branch and is
> > > probably the last release of the 17.12 series.
> > >
> > > The release files can be downloaded from here:
> > > https://dist.apache.org/repos/dist/dev/ofbiz/
> > >
> > > and are:
> > > * apache-ofbiz-17.12.09.zip
> > > * KEYS: text file with keys
> > > * apache-ofbiz-17.12.09.zip.asc: the detached signature file
> > > * apache-ofbiz-17.12.09.zip.sha512: checksum file
> > >
> > > Please download and test the zip file and its signatures (for
> > > instructions on testing the signatures see [*]).
> > >
> > > Vote:
> > >
> > > [ +1] release as Apache OFBiz 17.12.09
> > > [ -1] do not release
> > >
> > > For more details about this process please read [**].
> > > [*]
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz#ReleaseManagementGuideforOFBiz-Votingonarelease
> > > [**] http://www.apache.org/foundation/voting.html
>

Re: svn commit: r52095 - /release/ofbiz/README.html

[Pierre Smits]

Hi Jacopo,

Thank you for doing this.

Are you aware that the description of the following line (the addition) is
the same as the line beneath it?

+apache-ofbiz-*17.12.08.zip* - Released in January 2022. http://ofbiz.apache.org/release-notes-17.12.09.html;>Release
notes.



Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Sat, Jan 15, 2022 at 1:20 PM  wrote:

> Author: jacopoc
> Date: Sat Jan 15 12:20:44 2022
> New Revision: 52095
>
> Log:
> Update release history log with the release 17.12.09.
>
> Modified:
> release/ofbiz/README.html
>
> Modified: release/ofbiz/README.html
>
> ==
> --- release/ofbiz/README.html (original)
> +++ release/ofbiz/README.html Sat Jan 15 12:20:44 2022
> @@ -15,6 +15,7 @@ This series has been stabilized with bug
>  17.12 series (closed)
>  This series has been stabilized with bug fixes since December 2017.
>  
> +apache-ofbiz-17.12.08.zip - Released in January 2022.  target="external" href="
> http://ofbiz.apache.org/release-notes-17.12.09.html;>Release
> notes.
>  apache-ofbiz-17.12.08.zip - Released in August 2021.  target="external" href="
> http://ofbiz.apache.org/release-notes-17.12.08.html;>Release
> notes.
>  apache-ofbiz-17.12.07.zip - Released in April 2021.  target="external" href="
> http://ofbiz.apache.org/release-notes-17.12.07.html;>Release
> notes.
>  apache-ofbiz-17.12.06.zip - Released in March 2021.  target="external" href="
> http://ofbiz.apache.org/release-notes-17.12.06.html;>Release
> notes.
>
>
>

Re: [ofbiz-framework] branch release22.01 updated: Fixed: no functional change, right version (22.01) in gradle.yaml

[Pierre Smits]

Github documentation regarding actions/workflow indicates that it should
be.
How would I check? I don't have the privileges.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Thu, Jan 13, 2022 at 11:41 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 13/01/2022 à 10:58, Pierre Smits a écrit :
> > If the script is the same for every branch in maintenance, why not make
> the
> > script generic like:
> >
> > branches: *
> I'm unsure it's possible, did you check?
>
> Jacques
>
>

Re: [ofbiz-framework] branch release22.01 updated: Fixed: no functional change, right version (22.01) in gradle.yaml

[Pierre Smits]

Hi Jacques,

No worries. That is what collaborating in an open source project is about.

If the script is the same for every branch in maintenance, why not make the
script generic like:

branches: *


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Thu, Jan 13, 2022 at 10:46 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Oops, right, thanks Pierre,
>
> I keep doing this error from start, not sure why. Several pairs of eyes
> always prove better!
>
> Jacques
>
> Le 13/01/2022 à 10:24, Pierre Smits a écrit :
> > Hey Jacques,
> >
> > The change states:
> >
> > +branches: [ release20.01 ]
> >
> >
> > Should it not be:
> >
> > +branches: [ release22.01 ]
> >
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> > Proud contributor to the ASF since 2006
> >
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> >
> >
> > On Thu, Jan 13, 2022 at 10:14 AM  wrote:
> >
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> jleroux pushed a commit to branch release22.01
> >> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/release22.01 by this
> push:
> >>   new a114a20  Fixed: no functional change, right version (22.01) in
> >> gradle.yaml
> >> a114a20 is described below
> >>
> >> commit a114a20ba8e368e4db53295784ae631427a71ffd
> >> Author: Jacques Le Roux 
> >> AuthorDate: Thu Jan 13 10:14:05 2022 +0100
> >>
> >>  Fixed: no functional change, right version (22.01) in gradle.yaml
> >>
> >>  This will also allow to test the just updated BB config, nothing
> >> happened last
> >>  time no ideas why yet...
> >> ---
> >>   .github/workflows/gradle.yaml | 4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/.github/workflows/gradle.yaml
> b/.github/workflows/gradle.yaml
> >> index 18d5c18..0201056 100644
> >> --- a/.github/workflows/gradle.yaml
> >> +++ b/.github/workflows/gradle.yaml
> >> @@ -21,9 +21,9 @@ name: Java CI with Gradle
> >>
> >>   on:
> >> push:
> >> -branches: [ trunk ]
> >> +branches: [ release20.01 ]
> >> pull_request:
> >> -branches: [ trunk ]
> >> +branches: [ release20.01 ]
> >>
> >>   jobs:
> >> build:
> >>
>

Re: [ofbiz-framework] branch release22.01 updated: Fixed: no functional change, right version (22.01) in gradle.yaml

[Pierre Smits]

Hey Jacques,

The change states:

+branches: [ release20.01 ]


Should it not be:

+branches: [ release22.01 ]



Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Thu, Jan 13, 2022 at 10:14 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> jleroux pushed a commit to branch release22.01
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
>
> The following commit(s) were added to refs/heads/release22.01 by this push:
>  new a114a20  Fixed: no functional change, right version (22.01) in
> gradle.yaml
> a114a20 is described below
>
> commit a114a20ba8e368e4db53295784ae631427a71ffd
> Author: Jacques Le Roux 
> AuthorDate: Thu Jan 13 10:14:05 2022 +0100
>
> Fixed: no functional change, right version (22.01) in gradle.yaml
>
> This will also allow to test the just updated BB config, nothing
> happened last
> time no ideas why yet...
> ---
>  .github/workflows/gradle.yaml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/.github/workflows/gradle.yaml b/.github/workflows/gradle.yaml
> index 18d5c18..0201056 100644
> --- a/.github/workflows/gradle.yaml
> +++ b/.github/workflows/gradle.yaml
> @@ -21,9 +21,9 @@ name: Java CI with Gradle
>
>  on:
>push:
> -branches: [ trunk ]
> +branches: [ release20.01 ]
>pull_request:
> -branches: [ trunk ]
> +branches: [ release20.01 ]
>
>  jobs:
>build:
>

Re: [apache/ofbiz-framework] Implemented: getEnvironmentProperty to allow environment variable configuration (OFBIZ-9498) (PR #355)

[Pierre Smits]

Whahaha.

"It is not about the PR content". "It works as intended". "Let's not
implement it", because of potential future developments (sans commitment).
There is no 'hurrying' here to get OFBiz improved. That might have been so,
when an approach/discussion preceding the solution in the PR hadn't
happened, or when the code change had been committed to the codebase
without it.

This kind of continuation of bringing suggestions to wait for additional
stuff and/or bringing forward arguments for such, is definitely feeding
procrastination.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Jan 3, 2022 at 11:41 AM Michael Brohl 
wrote:

> You missed the point of the cited comment on GitHub.
>
> It is not about the PR contents but about a follow-up enhancement for
> centralized configuration.
>
> The contributors of the PR themselves (Gil/Marco) want to improve the
> PR. I see no reason why you are pushing them to merge a PR they want to
> improve first.
>
> It's a better approach to quality than to hurry with a "it works"
> attitude and has nothing to do with procrastination.
>
> Michael
>
>
> Am 03.01.22 um 09:44 schrieb Pierre Smits:
> > Hi All,
> > To start with: I wish a healthy and prosperous 2022 to all participating
> in
> > this thread.
> >
> > This works now! It has been brought forward as working as intended and
> does
> > not disrupt OFBiz functionality.
> >
> > While it is good to see that this PR triggers others to think about it
> and
> > suggest (potential) variants and/or extensions on the concept, we should
> > not have that delay making this available to the greater audience.
> >
> > We don't know what the future may bring regarding improvement following
> > this PR, those (suggested/promissed) variants and/or extensions. And
> > suggesting delaying or waiting on somebody else to pen those down
> (whenever
> > they may find the time/without any obligation vis-a-vis commitment) does
> > not help the project.
> >
> > Stop feeding procrastination.
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> > Proud contributor to the ASF since 2006
> >
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> >
> >
> > On Mon, Jan 3, 2022 at 9:06 AM Michael Brohl 
> > wrote:
> >
> >> Hi @gilPts <https://github.com/gilPts> ,
> >> we already have such a centralized configuration mechanism in production
> >> for several years now. Maybe we should share this and let him check if
> it
> >> fits the needs, why do the work again?
> >>
> >> —
> >> Reply to this email directly, view it on GitHub
> >> <
> https://github.com/apache/ofbiz-framework/pull/355#issuecomment-1003923835
> >,
> >> or unsubscribe
> >> <
> https://github.com/notifications/unsubscribe-auth/AA6ERMVJ3YE25A3NNOJLQ6TUUFKJBANCNFSM5IYBDP7Q
> >
> >> .
> >> Triage notifications on the go with GitHub Mobile for iOS
> >> <
> https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email=8=524675
> >
> >> or Android
> >> <
> https://play.google.com/store/apps/details?id=com.github.android=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
> >.
> >>
> >> You are receiving this because you were mentioned.Message ID:
> >> 
> >>
>

Re: [apache/ofbiz-framework] Implemented: getEnvironmentProperty to allow environment variable configuration (OFBIZ-9498) (PR #355)

[Pierre Smits]

Hi All,
To start with: I wish a healthy and prosperous 2022 to all participating in
this thread.

This works now! It has been brought forward as working as intended and does
not disrupt OFBiz functionality.

While it is good to see that this PR triggers others to think about it and
suggest (potential) variants and/or extensions on the concept, we should
not have that delay making this available to the greater audience.

We don't know what the future may bring regarding improvement following
this PR, those (suggested/promissed) variants and/or extensions. And
suggesting delaying or waiting on somebody else to pen those down (whenever
they may find the time/without any obligation vis-a-vis commitment) does
not help the project.

Stop feeding procrastination.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Jan 3, 2022 at 9:06 AM Michael Brohl 
wrote:

> Hi @gilPts <https://github.com/gilPts> ,
> we already have such a centralized configuration mechanism in production
> for several years now. Maybe we should share this and let him check if it
> fits the needs, why do the work again?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/ofbiz-framework/pull/355#issuecomment-1003923835>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AA6ERMVJ3YE25A3NNOJLQ6TUUFKJBANCNFSM5IYBDP7Q>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email=8=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
> You are receiving this because you were mentioned.Message ID:
> 
>

Re: [ofbiz-framework] branch trunk updated: Fixed: [SECURITY] CVE-2021-44832: Apache Log4j2 (OFBIZ-12475)

[Pierre Smits]

Hi Jacques,

Re: OFBiz R22, I would like to see PR355 implemented.
Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Fri, Dec 31, 2021 at 8:25 AM jler...@apache.org 
wrote:

> Hi Jacopo, All,
>
> Ready to release 18.12.05?
>
> Also it'd be good to ASAP freeze 22.01. Then I'll adapt BuildBot config
> and ask Infra to restart the demos. We will need to also trivially update
> README.adoc. I'll put that in the freeze part of the release plan page in
> wiki.
>
> TIA
>
> Happy holidays :)
>
> Jacques
>
> Le 29/12/2021 à 09:05, jler...@apache.org a écrit :
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > jleroux pushed a commit to branch trunk
> > in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> >
> >
> > The following commit(s) were added to refs/heads/trunk by this push:
> >   new a744965  Fixed: [SECURITY] CVE-2021-44832: Apache Log4j2
> (OFBIZ-12475)
> > a744965 is described below
> >
> > commit a7449655678460ecd84ce6c04f7cc90bb55d1ea5
> > Author: Jacques Le Roux 
> > AuthorDate: Wed Dec 29 08:51:55 2021 +0100
> >
> >  Fixed: [SECURITY] CVE-2021-44832: Apache Log4j2 (OFBIZ-12475)
> >
> >  See complete explanation at
> https://issues.apache.org/jira/browse/OFBIZ-12475
> > ---
> >   build.gradle | 14 +++---
> >   1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/build.gradle b/build.gradle
> > index 99206c3..0dc7486 100644
> > --- a/build.gradle
> > +++ b/build.gradle
> > @@ -217,8 +217,8 @@ dependencies {
> >   implementation
> 'org.apache.geronimo.components:geronimo-transaction:3.1.4'
> >   implementation
> 'org.apache.geronimo.specs:geronimo-jms_1.1_spec:1.1.1'
> >   implementation 'org.apache.httpcomponents:httpclient-cache:4.5.13'
> > -implementation 'org.apache.logging.log4j:log4j-api:2.17.0' // the
> API of log4j 2
> > -implementation 'org.apache.logging.log4j:log4j-core:2.17.0' //
> Somehow needed by Buildbot to compile OFBizDynamicThresholdFilter.java
> > +implementation 'org.apache.logging.log4j:log4j-api:2.17.1' // the
> API of log4j 2
> > +implementation 'org.apache.logging.log4j:log4j-core:2.17.1' //
> Somehow needed by Buildbot to compile OFBizDynamicThresholdFilter.java
> >   implementation 'org.apache.poi:poi:4.1.2' //
> poi-ooxml-schemas-5.0.0.pom'. Received status code 401 from server
> >   implementation 'org.apache.pdfbox:pdfbox:2.0.24'
> >   implementation 'org.apache.shiro:shiro-core:1.8.0'
> > @@ -256,11 +256,11 @@ dependencies {
> >   runtimeOnly 'org.apache.axis2:axis2-transport-local:1.7.9' //
> Above: SOAPEventHandler.java:42: error: package
> org.apache.axiom.om.impl.builder does not exist
> >   runtimeOnly 'org.apache.derby:derby:10.14.2.0'  // So far we did
> not update from 10.14.2.0 because of a compile issue. You may try w/ a
> newer version than 10.15.1.3
> >   runtimeOnly
> 'org.apache.geronimo.specs:geronimo-jaxrpc_1.1_spec:2.1'
> > -runtimeOnly 'org.apache.logging.log4j:log4j-1.2-api:2.17.0' // for
> external jars using the old log4j1.2: routes logging to log4j 2
> > -runtimeOnly 'org.apache.logging.log4j:log4j-jul:2.17.0' // for
> external jars using the java.util.logging: routes logging to log4j 2
> > -runtimeOnly 'org.apache.logging.log4j:log4j-slf4j-impl:2.17.0' //
> for external jars using slf4j: routes logging to log4j 2
> > -runtimeOnly 'org.apache.logging.log4j:log4j-web:2.17.0' //???
> > -runtimeOnly 'org.apache.logging.log4j:log4j-jcl:2.17.0' // need to
> constrain to version to avoid classpath conflict (ReflectionUtil)
> > +runtimeOnly 'org.apache.logging.log4j:log4j-1.2-api:2.17.1' // for
> external jars using the old log4j1.2: routes logging to log4j 2
> > +runtimeOnly 'org.apache.logging.log4j:log4j-jul:2.17.1' // for
> external jars using the java.util.logging: routes logging to log4j 2
> > +runtimeOnly 'org.apache.logging.log4j:log4j-slf4j-impl:2.17.1' //
> for external jars using slf4j: routes logging to log4j 2
> > +runtimeOnly 'org.apache.logging.log4j:log4j-web:2.17.1' //???
> > +runtimeOnly 'org.apache.logging.log4j:log4j-jcl:2.17.1' // need to
> constrain to version to avoid classpath conflict (ReflectionUtil)
> >   runtimeOnly
> 'org.codeartisans.thirdparties.swing:batik-all:1.8pre-r1084380'
> >
> >   // Dependencies defined by the plugins
>

Re: Add CHANGELOG.md file

[Pierre Smits]

Hi Jacques,

See the ticket referenced.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Tue, Dec 21, 2021 at 11:46 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi All,
>
> OK we have a CHANGELOG file now for 10 months, but nothing in it, so?
>
> Jacques
>
> Le 19/06/2020 à 12:19, Deepak Dixit a écrit :
> > Here is the link for task
> > https://issues.apache.org/jira/browse/OFBIZ-11839
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> > ofbiz.apache.org
> >
> >
> > On Thu, Jun 18, 2020 at 10:22 AM Swapnil M Mane
> > wrote:
> >
> >> +1
> >>
> >> - Best regards,
> >> Swapnil M Mane,
> >> ofbiz.apache.org
> >>
> >>
> >>
> >> On Wed, Jun 17, 2020 at 11:23 AM Deepak Dixit
> wrote:
> >>
> >>> Hi Dev,
> >>>
> >>> As we have already moved to git for the version control system, I
> propose
> >>> to add a changelog file to maintain the changelogs[1].
> >>> What is a changelog?
> >>>
> >>> A changelog is a file which contains a curated, chronologically ordered
> >>> list of notable changes for each version of a project.
> >>> Why keep a changelog?
> >>>
> >>> To make it easier for users and contributors to see precisely what
> >> notable
> >>> changes have been made between each release (or version) of the
> project.
> >>> Who needs a changelog?
> >>>
> >>> People do. Whether consumers or developers, the end users of software
> are
> >>> human beings who care about what's in the software. When the software
> >>> changes, people want to know why and how.
> >>>
> >>> We can have our own process to generate changelog, It may be either
> >> manual
> >>> entries, or some tool or using git log. We can discuss this
> >> independently.
> >>> https://keepachangelog.com/en/1.0.0/
> >>>
> >>> Thanks & Regards
> >>> --
> >>> Deepak Dixit
> >>> ofbiz.apache.org
> >>>

Re: lib/README file and .DS_Store in .gitignore

[Pierre Smits]

Hi Jacques,

IMO, 'applications/content/index/' can be removed from .gitignore, as
indexes should be under the 'runtime' folder. And, AFAICT, this
'applications/content/index/' isn't in use in current setup.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Thu, Dec 16, 2021 at 11:18 AM Michael Brohl 
wrote:

> Thanks Jacques!
>
> Michael
>
> Am 16.12.21 um 08:11 schrieb Jacques Le Roux:
> > Thanks Michael,
> >
> > I add a doubt, fixed
> >
> > Jacques
> >
> > Le 15/12/2021 à 20:43, Michael Brohl a écrit :
> >> Hi Jacques,
> >>
> >> thanks for bringing this up.
> >>
> >> The lib dir is a mechanism which allows users to use and load
> >> external libs which can not (or should not) be loaded from external
> >> repositories through the Gradle mechanism. It is used in build.gradle
> >> at the end of the dependencies section.
> >>
> >> We do not use this library path but others may be using it. It's a
> >> feature to extend OFBiz, does no harm and might be useful in some cases.
> >>
> >> I would propose to keep it and change the README inside the folder to
> >> point to Maven Central instead of jCenter.
> >>
> >> Yes, .DS_Store is Mac related (https://file.org/extension/ds_store)
> >> and should stay in .gitignore.
> >>
> >> Thanks
> >>
> >> Michael
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >> Am 15.12.21 um 17:36 schrieb Jacques Le Roux:
> >>> Hi All,
> >>>
> >>> The lib/README file contains deprecated information, like using
> >>> jcenter. I propose to get rid of the whole lib dir, except if I miss
> >>> something (I know .DS_Store is Apple-Mac related)?
> >>>
> >>> Jacques
> >>>
>

Re: lib/README file and .DS_Store in .gitignore

[Pierre Smits]

Hi Jacques,

Maybe you forgot, but ...
As a privileged contributor you have the discretionary power to remove
deprecated elements at any time from the files in the OFBiz repository
without a proposal for (and a discussion regarding) such removal.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Wed, Dec 15, 2021 at 5:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi All,
>
> The lib/README file contains deprecated information, like using jcenter. I
> propose to get rid of the whole lib dir, except if I miss something (I know
> .DS_Store is Apple-Mac related)?
>
> Jacques
>
>

Re: Migration from ci.a.o

[Pierre Smits]

HI Jacques,

If the project still sees XMLRPC functionality as an important OFBiz
service, we should work to get the CI to work with the tests. If the
project feels it has outlived its usefulness, we should work to get this
attic-ed.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Wed, Dec 15, 2021 at 5:24 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 14/12/2021 à 09:34, Jacques Le Roux a écrit :
> > I also wonder if we should not get rid of Apache XMLRPC knowing that
> it's no longer maintained:
> https://github.com/advisories/GHSA-6vwp-35w3-xph8
>
> A milder mitigation would be to simply comment out the 2 tests that fail
> on BuildBot. That would allow to keep XMLRPC for those interested. Like
> people working in a safe (ie no internet) environment. We also know that
> only post-auth attacks are possible.
>
> Opinions?
>
> Jacques
>
>

Re: [jira] [Commented] (OFBIZ-12449) [SECURITY] CVE-2021-44228: Apache Log4j2

[Pierre Smits]

Thanks Jaques, for being on top of this.
Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Tue, Dec 14, 2021 at 12:23 PM ASF subversion and git services (Jira) <
j...@apache.org> wrote:

>
> [
> https://issues.apache.org/jira/browse/OFBIZ-12449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459094#comment-17459094
> ]
>
> ASF subversion and git services commented on OFBIZ-12449:
> -
>
> Commit 479e222bbb7ecb81fdbf123cc6cfcc10f8dbac4a in ofbiz-framework's
> branch refs/heads/trunk from Jacques Le Roux
> [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=479e222 ]
>
> Improved: Apache Log4j2 (OFBIZ-12449)
>
> Updates log4j2 from 2.15.0 to 2.16.0 because of
> https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4
>
> It's not a security issue, I lazily use OFBIZ-12449 because it can improve
> security even if it's not necessary (dixit the announce)
>
>
> > [SECURITY] CVE-2021-44228: Apache Log4j2
> > 
> >
> > Key: OFBIZ-12449
> > URL: https://issues.apache.org/jira/browse/OFBIZ-12449
> > Project: OFBiz
> >  Issue Type: Sub-task
> >  Components: ALL COMPONENTS
> >Affects Versions: Trunk
> >Reporter: Jacques Le Roux
> >Assignee: Jacques Le Roux
> >Priority: Blocker
> > Fix For: 18.12.03
> >
> >
> > CVE-2021-44228: Apache Log4j2 JNDI features do not protect against
> attacker controlled LDAP and other JNDI related endpoints:
> > https://logging.apache.org/log4j/2.x/security.html
> > I'm not sure we are concerned, have no time to check, better safe than
> sorry...
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.1#820001)
>

Re: [ANNOUNCE] Apache OFBiz 18.12.03 released

[Pierre Smits]

Thanks Jacques, jacopo, all

Op ma 13 dec. 2021 21:22 schreef Jacopo Cappellato :

> The Apache OFBiz community is pleased to announce the new release "Apache
> OFBiz 18.12.03".
>
> Apache OFBiz® is an open source product for the automation of enterprise
> processes that includes framework components and business applications.
>
> http://ofbiz.apache.org/
>
> "Apache OFBiz 18.12.03" is the third release of the 18.12 series.
>
> For more details of the changes introduced with this new version
> please refer to http://ofbiz.apache.org/release-notes-18.12.03.html
>
> The release file can be downloaded following the instructions in the OFBiz
> download page:
>
> http://ofbiz.apache.org/download.html
>

Re: svn commit: r51352 - /release/ofbiz/README.html

[Pierre Smits]

Hi Jacopo, all,

Please do not forget to set the tag for the release in the git repo, and
inform our users.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Sun, Dec 12, 2021 at 7:46 PM  wrote:

> Author: jacopoc
> Date: Sun Dec 12 18:46:15 2021
> New Revision: 51352
>
> Log:
> Add to history log the new release 18.12.03
>
> Modified:
> release/ofbiz/README.html
>
> Modified: release/ofbiz/README.html
>
> ==
> --- release/ofbiz/README.html (original)
> +++ release/ofbiz/README.html Sun Dec 12 18:46:15 2021
> @@ -5,6 +5,7 @@ Note: old releases can be downloaded fro
>  18.12 series
>  This series has been stabilized with bug fixes since December 2018.
>  
> +apache-ofbiz-18.12.03.zip - Released in December 2021.  target="external" href="
> http://ofbiz.apache.org/release-notes-18.12.03.html;>Release
> notes.
>  apache-ofbiz-18.12.02.zip - Released in November 2021.  target="external" href="
> http://ofbiz.apache.org/release-notes-18.12.02.html;>Release
> notes.
>  apache-ofbiz-18.12.01.zip - Released in October 2021.  target="external" href="
> http://ofbiz.apache.org/release-notes-18.12.01.html;>Release
> notes.
>  
>
>
>

Re: Migration from ci.a.o

[Pierre Smits]

Jacques,
The failure is not due to the inclusion of the SystemProperty record in
seed data. It is due to a unexpected result when testInvoicePerShipment is
called with product="GZ-1000" and invoicePerShipment="N". And the same
happens in the same test with product="GZ-1000" and invoicePerShipment="Y".

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Dec 13, 2021 at 11:38 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks guys,
>
> With the help of Pierre, I found that it's due to
> https://github.com/apache/ofbiz-framework/pull/392/files
>
> Exactly to
>
>systemPropertyId="create.invoice.per.shipment" systemPropertyValue="Y"
>  description="create invoice per shipment. Options: = Y (Invoice per
> shipment), N (Invoice per order)"/>
>
> As the test name says testInvoicePerShipmentSetFalse
>
> The alternatives are:
>
>  1. Revert the PR (would allow to go on with INFRA-22279)
>  2. Just comment out the property above (would allow to go on with
> INFRA-22279)
>  3. Discuss if we want to use invoice per shipment by default (I guess it
> has been already done, if not several times)
>
> For now I decide to use 2 as it's the easiest way to go on with INFRA-22279
>
> Jacques
>
> Le 13/12/2021 à 10:47, Pierre Smits a écrit :
> > On my Mac the testInvoicePerShipmentSetFalse fails too, giving
> >
> > assert UtilValidate.isEmpty(invoices) | | false
> [['orderItemSeqId':'1',
> >> 'amount':15.99, 'quantity':1.00, 'statusId':'INVOICE_READY',
> >> 'orderId':'WSCO10020', 'itemIssuanceId':'10020', 'invoiceId':'CI1',
> >> 'invoiceItemSeqId':'1', 'shipmentReceiptId':null]]
> >>
> >> Assertion failed:
> >>
> >> assert UtilValidate.isEmpty(invoices)
> >> | |
> >> false [['orderItemSeqId':'1', 'amount':15.99, 'quantity':1.00,
> >> 'statusId':'INVOICE_READY', 'orderId':'WSCO10020',
> >> 'itemIssuanceId':'10020', 'invoiceId':'CI1', 'invoiceItemSeqId':'1',
> >> 'shipmentReceiptId':null]]
> >>
> >> at
> >>
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:415)
> >> at
> >>
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
> >> at
> >>
> org.apache.ofbiz.accounting.InvoicePerShipmentTests.testInvoicePerShipmentSetFalse(InvoicePerShipmentTests.groovy:154)
> >> at
> >>
> org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:90)
> >> at
> >>
> org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:153)
> >> at
> >>
> org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:77)
> >> at
> >>
> org.apache.ofbiz.base.start.StartupControlPanel.loadContainers(StartupControlPanel.java:146)
> >> at
> >>
> org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:70)
> >> at org.apache.ofbiz.base.start.Start.main(Start.java:89)
> >>
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> > Proud contributor to the ASF since 2006
> >
> > *Apache Directory<https://directory.apache.org>, PMC Member*
> >
> >
> > On Mon, Dec 13, 2021 at 10:28 AM Daniel Watford
> wrote:
> >
> >> Hi Jacques,
> >>
> >> After running ./gradlew testIntegration I can confirm that I see the
> test
> >> failure for testInvoicePerShipmentSetFalse.
> >>
> >> The error was visible by viewing
> >> $OFBIZ/runtime/logs/test-results/html/index.html in a browser and then
> >> navigating to the invoicestests class.
> >>
> >> On Mon, 13 Dec 2021 at 08:28, Jacques Le Roux <
> >> jacques.le.r...@les7arts.com>
> >> wrote:
> >>
> >>> Hi All,
> >>>
> >>> We have an issue withhttps://issues.apache.org/jira/browse/INFRA-22279
> >>> for tests on trunk and I need all your attention to help me fix it.
> >>>
> >>> The last successful trunk build on the old Buildbot (0.8) was <<*Oct.
> >>> 18*>>:
> >>> https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/
> >>>

Re: Migration from ci.a.o

[Pierre Smits]

On my Mac the testInvoicePerShipmentSetFalse fails too, giving

assert UtilValidate.isEmpty(invoices) | | false [['orderItemSeqId':'1',
> 'amount':15.99, 'quantity':1.00, 'statusId':'INVOICE_READY',
> 'orderId':'WSCO10020', 'itemIssuanceId':'10020', 'invoiceId':'CI1',
> 'invoiceItemSeqId':'1', 'shipmentReceiptId':null]]
>
> Assertion failed:
>
> assert UtilValidate.isEmpty(invoices)
> | |
> false [['orderItemSeqId':'1', 'amount':15.99, 'quantity':1.00,
> 'statusId':'INVOICE_READY', 'orderId':'WSCO10020',
> 'itemIssuanceId':'10020', 'invoiceId':'CI1', 'invoiceItemSeqId':'1',
> 'shipmentReceiptId':null]]
>
> at
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:415)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
> at
> org.apache.ofbiz.accounting.InvoicePerShipmentTests.testInvoicePerShipmentSetFalse(InvoicePerShipmentTests.groovy:154)
> at
> org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:90)
> at
> org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:153)
> at
> org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:77)
> at
> org.apache.ofbiz.base.start.StartupControlPanel.loadContainers(StartupControlPanel.java:146)
> at
> org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:70)
> at org.apache.ofbiz.base.start.Start.main(Start.java:89)
>

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Dec 13, 2021 at 10:28 AM Daniel Watford  wrote:

> Hi Jacques,
>
> After running ./gradlew testIntegration I can confirm that I see the test
> failure for testInvoicePerShipmentSetFalse.
>
> The error was visible by viewing
> $OFBIZ/runtime/logs/test-results/html/index.html in a browser and then
> navigating to the invoicestests class.
>
> On Mon, 13 Dec 2021 at 08:28, Jacques Le Roux <
> jacques.le.r...@les7arts.com>
> wrote:
>
> > Hi All,
> >
> > We have an issue with https://issues.apache.org/jira/browse/INFRA-22279
> > for tests on trunk and I need all your attention to help me fix it.
> >
> > The last successful trunk build on the old Buildbot (0.8) was <<*Oct.
> > 18*>>:
> > https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/
> >
> > Gavin has worked since on INFRA-22279 but got stuck because of (I
> > guess/hope only)  testInvoicePerShipmentSetFalse error on trunk.
> >
> > The last time I locally tried the test was 09/Nov/21 19:31
> > <
> >
> https://issues.apache.org/jira/browse/INFRA-22279?focusedCommentId=17441317=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17441317
> > >
> >
> > Yesterday, I have tried locally to run the tests 3 times (I'm on Windows
> > and there are sometimes quirks with tests) and 3 times got this sole
> > testInvoicePerShipmentSetFalse error.
> >
> > I have just checked the changes in accounting between 09/Nov/21 and now.
> I
> > did not find any evidences related to testInvoicePerShipmentSetFalse.
> >
> > I'll continue on this today, if you know better please help.
> >
> > First I'd appreciate if you can confirm you also cross the
> > testInvoicePerShipmentSetFalse error.
> >
> > TIA
> >
> > Jacques
> >
> >
> > Le 31/08/2021 à 14:08, Jacques Le Roux a écrit :
> > > Hi Gavin,
> > >
> > > Answering there
> > >
> > > Jacques
> > >
> > > Le 31/08/2021 à 11:32, Gavin McDonald a écrit :
> > >> I have created a Jira ticket where we can liaise on the migration
> which
> > I
> > >> would like to do ASAP.
> > >
>
>
>
> --
> Daniel Watford
>

Re: I'm working on an OFBiz helm chart for kubernetes

[Pierre Smits]

Hi Ioan,

Thanks for the reply.

I know this what you stated about Kubernetes and Docker images. But that is
not about the point I was asking about. My apologies if it didn't trigger
the right bells.

You talked about not having a clear way of loading data (I presume seed,
and maybe seed-ext) into the database of an OFBiz implementation (either in
a Docker environment, or a Kubernetes setup, on prem or off prem), and this
is what I am driving at:

   1. An OFBiz implementation with Apache Derby (whatever the
   environment) s not suitable for production. It is suitable for development.
   Every user, like me, doesn't use OFBiz in combination with Derby as
   production environment. It can be used for testing (SIT, UAT), but as you
   say, loading data into the database can be a problem with given means for
   Derby.;
   2. An OFBiz implementation with a production grade rdbms underneath is
   suitable for production. And it is suitable for testing. Most
   implementation will have the OFBiz implementation not on the same as the
   rdbms is.

In both cases, loading of data into the underlying rdbms is an issue
solvable. in the first case, we have scripts for that available. In the
second case, devops will have their ways to load data into the rdbms
directly (with sql scripts) before firing up (running OFBiz).

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Nov 29, 2021 at 1:39 AM Eugen Stan  wrote:

> Hello Alexis, Pierre,
>
> Alexis: if you have any questions or a specific interest, et me know on
> ofbiz slack channel, ask on email or open an issue on the chart repository.
>
> What are your plans for this?
> What are your interests?
> Are you currently running ofbiz in a dev/prod environment?
>
>
> Pierre, see my reply bellow:
>
> On 28.11.2021 11:15, Pierre Smits wrote:
> > Hi Ioan,
> >
> > Would you say that OFBiz in Kubernetes is more geared towards a
> production
> > environment, and OFBiz in Docker is more geared towards a development
> > environment?
> >
>
> kubernetes will use the same docker image IMO so depends on your setup
> and preference.
> Kubernetes is backed up by major cloud providers (you get hosting
> offerings) and not so much for docker clusters (beyond one server).
>
> This is of course debatable, and in the end left to the end user.
>
> Hope this helps,
> --
> Eugen Stan
>
> +40770 941 271  / https://www.netdava.com

Re: I'm working on an OFBiz helm chart for kubernetes

[Pierre Smits]

Hi Ioan,

Would you say that OFBiz in Kubernetes is more geared towards a production
environment, and OFBiz in Docker is more geared towards a development
environment?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Fri, Nov 26, 2021 at 8:05 PM Eugen Stan  wrote:

> I made some small updates to the chart and it's now
> I managed to publish the chart
>
> https://github.com/ieugen/charts
>
>
> Instalation details are on the ofbiz chart page:
> https://github.com/ieugen/charts/tree/main/charts/ofbiz
>
> Right now I can use the chart + custom valus to start ofbiz in
> kubernetes but I don't have a clear way to load data into it.
>
> I'll open another thread about this if I don't find something online first.
>
>
> I'll add more examples on how to use it since right now it might not be
> that obvious, but it works for me.
>
> Let me know if you need help with it or if you would like to be involved
> with this.
>
> --
> Eugen Stan
>
> +40770 941 271  / https://www.netdava.com

Re: IDEA plugin for OFBiz

[Pierre Smits]

Bonjour Gaitan, All,

First of all, I truly appreciate what you and your fellow team members at
Nereide have done for OFBiz developers (working at system integrators)
using IntelliJ. Like you, I presume that there are more OFBiz developers
(like a lot more) out there. There might even be quite a number using
IntelliJ as their goto IDE for creating, bug fixing and otherwise improving
OFBiz functions. But we don't know. Not about how many, or their level of
expertise.

You mentioned in your posting: intended for junior developers. IMO, if such
junior developers are working for a system integrator, then I would expect
that they be trained in the ways of the (senior developers of the) the
system integrator.
Also, while great effort has been spent by contributors on easing the life
of fellow contributors (and subsequently has trickled down into the ways of
working at (other) system integrators, the primary goal of this project is
to deliver something open source and useful to the users (businesses doing
ecommerce, manufacturing, warehousing, ordering, etc, in short a suite of
solutions around ERP processes, but also to their employees/workers with
varying permissions and roles). As our website states (see [1]) as what
OFBiz is: Apache OFBiz is a suite of business applications flexible enough
to be used across any industry

Again, I truly appreciate the effort you and your fellow team mates spent
on creating this plugin for developers using IntelliJ. And thank you
providing the link to where it can be found.
If I would ever change over to IntelliJ, I will surely remember this thread
and take it from the Nereide repository. And I will be happy advising new
contributors using IntelliJ to check out your plugin at the Nereide
repository in Github. IMO, having it there is a good thing. And having it
remain there till the end of days is something I can be happy with.

As you know, there are many IDEs out there in assisting an OFBiz developer.
Even the CLI can be used as the goto development tool (but that is beside
the point).This project should not move away from its primary focus, and
have contributors divert their attention to a plugin they may not care
about (because they don't use the IntelliJ). Should their be contributors
not working for Nereide, and being junior, and using IntelliJ together with
your plugin in their local development fork, I am confident that they can
bring accolades (and issues if they experience such, or improvement
suggestions) to you directly. They would know where to find you.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Fri, Nov 26, 2021 at 3:53 PM Gaetan  wrote:

> Hello OFBiz community,
>
> A few weeks ago, we made an announcement for an IDEA plugin for OFBiz.
> Though we didn't get any return on it, we'd like to insist on what this
> may bring to the community.
> It was designed to make OFBiz development easier, mostly for junior
> OFBiz devs.
> Seniors have their own habits for navigation towards service, entity, or
> file locations, but for a junior (such as me) it can be difficult at first.
> We made this as the tool I'd have liked to have when I began working
> with ofbiz.
>
> For example let's see this case (from `ContentManagmentServices.java`):
> ```java
> Map thisResult = dispatcher.runSync("createContent",
> contentContext);
>  if (ServiceUtil.isError(thisResult) ||
> ServiceUtil.isFailure(thisResult)) {
>  return
> ServiceUtil.returnError(UtilProperties.getMessage(resource,
> "ContentContentCreatingError", UtilMisc.toMap("serviceName",
> "persistContentAndAssoc"), locale), null, null, thisResult);
>  }
> ```
>
> For a junior, it might be unclear where to find the definition of the
> `createContent` service.
> The plugin allows you to simply `CTRL+Click` on the service name to
> navigate towards the definition.
> As a bonus, you can even `CTRL+Click`the name of the label and navigate
> to the property definition.
> The same goes for entity name (and we plan to add a quick doc popup for
> fields contained in the entity definition).
>
> We really think this has the potential to soften the framework's first
> impression of complexity that some people might feel.
> Knowing that a tool exists to help you build with OFBiz could help a lot.
>
> The idea is to get feedback of the interest for the community and to
> eventually contribute it into Apache OFBiz repository.
>
> Is there a place to find OFBiz related tools, or should we let it in
> Github as it is (https://github.com/Nereide-lab/idea-ofbiz-plugin)?
>
> Gaetan,
> OFBiz junior dev and enthusiast.
>
>

Re: [ANNOUNCE] Apache OFBiz 18.12.02 released

[Pierre Smits]

Hi Jacopo, All,

Thank you Jacopo.
It is a pity though that so shortly after the release of 18.12.01,
potential adopters will have a hard time finding what is in the total
package (improvements and bugfixes) since the start of releasing from the
18 branch.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Wed, Nov 24, 2021 at 11:50 AM Jacopo Cappellato 
wrote:

> The Apache OFBiz community is pleased to announce the new release "Apache
> OFBiz 18.12.02".
>
> Apache OFBiz® is an open source product for the automation of enterprise
> processes that includes framework components and business applications.
>
> http://ofbiz.apache.org/
>
> "Apache OFBiz 18.12.02" is the second release of the 18.12 series.
>
> For more details of the changes introduced with this new version
> please refer to http://ofbiz.apache.org/release-notes-18.12.02.html
>
> The release file can be downloaded following the instructions in the OFBiz
> download page:
>
> http://ofbiz.apache.org/download.html
>

Re: Freezing page in wiki?

[Pierre Smits]

Hi Jacopo, All,

Regarding point 6 in the updated page:
Would it not be a bit more convenient to create the release in Github
(based on the tag registered there for the release), as it would minimise
the risk of getting the wrong commit (version) for the zip to be generated?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Wed, Nov 24, 2021 at 10:52 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Jacopo,
>
> I'm putting the sentence there
>
> Jacques
>
> Le 24/11/2021 à 10:16, Jacopo Cappellato a écrit :
> > Hi Jacques,
> >
> > I have simply added a new paragraph at the bottom of the same page. It is
> > just a draft at this point but it should be good enough for now.
> >
> > Regards,
> >
> > Jacopo
> >
> >
> > On Tue, Nov 23, 2021 at 5:20 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Le 23/11/2021 à 17:05, Jacopo Cappellato a écrit :
> >>> Hi Jacques,
> >>>
> >>> On Tue, Nov 23, 2021 at 11:50 AM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>>> [...]
> >>>> Now I wonder where we should put that. Is there already a "How to
> >> Freeze"
> >>>> page in wiki?
> >>>>
> >>> I don't think we have such a page but it may be useful to have one.
> >>>
> >>> Jacopo
> >> Would you help creating one? I think you are the most qualified for
> that.
> >> I'd then just add the referred sentence :)
> >>
> >> Jacques
> >>
> >>
>

Re: [Conclusion] PartyRole usage in OFBiz

[Pierre Smits]

Hi Gil, All,

My apologies, but I have to object to this and for the following reasoning:
Objections to pursuing improvements to the entity definition (for
PartyRole) and subsequent addressing front-end issues (screens/forms,
requests, services etc) for that and other entities impacted were raised,
before https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole was
brought forward now 4 days ago.

That page defines the requirements for any and all EntityNameRole entity,
including PartyRole. And the validity of what was stated there has not been
contested up to now. Not even by those objecting to changes to PartyRole
(as it is included in the page) before the date/time of the page, and who
have remained silent since the availability of the page. I wanted to wait a
bit longer, so that every contributor (and other readers of the dev ml)
could have an informed opinion, before suggesting to claim consensus on
that. But alas...

So it stands to reason that getting current existing and failing
EntityNameRole entities (including the PartyRole entity) compliant is
implied and thus warranted. And thus tickets can stay as they are. Just the
order of improvements coming in is a concern that needs to be addressed
when they come in. And if such concerns can be addressed and eliminated
beforehand, so much the better.

Furthermore, one key aspect I would like to mention here. You mentioned in
your comment (see [1]): 'The current applications IMO are not meant to be
used as is'.
This is a very wrong point of view, as the many users/contributors in user
ml see differently. Otherwise they would not raise a thread about the
workings of OFBiz, about functionalities not being good enough. Or a ticket
in JIRA. They expect OFBiz as a business solutions to be usable as is, as a
minimal viable product (MVP). They don't expect it to be perfect when they
start using it. They'll trust that it will come along in due time.  And
they also don't expect it to have all the bells and whistles a particular
developer thinks necessary (while adding no value to the user). But, any
improvement brought forward to benefit all can/should go in. That is what
they expect.
And integrators downstream can take that and enhance for their own audience
(current and future) as they see fit. It is not up to the integrators (as
you proclaimed in the same posting: 'It is our choices as Integrators to
decide') to decide what goes into OFBiz that works for all users, not just
their own clients. System integrators don't contribute to an project to the
ASF. Even if they would be able to do so, at the end the using company
decides).
We need to work on that perception of contributors with privileges, as it
seems that this mindset (Integrators decide) is dictates the direction of
this project.

[1] https://lists.apache.org/thread/n9z54kljr1tmjo340bpontlvttcsttxk

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges).
13 years already. What does time fly (when happy contributing towards
improving OFBiz for all users)

Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Fri, Nov 19, 2021 at 5:03 PM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

> Hello,
>
> I will try to summarize the ongoing thread, to produce a conclusion or
> potential plan. Sorry in advance, if I forgot some points.
>
> About the improvement of adding lifespan in PartyRole entity, the "Won't
> do"
> seems to get the consensus, since this improvement do not follow logical
> purpose (might for audit), and will introduce regressions and bugs risks if
> implemented.
>
> The discussion went to a new subjects, like using PartyRelationship for
> party
> selection screens.
> Opinion about removing PartyRole FK from EntityRole entities has been
> expressed.
> Those both topics can be lead into separate thread if needed, to let anyone
> envision it without being polluted by the previous discussion in the
> thread.
>
> If no one object I will close Jira about PartyRole lifespan.
>
> Thanks for your sharing, and Regards.
>
> Gil
>
>
>
>

Re: Freeze branch release21

[Pierre Smits]

Hi Nicolas, All,

Why rush now with a branch for 2021? Why not wait till short after the
start of 2022 and have a branch 22 similarly to what Michael suggested for
2020 in the referenced thread which seemed to have consensus among those
participating there and then?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Fri, Nov 19, 2021 at 4:44 PM Nicolas Malin 
wrote:

> Hello,
>
> As we previously shared [1], now that the 18.12 is released out as the
> current stable (thanks all for the work !), we can continue to go
> forward with creating the next branch release 21.
>
> I propose this plan :
>  * Create the branch release21.11 or release21.12 (it's a palindrome, so
> it's better!)
>  * Formalize it to support java 11 and Gradle 6.5
>  * Formalize that trunk support java 17
>
> Any others suggests or remarks ?
> Otherwise I will work on it the next week.
>
> Cheers,
> Nicolas
>
> [1] https://lists.apache.org/thread/2tbgmv8jmv5bk5y3g5hco0b3d92ss1tq
> --
> logoNrd <https://nereide.fr/>
> Nicolas Malin
> The apache way <http://theapacheway.com/> : *Charity* Apache’s mission
> is providing software for the public good.
> informat...@nereide.fr
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
> <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>
>

Fwd: OFBiz implementatie

[Pierre Smits]

Hi All,

FYI a feedback I had from a prospective integrator . Would not withhold it
from you. It is in Dutch, but I am confident that together with the AI of
Google Translate (and the likes) you should be able to get the gist.

If not, feel free to ask


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


-- Forwarded message -
Subject: Re: OFBiz implementatie
To: Smits, Pierre 


Goedemorgen Pierre,



Dank voor je mail en jij ook de beste wensen!



Om eerlijk te zijn hebben we besloten niet verder te investeren in Ofbiz.
Het belangrijkste punt waar we tegen aanliepen is gebrek aan documentatie
en community. Er is zeker wel een community, maar de grootte is beperkt. De
meeste errors die ik tegenkom en ga googlen geven geen (relevante)
zoekresultaten waardoor je zelf vaak lang aan het zoeken bent. De
documentatie is er wel, maar heel beperkt. Zowel voor de gebruiker als de
developer. Als ik tegen een vraagstuk van de klant oploop en ga zoeken dan
vind ik heel algemeen hoe je bijvoorbeeld een factuur aanmaakt, maar niet
exact wat het idee is achter payment preferences, payments, applyen van
payments etc.



Ik merk ook dat de klant het vaak heel omslachtig vindt. In deze zelfde
functionaliteit zie je bijvoorbeeld dat er aan een order een factuur zit en
aan de factuur een betaling. Deze betaling kan op ‘betaald’ staan terwijl
de factuur niet op betaald staat. Dan moet de klant dus handmatig aangeven
dat de factuur ook betaald is. Dit soort zaken heb ik uiteindelijk maar
opgelost door het via een cronjob recht te trekken, want de code was iets
te complex om dat aan te passen zonder mijzelf heel veel testwerk op de
hals te halen.



Ondertussen ken ik aardig de weg in de code waardoor het nu ook wel een
stuk sneller gaat. Vanuit andere (niet-ERP) systemen weet ik dat het nooit
wenselijk is om de core code aan te passen ivm de mogelijkheid tot updaten.
Dit wilde ik ook niet in Ofbiz doen, maar ik kwam er al snel achter dat je
hier niet aan ontkomt. Aan de mailinglist merk ik ook dat dit vaak
aangeraden wordt. Je kunt prima nieuwe, losstaande modules ontwikkelen. Je
kunt daarmee alleen niet functies aan andere modules aanpassen of
toevoegen. Op zich is dat natuurlijk gewoon een keuze, toen ik dit eenmaal
geaccepteerd had ging het ontwikkelen op zich prima.



Ik merk dat de shift van Java naar GroovyScript op zich wel fijn is. Dit
versnelt het ontwikkelen aanzienlijk doordat je niet steeds Ofbiz opnieuw
hoeft te starten. Het nadeel is nu alleen dat je soms aan het zoeken bent
binnen templates, service definities, groovyscripts en javacode voordat je
gevonden hebt wat je zocht. Dat is nu wellicht een transitie, maar is voor
een developer niet altijd handig.



Het klinkt nu heel negatief, maar dat is ook niet mijn bedoeling. Het
grootste pijnpunt zit vooral in de documentatie. Ik ben te vaak tegen
vragen van de klant aangelopen die ik zelf eigenlijk ook niet goed kon
beantwoorden. Of het bugs zijn of dat er een logische reden voor is weet ik
ook niet altijd. Nog een voorbeeld: als je een order aan het invoeren bent
kun je de prijs aanpassen. Als je vervolgens het aantal aanpast wordt de
prijs weer teruggezet naar de originele prijs. Is dat een bewuste keus of
een bug? Zo zijn er heel veel van die kleine dingen die soms wellicht via
documentatie af te vangen zijn. Had mij een hoop zoeken door de code en
frustraties bij de klant gescheeld :).



Als Ofbiz een grotere aantrekkingskracht moet krijgen zijn er een aantal
zaken waar de focus nu op moet liggen:



   - Documentatie
   - Webpos
   - Design
   - Koppelingen met bestaande webshops



De documentatie lijkt mij ondertussen duidelijk. De webpos werkt nog heel
buggy en niet in lijn met de order manager. Ik begrijp dat deze module ook
nog vrij nieuw is, dus dat is op zich logisch. Het design zie ik vooral als
een quick win. Wij hebben er zelf een beetje aan gesleuteld (obv het
default theme) en dit er uit gekregen:

[image: Afbeelding met schermafbeelding Automatisch gegenereerde
beschrijving]



Blijft een kwestie van smaak, maar ik denk dat dit al een stuk cleaner en
vooral moderner oogt. Als je het interessant vindt kan ik eens kijken voor
je of we dit makkelijk los kunnen trekken en toe kunnen voegen in het
project zodat anderen het ook kunnen gebruiken. Ik moet even checken of er
dan geen klant-specifieke zaken in zitten namelijk. Zo weet ik dat we
bepaalde items verborgen hebben die deze klant toch niet ging gebruiken om
het overzichtelijk te houden. Ik ben ook bang dat we de CSS overriden ipv
de originele CSS aanpassen, dus dat zouden we dan ook op moeten schonen.



Wat mijn laatste punt betreft, koppelen aan webshops, denk ik dat daar best
veel interesse kan liggen. Het is moeilijk om te concurreren aan andere
webshop platformen. Daar l

EntityNameRole (was re: PartyNameRole)

[Pierre Smits]

Hi Jacques, All,

My apologies. I should have pulled it out of the originating thread. Doing
so now.

See inline.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Tue, Nov 16, 2021 at 3:48 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pierre,
>
> You missed the relation with PartyRole that all have (but PartyRole of
> course). I believe this relation, or rather the PKs in it, is the crux of
> the
> problem, as David suggested long ago.
>

As the necessity to having a relation to PartyRole for other EntityNameRole
definitions is a topic of discussion in the other thread (as it was back
then), I chose to leave it out for now. As soon as a consensus has been
reached regarding that topic it can be included in the page.


>
> The rest sounds good to me. We need to understand is why 15(!) other
> EntityNameRoles  don't comply with rules 5 and 7.
> I hope it's only a miss and not something functional. It's maybe not a
> problem, and we could try to add them once we are sure that removing PKs in
> relation from other EntityNameRoles works.
>

I presume, that the contributor who contributed the entity definition
either:

   1. started from scratch (without knowing about another contributor's
   commits that are similar)
   2. took the PartyRole entity as inspiration, copy-pasted it and adjusted
   to his/her/them needs, without researching whether similar EntityNameRole
   definitions existed
   3. didn't see the need to include fromDate and thruDate

Or maybe all of the above, if that is possible.
Aspect #1 would explain why some don't comply with rule #2.



>
> Jacques
>
> Le 15/11/2021 à 18:48, Pierre Smits a écrit :
> > Hi Jacques, All,
> >
> > I have taken your summation, Jacques, and poured it into a page in
> > confluence (see [1]).
> >
> > Can we say that there is consensus regarding the definition?
> >
> > [1] https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> > Proud contributor to the ASF since 2006
> >
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> >
> >
>

Re: PartyRole usage in OFBiz

[Pierre Smits]

Hi Jacques, All,

I have taken your summation, Jacques, and poured it into a page in
confluence (see [1]).

Can we say that there is consensus regarding the definition?

[1] https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Nov 15, 2021 at 4:48 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Gil,
>
> I now get the ideas and I agree with them.
>
> Le 15/11/2021 à 15:37, gil a écrit :
> > I will try to explain better
> >
> > With OFBiz you could create minimalistic application where you could
> define roles to a party to make them appear in one dropdown for a specific
> > purpose.
> > What I wanted to show is that through pragmatism, basic usage of
> PartyRole can exist and be sufficient.
> >
> > But whereas a business need indicates that there is retirement of an
> actor from a particular role, for me, then context "EntityNameRole" fits
> for
> > this. Thus I agree with PartyRelationship usage.
> >
> > In partyMgr component, when managing party relationships and party role,
> since it is more like a technical component, I do not see how we can
> > improve the screens and avoid having technical error like partyRole FK
> constraint. And moreover, it is nice like this to me.
> >
> > For business oriented component, like HR, the choice of roles
> managements process should be made, and if I understand well that the goal
> of OFBIZ-5827.
> >
> > I hope it is clear
> >
> > Gil
> >
> >
> >
> > Le lun. 15 nov. 2021 à 1:25 pm, Jacques Le Roux <
> jacques.le.r...@les7arts.com> a écrit :
> >> Hi Gil,
> >>
> >> Inline...
> >>
> >> Le 15/11/2021 à 10:36, gil a écrit :
> >>> Hello,
> >>>
> >>> The current applications IMO are not meant to be used as it, but are
> presenting existing features.
> >>> So there are many design flaws that exists in the current states of
> the application (leads to fk constraint error messages when deleting
> partyRole
> >>>  or creating partyRel).
> >>>
> >>> The example of having only a partyRole defined  for an actor to be
> selected can be *sufficient* in one implementation
> >>
> >> Sorry, I'm not sure what that means, could you explain a bit more? TIA
> >>
> >>
> >>> Having the need to expire role association implies, for me,  to have
> it associated within a context (WorkEffort, PartyRel, etc.) which
> OFBIZ-5827
> >>> is  one possibility.
> >>
> >> That makes sense and would prevent to remove PKs to PartyRole from
> EntityNameRole relations. But do we really need that? Should we not rather
> >> concentrate on PartyRelationShip. For instance we can't assign a role
> to a party with a relation to an organisation (for OFBIz implementation
> where
> >> there is several organisations). PartyRelationShip allows that.
> >>
> >>
> >>> It is our choices as Integrators to decide and customize application
> to use `ensurePartRole` when it is needed, or to lookup for the good
> >>> configured  party the way it is the best for our case.
> >>
> >> Sure, but what do you mean by that? To not remove things in model,
> services, UI, etc?
> >>
> >>
> >>>
> >>> In other word, Jacques I second your proposal, that seems the
> consensus we could agree on.
> >>
> >> Thanks, but it's a bit confuse to me, detailing your proposition would
> help.
> >>
> >> TIA
> >>
> >> Jacques
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Gil
> >>>
> >>> Le lun. 15 nov. 2021 à 8:04 am, Jacques Le Roux <
> jacques.le.r...@les7arts.com <mailto:jacques.le.r...@les7arts.com>> a
> écrit :
> >>>> Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :
> >>>>> Jacopo made an interesting comment at: <<https://s.apache.org/6s8lr>>
> that:
> >>>>>
> >>>>>< facilitated by one approach and made more difficult by the other, to both
> ways of
> >>>>>interpreting PartyRole records.
> >>>>>The current approach, implemented in many ootb applications, as
> Michael Brohl has pointed out, is to interpret the PartyRole records as all

Re: PartyRole usage in OFBiz

[Pierre Smits]

Hi Jacques, All,

You asked earlier in this thread what I meant with 'erroneous record going
into the PartyRole table'. My apologies for not addressing this earlier.

What I meant with that is this: any record that goes into the PartyRole
table (or any other table) that either intentionally or unintentionally can
be defined in any OFBiz component due to 'features' in that component while
at the same time going against policies and procedures of the OFBiz-using
organisation.

Does that mean that there is something wrong with the ensurePartyRole
request and underying service (when talking about PartyRole)? No. the
request takes the parameters as defined by the underlying service, and the
service applies those parameters in line with the entity definition.

As for your proposal to circumvent current issues by having the community
to prefer the service(s) under the createPartyRelationshipAndRoles request
over any other solution is in essence the combination of invoking the
ensurePartyRole service and the createPartyRelationship service under a
request?

There is technically nothing wrong with  a) the services ensurePartyRole
and create PartyRelationship (invoked by a triggered request or call
service) or createPartyRelationshipAndRoles. Works as designed, any
developer will say. But there is a functional issue . Which is: who in what
capacity is permitted to invoke this service and given the specific OFBiz
application what are the - functional - limits to the field/value
combinations (for Party AND RoleType) that can be provided as required
input parameters to the service?

As for those claiming that the PartyRole definition lacks context in OFBiz
and therefore should not exist: this is a wrong presumption/conclusion. The
context of a PartyRole record is the relationship shared between 2 other
records: a Party record and a RoleType record.  Like any other new
Role record creates/shows the context shared between 3 other
entity records. As an example:
https://demo-trunk.ofbiz.apache.org/webtools/control/entity/find/ProductRole/DEMO-PRODUCT-1/DemoCustomer-1/PRODUCT_OWNER/2010-11-18%2014:50:01.259
shows the context shared between a Product record, a Party and a RoleType.

Functionally (and technically per current design), you can not have the
existence of a PartyRelationship record without the context of the Party
and the RoleType record (a PartyRole record) for both to and from

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Nov 15, 2021 at 1:26 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Gil,
>
> Inline...
>
> Le 15/11/2021 à 10:36, gil a écrit :
> > Hello,
> >
> > The current applications IMO are not meant to be used as it, but are
> presenting existing features.
> > So there are many design flaws that exists in the current states of the
> application (leads to fk constraint error messages when deleting partyRole
> > or creating partyRel).
> >
> > The example of having only a partyRole defined  for an actor to be
> selected can be *sufficient* in one implementation
>
> Sorry, I'm not sure what that means, could you explain a bit more? TIA
>
>
> > Having the need to expire role association implies, for me,  to have it
> associated within a context (WorkEffort, PartyRel, etc.) which OFBIZ-5827
> is
> > one possibility.
>
> That makes sense and would prevent to remove PKs to PartyRole from
> EntityNameRole relations. But do we really need that? Should we not rather
> concentrate on PartyRelationShip. For instance we can't assign a role to a
> party with a relation to an organisation (for OFBIz implementation where
> there is several organisations). PartyRelationShip allows that.
>
>
> > It is our choices as Integrators to decide and customize application to
> use `ensurePartRole` when it is needed, or to lookup for the good
> configured
> > party the way it is the best for our case.
>
> Sure, but what do you mean by that? To not remove things in model,
> services, UI, etc?
>
>
> >
> > In other word, Jacques I second your proposal, that seems the consensus
> we could agree on.
>
> Thanks, but it's a bit confuse to me, detailing your proposition would
> help.
>
> TIA
>
> Jacques
>
> >
> > Thanks,
> >
> > Gil
> >
> > Le lun. 15 nov. 2021 à 8:04 am, Jacques Le Roux <
> jacques.le.r...@les7arts.com> a écrit :
> >> Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :
> >>> Jacopo made an interesting comment at: <https://s.apache.org/6s8lr>
> that:
> >>>
> >>>< by one approach and made

Re: PartyRole usage in OFBiz

[Pierre Smits]

Hi Jacques, All,

Thank you for reminding us of ticket
https://issues.apache.org/jira/browse/OFBIZ-5827, another indicator of the
greater issue at hand. Having reread it today, I must conclude now that
this ticket raised in October 2014 deserves more explanation (especially
regarding edge cases).

Though I have tried to explain the bigger issue in various threads here
(and in tickets) through examples before this thread, I failed to succeed.
Does that mean that any of the related ticket is therefore null and void? I
don't think so, as the greater part of the related tickets pertain to a
specific use-case issue *and* are indicators of the greater issue.

IMO, before we can start working towards a solution and addressing
individual tickets in JIRA (or preferring one over another), we need
answers to this question:

Why should the community allow deviations from the general consensus
regarding Role entities (see [1], meaning having lifespan
fields) to exist when talking about BudgetRole, InvoiceRole,
SegmentGroupRole, SalesOpportunityRole, OrderRole, OrderItemRole,
AgreementRole, CommunicationEventRole, ValidContactMechRole, PartyRole,
FacilityGroupRole, ProductStoreGroupRole, ItemIssuanceRole,
ShipmentReceiptRole, TimesheetRole in its codebase? What are these
exceptional use-cases that make these Role entities deviating
from those under [1] so special that we need to have them in the codebase?
Why not let these deviations reside at party using OFBiz? They can extend
entity models to their particular needs, right?


If we can find those answers, then I believe we can address the use cases
regarding the screens/forms, etc. that a user of a single component can
work with per OOTB functionality of OFBiz (I am here not talking about the
user above all other users), and what the downstream records are that also
need to be generated (as part of the request, if any).

[1] Role entities adhering to the general consensus:
GlAccountRole, BillingAccountRole, ContentRole, DataResourceRole,
WebsiteRole, MarketingCampaignRole, QuoteRole,
RequirementRole,ProdCatalogRole, ProdCategoryRole, ProductRole,
ProductStoreRole, PicklistRole,

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Nov 15, 2021 at 8:06 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :
> > Jacopo made an interesting comment at: https://s.apache.org/6s8lr that:
> >
> >< by one approach and made more difficult by the other, to both ways of
> >interpreting PartyRole records.
> >The current approach, implemented in many ootb applications, as
> Michael Brohl has pointed out, is to interpret the PartyRole records as all
> the
> >roles the party actually plays.
> >The other approach, that is the one advocated by Pierre Smits, is to
> interpret the PartyRole records as the roles the party can play.>>
>
> Hi Jacopo, All,
>
> Thinking about it, is there not a contradiction between Michael's vision
> (actually also how it was also historically envisioned by the founders) and
> the fact that we are able to create/edit PartyRoles in party component?
>
> Hence the creation of OFBIZ-5980 "Have the ability to revoke (expire)
> roles of a party", OFBIZ-12370 "InvoiceRole: impossible combination of
> party and
> role selectable: leads to error" and all related issues,
>
> It seems to me that OFBIZ-5827 "Have party selection in screens based on
> relation(s) in stead of role" and all related issues fits more.
>
> Note that all is Pierre's work. That's the Gordian node I speak about. I
> think we have already almost decided how to cut it: OFBIZ-5827 way rather
> than OFBIZ-5980 one.
>
> So we should tackle OFBIZ-5827 and all related issues and close OFBIZ-5980
> and all related issue after carefully reviewing them
>
> Nobody objects?
>
> Jacques
>
>

Re: PartyRole usage in OFBiz

[Pierre Smits]

No. I linked to what you stated in [1]
https://github.com/apache/ofbiz-framework/pull/293


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Sun, Nov 14, 2021 at 6:42 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pierre,
>
> Inline...
>
> Le 13/11/2021 à 14:45, Pierre Smits a écrit :
> > Thank you, Gil, for referencing various pre-cursors to this discussion.
> >
> > As some may experience a case of TLDR given the lenghty threads in your
> > listing of references, I will try to clarify the issue within its
> context.
> >
> > *** Does a user experience one or more issues with the 'remove'
> > functionality regarding the PartyRole entity? ***
> > Yes, they do. The user experiences an error message when he/she/they
> > removes (meaning delete) an PartyRole in either the party component or in
> > webtools.
> > This should be undesirable from the project's perspective. Hence Jacques
> > remark in [1].
>
> As you somehow quoted me (I guess you speak about my 1st comment in
> OFBIZ-5959), I want to mention the end of that comment:
>
> <>
>
> And my next comment follow comments from other,notably from the late
> Adrian:
>
> < As says Nicolas, this endeavour seems risky. What would be the
> alternatives?>>
>
> I think it's enough to clarify my thoughts at that moment.
>
>
> > *** What is the root-cause of this issue? ***
> > This is two-fold:
> >
> > 1. functional: because in various Party and Role setting forms ( in
> > various applications other than party and webtools) there is no
> limit to
> > which party can be paired to what role. Which is then taken by the
> > ensureParty as parameters and persisted as a PartyRole record.
> > 2. technical: because of the PartyRole being used as a sql foreign
> key
> > constraint in various other entities, and
> >
> > *** Can the issue regarding the PartyRole be resolved technically? ***
> > It is not impossible, so yes. And preferable, as Jacopo points out,
> without
> > introducing new bugs.
> >
> > Addressing aspect #1, listed above, will reduce the number of erroneous
> > record going into the PartyRole table.
> > And evaluating each of the entities relating to aspect #2 whether there
> is
> > an absolute (as in set-in-stone) necessity for having the sql foreign key
> > constraint on PartyRole.
> >
> > When both are addressed, then the risk of introducing enhancements to the
> > PartyRole (and its associated forms, requests and service functions) is
> > minimised.
>
> With my recent experience ending by a revert, I tend to agree, we can try
> that. But something is unclear to me. What is an "erroneous record going
> into the PartyRole table", how to limit them? Before doing anything this
> needs to be defined.
>
> For your second proposition, I think we can remove all FKs going to
> PartyRole, using one-nofk in relations for instance, as proposed David.
> As Scott wondered (I think he never proposed that) an even more audacious
> endeavour would be to remove PartyRole altogether.
>
> Jacques
>
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Contributing to* Apache OFBiz<https://ofbiz.apache.org/>  since 2008
> (without
> > privileges)
> > Contributing to the ASF since 2006
> >
> > *Apache Directory<https://directory.apache.org>, PMC Member*
> >
> >
> > On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
> > jacopo.cappell...@gmail.com> wrote:
> >
> >> Thank you Gil.
> >>
> >> In my opinion the *Role data model and the way OFBiz leverages it and
> the
> >> *Relationship data model are not ideal (some of the issues have been
> >> mentioned in the various threads referenced by Gil) but I don't feel
> that
> >> this specific enhancement is relevant enough to justify the risk of
> >> introducing new bugs, issues and regressions.
> >>
> >> Jacopo
> >>
> >>
> >> On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
> >> gil.portensei...@nereide.fr> wrote:
> >>
> >>> Hello,
> >>>
> >>> I'm starting a new thread to discuss with the community about an
> >>> Improvement that has been submitted by Pierre Smits [1]
> >>> This topic has already been discussed in the past [2]

Re: PartyRole usage in OFBiz

[Pierre Smits]

[1] https://github.com/apache/ofbiz-framework/pull/293

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Sat, Nov 13, 2021 at 2:45 PM Pierre Smits  wrote:

> Thank you, Gil, for referencing various pre-cursors to this discussion.
>
> As some may experience a case of TLDR given the lenghty threads in your
> listing of references, I will try to clarify the issue within its context.
>
> *** Does a user experience one or more issues with the 'remove'
> functionality regarding the PartyRole entity? ***
> Yes, they do. The user experiences an error message when he/she/they
> removes (meaning delete) an PartyRole in either the party component or in
> webtools.
> This should be undesirable from the project's perspective. Hence Jacques
> remark in [1].
>
> *** What is the root-cause of this issue? ***
> This is two-fold:
>
>1. functional: because in various Party and Role setting forms ( in
>various applications other than party and webtools) there is no limit to
>which party can be paired to what role. Which is then taken by the
>ensureParty as parameters and persisted as a PartyRole record.
>2. technical: because of the PartyRole being used as a sql foreign key
>constraint in various other entities, and
>
> *** Can the issue regarding the PartyRole be resolved technically? ***
> It is not impossible, so yes. And preferable, as Jacopo points out,
> without introducing new bugs.
>
> Addressing aspect #1, listed above, will reduce the number of erroneous
> record going into the PartyRole table.
> And evaluating each of the entities relating to aspect #2 whether there is
> an absolute (as in set-in-stone) necessity for having the sql foreign key
> constraint on PartyRole.
>
> When both are addressed, then the risk of introducing enhancements to the
> PartyRole (and its associated forms, requests and service functions) is
> minimised.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Contributing to* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without
> privileges)
> Contributing to the ASF since 2006
>
> *Apache Directory <https://directory.apache.org>, PMC Member*
>
>
> On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
> jacopo.cappell...@gmail.com> wrote:
>
>> Thank you Gil.
>>
>> In my opinion the *Role data model and the way OFBiz leverages it and the
>> *Relationship data model are not ideal (some of the issues have been
>> mentioned in the various threads referenced by Gil) but I don't feel that
>> this specific enhancement is relevant enough to justify the risk of
>> introducing new bugs, issues and regressions.
>>
>> Jacopo
>>
>>
>> On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
>> gil.portensei...@nereide.fr> wrote:
>>
>> > Hello,
>> >
>> > I'm starting a new thread to discuss with the community about an
>> > Improvement that has been submitted by Pierre Smits [1]
>> > This topic has already been discussed in the past [2] and was conclude
>> by
>> > a lazy consensus not to implement PartyRole lifespan into OFBiz.
>> > Recently, this improvement was discussed again in Jira [3], and partly
>> > commited, before being reverted when big blocking side effect where
>> > discovered.
>> > A more detailed summary has been made by Jacques here [4].
>> > The enhancement is about adding fromDate and thruDate fields onto
>> > PartyRole entity, modifying its primary key (fromDate)
>> > The fact is that a such big subject need to be addressed with the
>> > community consensus, as it is not trivial.
>> > Please let us know you thoughts about this task and let's decide, if we
>> > need to organize or if we need to close pending Jira with reference to
>> this
>> > discussion ?
>> >
>> > Thanks,
>> > Gil
>> > [1] https://issues.apache.org/jira/browse/OFBIZ-5959
>> > [2]
>> >
>> https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
>> > [3] https://issues.apache.org/jira/browse/OFBIZ-5980 (
>> >
>> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
>> > )
>> > [4]
>> >
>> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
>> >
>>
>

Re: PartyRole usage in OFBiz

[Pierre Smits]

Thank you, Gil, for referencing various pre-cursors to this discussion.

As some may experience a case of TLDR given the lenghty threads in your
listing of references, I will try to clarify the issue within its context.

*** Does a user experience one or more issues with the 'remove'
functionality regarding the PartyRole entity? ***
Yes, they do. The user experiences an error message when he/she/they
removes (meaning delete) an PartyRole in either the party component or in
webtools.
This should be undesirable from the project's perspective. Hence Jacques
remark in [1].

*** What is the root-cause of this issue? ***
This is two-fold:

   1. functional: because in various Party and Role setting forms ( in
   various applications other than party and webtools) there is no limit to
   which party can be paired to what role. Which is then taken by the
   ensureParty as parameters and persisted as a PartyRole record.
   2. technical: because of the PartyRole being used as a sql foreign key
   constraint in various other entities, and

*** Can the issue regarding the PartyRole be resolved technically? ***
It is not impossible, so yes. And preferable, as Jacopo points out, without
introducing new bugs.

Addressing aspect #1, listed above, will reduce the number of erroneous
record going into the PartyRole table.
And evaluating each of the entities relating to aspect #2 whether there is
an absolute (as in set-in-stone) necessity for having the sql foreign key
constraint on PartyRole.

When both are addressed, then the risk of introducing enhancements to the
PartyRole (and its associated forms, requests and service functions) is
minimised.

Met vriendelijke groet,

Pierre Smits
*Contributing to* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without
privileges)
Contributing to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:

> Thank you Gil.
>
> In my opinion the *Role data model and the way OFBiz leverages it and the
> *Relationship data model are not ideal (some of the issues have been
> mentioned in the various threads referenced by Gil) but I don't feel that
> this specific enhancement is relevant enough to justify the risk of
> introducing new bugs, issues and regressions.
>
> Jacopo
>
>
> On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
> gil.portensei...@nereide.fr> wrote:
>
> > Hello,
> >
> > I'm starting a new thread to discuss with the community about an
> > Improvement that has been submitted by Pierre Smits [1]
> > This topic has already been discussed in the past [2] and was conclude by
> > a lazy consensus not to implement PartyRole lifespan into OFBiz.
> > Recently, this improvement was discussed again in Jira [3], and partly
> > commited, before being reverted when big blocking side effect where
> > discovered.
> > A more detailed summary has been made by Jacques here [4].
> > The enhancement is about adding fromDate and thruDate fields onto
> > PartyRole entity, modifying its primary key (fromDate)
> > The fact is that a such big subject need to be addressed with the
> > community consensus, as it is not trivial.
> > Please let us know you thoughts about this task and let's decide, if we
> > need to organize or if we need to close pending Jira with reference to
> this
> > discussion ?
> >
> > Thanks,
> > Gil
> > [1] https://issues.apache.org/jira/browse/OFBIZ-5959
> > [2]
> >
> https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
> > [3] https://issues.apache.org/jira/browse/OFBIZ-5980 (
> >
> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
> > )
> > [4]
> >
> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
> >
>

Re: OFBIZ-12329 and PR 320

[Pierre Smits]

Bonjou Jacques

If nothing is wrong with neither issue or PR, and it has your attention..

Then why don't you merge the PR?

Mvg
Pierre

Op za 6 nov. 2021 14:11 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:

> Hi Pierre,
>
> Nothing just needs some attention
>
> Jacques
>
> Le 06/11/2021 à 13:11, Pierre Smits a écrit :
> > Bonjour Jacques,
> >
> > What is wrong there?
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> > Proud contributor to the ASF since 2006
> >
> > *Apache Directory <https://directory.apache.org>, PMC Member*
>
>

OFBIZ-12329 and PR 320

[Pierre Smits]

Bonjour Jacques,

What is wrong there?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*

Re: Rework OFBiz Committers Roles and Responsibilities

[Pierre Smits]

Guten Tag Michael,

Great idea!

When reworking the page, please consider:

   - https://github.com/dotnet/runtime/issues/260
   -
   
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Tue, Nov 2, 2021 at 5:12 PM Jacques Le Roux 
wrote:

> Hi Michael,
>
> +1, will you or/and your team work on it?
>
> Jacques
>
> Le 02/11/2021 à 16:29, Michael Brohl a écrit :
> > Hi team,
> >
> > the Confluence page [1] contains a lot of references to the long
> outdated use of SVN. I think it's time to get rid of those references and
> put in
> > the Git / GitHub informations.
> >
> > What do you think?
> >
> > Best regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > [1]
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities
> >
> >
>

Demo

[Pierre Smits]

HI all,

Currently we have:

   - demo-trunk.ofbiz.a.o: sporting the latest commit (and refreshed every
   day) in trunk, intended for contributors who want to check what differs
   between the latest merged commit in trunk and the development
   (feature/bugfix) branch in their own environment;
   - dem-latest.ofbiz.a.o: sported the latest commit (and refreshed every
   day) of the latest release branch (currently at 17.12), intended for
   contributors who want to check what differs between the latest commit in
   the release branch and the development (feature/bugfix) branch in their own
   environment.

As both can change overnight, potential adopters can have a hard time
keeping track of the changes when evaluating OFBiz on its merits. Often
adopters won't go for what the latest is in a branch, and we don't
encourage them to do so but rather use a release.

Would it therefore not be prudent to show them a demo that is based on an
actual release?
We could use demo.ofbiz.a.o for that. Which only changes when a new release
has been made available.
Having that in play we also provide our contributors with an extra means to
check the development (feature/bugfix) branch in their own environment
against.

What are your thoughts?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*

Re: Latest release and tag in git

[Pierre Smits]

Grazie, Jacopo!

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Thu, Nov 4, 2021 at 3:14 PM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:

> Hi Pierre,
>
> Done, thanks!
>
> Jacopo
>
>
> On Thu, Nov 4, 2021 at 1:16 PM Pierre Smits 
> wrote:
>
> > Hi all,
> >
> > Can you please ensure that the latest release (18.12.01) is tagged in
> git?
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2006 (without privileges)
> >
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
>

Latest release and tag in git

[Pierre Smits]

Hi all,

Can you please ensure that the latest release (18.12.01) is tagged in git?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2006 (without privileges)

*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer

Re: ProductFacility on ecommerce listing product issue

[Pierre Smits]

Buona giornata Guilio,

Thank you for the detailed email. It is much appreciated.
I will read the ticket at a more convenient time, and will respond (if I
have anything to contribute) there.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Mon, Nov 1, 2021 at 4:08 PM Giulio Speri - MpStyle Srl <
giulio.sp...@mpstyle.it> wrote:

> Hello everyone,
>
> I hope you're doing well.
>
> I write here because I think I faced an issue in the ecommerce listing of
> products related to the ProductFacility entity and the filtering of out of
> stock products.
>
> Here's the context:
> - an ecommerce site where products are configured as a virtual-variant
> relationship.
> - a virtual product (parent) has color and size features associated as
> selectable, and its variants are all the combinations of colors and sizes.
> - in such a configuration InventoryItem records are registered for variant
> products (the actual sold products) and not for virtual products.
> - the product store is configured to not show out of stock products.
> - a record of ProductFacility is created for each product variant where its
> lastInventoryCount is automatically updated as soon as availability are
> imported/created (through PHYSICAL INVENTORY);
> - virtual products are associated to some ProductCategories;
>
> *Issue*:
> Products are not shown in category listing also if they have stock
> availability.
>
> *Issue details:*
> Listing of products is done through the screen "
> *CatalogScreens.xml#categorydetail*" and the *CategoryDetail.groovy* script
> is used to retrieve the list of products to show.
>
> In the groovy script the service responsible to get the product category
> members to show is *getProductCategoryAndLimitedMembers, *which checks and
> filters out of stock products (if ProductStore is configured to do so).
>
> Filtering out of stock products is done using
> *ProductWorker.java#filterOutOfStockProducts
> *method, that sums up all the lastInventoryCount (in all the facilities) of
> each category member and if sum is GT 0 the (virtual) product is kept and
> shown in listing.
>
> The lastInventoryCount field in the table ProductFacility is updated
> through the eeca service *setLastInventoryCount* on create/update on entity
> InventoryItemDetail.
> This service works only on the product on which a stock move is committed
> (in my case a specific product variant): it's (virtual) parent is never
> considered.
>
> That behaviour, in addition to the fact that filterOutOfStock method works
> on the category members that are the virtual parents, leads to products to
> not be shown in listing also if they have stock availability.
>
> *Possible solutions:*
> From my point of view there are two ways to fix this.
>
> *1)* add the handling of lastInventoryCount on virtual parents to the
> service setLastInventoryCount; the lastInventoryCount of the parent should
> be the sum of all its variant in the same facility, and each time a variant
> is modified, the related parent should be modified too.
>
> *2)* add the handling of virtual products in the ProductWorker.java#
> *filterOutOfStockProducts*: here when a virtual product category member is
> processed, all its variants should be retrieved and their
> lastInventoryCount added up through all facilities.
> Only if the sum of all the variants in all the facilities is GT 0, then we
> can keep and show the virtual product.
>
> *Considerations:*
> After a bit of research within the whole OFBiz project (R17.12.06) the
> lastInventoryCount field has quite limited direct usage (basically only for
> ecommerce scopes).
> I think solution 2) is better, because I think that the ProductFacility
> entity should not contain record for "virtual" products (products that
> physically won't be sold, since you will sell a variant of it; for the same
> reason virtual products should not have InventoryItem records associated).
>
> I think that solution 1) instead is not so clean and forced to adopt
> inventory item concepts also for virtual products, that in my opinion it
> does not make too much sense.
>
>
> Sorry for the long email, but I tried to retrieve as many details as
> possible and I would be very happy to know your thoughts about it.
>
> I opened an issue in Jira (OFBIZ-12359
> <https://issues.apache.org/jira/browse/OFBIZ-12359>) for this.
>
> Thanks in advance for your attention and help.
>
> Giulio
>
> --
> Giulio Speri
>
>
> *Mp Styl**e Srl*
> via Antonio Meucci, 37
> 41019 Limidi di Soliera (MO)
> T 059/684916
> M 347/0965506
>
> www.mpstyle.it
>

Re: Github PR actions'/events

[Pierre Smits]

Jacques,

Though not an issue/concern for you personally, can we have this feature
disabled?

These failures may give a false impression to contributors submitting PRs.
Which can potentially lead to them wasting time chasing a non-issue, or
worse: get annoyed and leave the project.

Best regards,

Pierre

Op vr 29 okt. 2021 11:24 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:

> Please see the request change, I can't edit the file
>
> Le 29/10/2021 à 11:15, Jacques Le Roux a écrit :
> > Hi Pierre,
> >
> > Ah indeed:
> https://github.com/apache/ofbiz-framework/runs/4037388858?check_suite_focus=true
> >
> > That's new and was reported by Mart Naum today at  OFBIZ-12351 "Builds
> fail due to unauthorized access to repo.spring.io/plugins-release"
> >
> > It appears only when you clean the Gradle cache (can't reproduce locally
> with a build after a clean). That's obviously a situation we get with GH
> > actions where all is new. I'm not sure yet it's the same situation with
> Buildbot. I'll check that pushing your PR.
> >
> > I'm not sure if this relates:
> https://markmail.org/message/skxini7ytetn23ub or if it's a completely new
> situation.
> >
> > HTH
> >
> > Jacques
> >
> > Le 28/10/2021 à 19:24, Pierre Smits a écrit :
> >
> >> Hi Jacques,
> >>
> >> Everything is going well?
> >>
> >> As an example: https://github.com/apache/ofbiz-framework/pull/323
> >>
> >> Met vriendelijke groet,
> >>
> >> Pierre Smits
> >> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> >> 2008 (without privileges)
> >>
> >> *Apache Directory <https://directory.apache.org>, PMC Member*
> >> Apache Incubator <https://incubator.apache.org>, committer
> >> Apache Steve <https://steve.apache.org>, committer
> >>
> >>
> >> On Thu, Oct 28, 2021 at 7:21 PM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com> wrote:
> >>
> >>> Pierre,
> >>>
> >>> Inline...
> >>>
> >>> Le 28/10/2021 à 13:41, Pierre Smits a écrit :
> >>>> When posting a PR to the GitHub repo, following events are triggered:
> >>>>
> >>>>  1. CodeCL / Analyze (java) (pull_request)
> >>>>  2. Java CI with Gradle / build (pull_request
> >>>>  3. CodeCL / Analyse (javascript) (pull_request)
> >>>>  4. etc.
> >>>>
> >>>> Of the actions/events listed, #1 and #2 fail.
> >>>>
> >>>> Is this something that is configurable?
> >>> Actually OFBiz (Java files) is too big for CodeCL. We need to pass less
> >>> data. I'm not yet sure how to handle that (not a priority to me, it
> does
> >>> not
> >>> prevent anything but itself):
> >>>
> >>>
> https://github.com/apache/ofbiz-framework/runs/3928683199?check_suite_focus=true
> >>>
> >>>
> https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning
> >>>
> >>>
> https://docs-dot-github-dotcom.gateway.web.tr/en/github-ae@latest/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#specifying-directories-to-scan
> >>>
> >>>
> >>> AFAIK we have no issue with your option 2. Have you an example?
> >>>
> >>> Jacques
> >>>
> >>>> It seems to me that this should not happen when:
> >>>> a. the change is only in an xml file
> >>>> b. the pull request has no conflicts with the base branche (and the
> base
> >>>> branch should always build, right?)
> >>>>
> >>>> Can this be looked into?
> >>>>
> >>>>
> >>>>
> >>>> Met vriendelijke groet,
> >>>>
> >>>> Pierre Smits
> >>>> *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
> >>> since
> >>>> 2008 (without privileges)
> >>>>
> >>>> *Apache Directory<https://directory.apache.org>, PMC Member*
> >>>> Apache Incubator<https://incubator.apache.org>, committer
> >>>> Apache Steve<https://steve.apache.org>, committer
> >
>

Re: Github PR actions'/events

[Pierre Smits]

Hi Jacques,

Everything is going well?

As an example: https://github.com/apache/ofbiz-framework/pull/323

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Thu, Oct 28, 2021 at 7:21 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Pierre,
>
> Inline...
>
> Le 28/10/2021 à 13:41, Pierre Smits a écrit :
> > When posting a PR to the GitHub repo, following events are triggered:
> >
> > 1. CodeCL / Analyze (java) (pull_request)
> > 2. Java CI with Gradle / build (pull_request
> > 3. CodeCL / Analyse (javascript) (pull_request)
> > 4. etc.
> >
> > Of the actions/events listed, #1 and #2 fail.
> >
> > Is this something that is configurable?
>
> Actually OFBiz (Java files) is too big for CodeCL. We need to pass less
> data. I'm not yet sure how to handle that (not a priority to me, it does
> not
> prevent anything but itself):
>
> https://github.com/apache/ofbiz-framework/runs/3928683199?check_suite_focus=true
>
> https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning
>
> https://docs-dot-github-dotcom.gateway.web.tr/en/github-ae@latest/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#specifying-directories-to-scan
>
> AFAIK we have no issue with your option 2. Have you an example?
>
> Jacques
>
> > It seems to me that this should not happen when:
> > a. the change is only in an xml file
> > b. the pull request has no conflicts with the base branche (and the base
> > branch should always build, right?)
> >
> > Can this be looked into?
> >
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Directory<https://directory.apache.org>, PMC Member*
> > Apache Incubator<https://incubator.apache.org>, committer
> > Apache Steve<https://steve.apache.org>, committer
>

Github PR actions'/events

[Pierre Smits]

When posting a PR to the GitHub repo, following events are triggered:

   1. CodeCL / Analyze (java) (pull_request)
   2. Java CI with Gradle / build (pull_request
   3. CodeCL / Analyse (javascript) (pull_request)
   4. etc.

Of the actions/events listed, #1 and #2 fail.

Is this something that is configurable?

It seems to me that this should not happen when:
a. the change is only in an xml file
b. the pull request has no conflicts with the base branche (and the base
branch should always build, right?)

Can this be looked into?



Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer

Re: Apache OFBiz I.d

[Pierre Smits]

Hi Katie,

My apologies for the late reaction. And congratulations. The next step, if
you want to be listed as a contributor to the OFBiz project is to add
yourself to following wiki page:
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors

Happy contributing.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Fri, Oct 15, 2021 at 6:38 PM Katie F.  wrote:

> Hello,
> I am contacting you in regards to my preferred I.d that I was told to send.
>
> I have sent and was confirmed through Secretary Matt Sicker that my ICLA
> has been filed.
> katiefoos.of...@apache.org
>
> Sincerely,
> Kathleen Foos
> 216-978-1941
> ofallskf...@gmail.com
>
> Sent from my iPhone.Kathleen Foos

Re: [DISCUSSION] Do we start the R18 publish process ?

[Pierre Smits]

I guess it is still ongoing.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Thu, Oct 21, 2021 at 3:32 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Heyho,
>
> What's the status here?
>
> Jacques
>
> Le 16/10/2021 à 09:17, Nicolas Malin a écrit :
> > Nice, thanks for your return.
> >
> > Can we close the OFBIZ-12171 ?
> >
> > I propose to wait the benjamin's return on the OFBIZ-12016 [1] on the
> > fix proposed by Jacques [2] and if we haven't any blocking issue, start
> > the publish process.
> >
> > Cheers,
> >
> > Nicolas
> >
> > [1] https://issues.apache.org/jira/browse/OFBIZ-12016
> >
> > [2]
> >
> https://issues.apache.org/jira/secure/attachment/13034949/13034949_OFBIZ-12016.patch
> >
> > On 15/10/2021 17:25, Michael Brohl wrote:
> >> Hi Nicolas,
> >>
> >> I have checked the jcenter problems together with Wiebke and Benjamin
> >> during the week.
> >>
> >> The both were not able to get to the build failure with deactivated
> >> access to jcenter, even with removing the Gradle caches, wrappers and
> >> new initialisation with init-gradle-wrapper.
> >>
> >> I just did another check, also removing everything and it is now also
> >> working without problems and a successful build. It might have been
> >> some mixture with the Gradle caches and different OFBiz
> >> versions/dependencies which lead to the previous error.
> >>
> >> So with 3 people on the ecomify side, we cannot reproduce the problem
> >> and I would say it is solved. It's just a bit confusing that now you
> >> have at least one remaining problem.
> >>
> >> But given the Gradle statement you mentioned, we should be good to go.
> >>
> >> Thanks for checking and best regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 15.10.21 um 14:51 schrieb Nicolas Malin:
> >>> Hello Michael,
> >>>
> >>> Gradle community create a dedicate page for this problem [1], If my
> >>> understanding is correct, we (massively you :) ) already done the job
> to
> >>> prepare the shutdown, and for the current potential issue that we have,
> >>> I read :
> >>>
> >>>> Impact to Gradle plugins
> >>>>   Behind the scenes, the Gradle Plugin Portal
> >>> <https://plugins.gradle.org/> uses JCenter to resolve dependencies of
> >>> plugins. We will be migrating the Plugin Portal away from JCenter
> before
> >>> the final shutdown. Builds will not need to make changes while the
> >>> Plugin Portal migrates away from JCenter.
> >>>> Resolving existing plugins
> >>>>   Existing plugins will continue to resolve in the same way they
> do
> >>> today. No changes should need to be made to your builds.
> >>>
> >>> Currently we have
> >>>
> >>>  > Could not resolve com.thoughtworks.xstream:xstream:1.4.17.
> >>>> Could not get resource
> >>> '
> https://plugins.gradle.org/m2/com/thoughtworks/xstream/xstream/1.4.17/xstream-1.4.17.pom
> '.
> >>>
> >>>   > Could not GET
> >>> '
> https://jcenter.bintray.com/com/thoughtworks/xstream/xstream/1.4.17/xstream-1.4.17.pom
> '.
> >>>
> >>>  > Connect to jcenter.bintray.com:443
> >>> [jcenter.bintray.com/127.0.0.1] failed: Connexion refusée (Connection
> >>> refused)
> >>>
> >>> The build call https://plugins.gradle.org/m2 so finally no problem for
> >>> us if we believe on gradle community.
> >>>
> >>> Do you confirm my analyze ?
> >>>
> >>> Nicolas
> >>>
> >>> [1] https://blog.gradle.org/jcenter-shutdown
> >>>
> >>> On 12/10/2021 10:24, Michael Brohl wrote:
> >>>> Hi Nicolas, all,
> >>>>
> >>>> I just checked the jcenter problem [1] and it still remains when you
> >>>> deactivate access to jcenter.bintray.com as shown in [2] and clean
> the
> >>>> gradle cache

OFbiz components in JIRA

[Pierre Smits]

Currently we have in JIRA following components (see [1]) registered for
rest-api:

   - plugin/rest
   - rest
   - rest-api

All which have tickets associated.

It seems to me that, given how we defined components in JIRA in the past
only the rest-api should be available as it lines up with the sub folder in
either the applications folder in the ofbiz-framework repo or with the sub
folder in the ofbiz-plugins repo.

Can we have this cleaned up?

[1]
https://issues.apache.org/jira/projects/OFBIZ?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer

Re: Reserved words

[Pierre Smits]

Thanks Michael for the fast reaction.

For sure, each database has its own set of reserved words, and there will
be commonalities across databases. Also the list of reserved words can
change over time with each new version of the database used.
And yet, hard coded the solution dictates a one-size-fits-all. Which
doesn't hold merit.
While many will opt for MySQL as the backend data store, some will make use
of the choice offered by the project (PostgreSQL, SQL Server, etc). And the
adopter should be able to customise the list of reserved words in
accordance with the requirements related to his choice, without having to
go through an implementation process of changes to the code.
IMO, it would be better if the list of reserved words were to be pulled
from the code and captures in a configuration file.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services


On Thu, Oct 7, 2021 at 5:40 PM Michael Brohl 
wrote:

> Correcting myself: only DATABASE is a reserved name in MySQL, the other
> two are keywords.
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 07.10.21 um 17:28 schrieb Michael Brohl:
> > Hi Pierre,
> >
> > those words are reserved names in different databases, please check
> > yourself:
> >
> https://stackoverflow.com/questions/8339396/all-reserved-words-of-every-dbms#8341855
> >
> > To me, the list seems pretty sophisticated for a variety of databases.
> > It is not meant to be used only for a specific database.
> >
> > For MySQL, all three words are reserved.
> >
> > Regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 07.10.21 um 11:06 schrieb Pierre Smits:
> >> Hi all,
> >>
> >> While working on a solution that involves bringing existing tables
> >> from a
> >> postgresql database into the entity group and model definitions, I
> >> noticed
> >> that some of the column definitions were not acceptable by OFBiz and
> >> thus
> >> entities would not get created in the underlying OFBiz database.
> >>
> >> I found in ModelEntityChecker.java has a list of reserved words,
> >> including
> >> words like:
> >>
> >> - password
> >> - database
> >> - type
> >>
> >> Many of the words listed there are not reserved according to [1]
> >>
> >> Does anyone know where these reserved words came from and when they got
> >> into the java file?
> >> It seems to me that a big brush was used to get to the list, and not
> >> much
> >> consideration was given to the context (variations in database
> >> applicability).
> >>
> >> What are your thoughts on correcting this?
> >>
> >>
> >> https://www.postgresql.org/docs/8.1/sql-keywords-appendix.html
> >>
> >> Best regards,
> >> Pierre Smits
> >>
> >> ORRTIZ.COM <http://www.orrtiz.com>
> >> OFBiz based solutions & services
> >>
>

Reserved words

[Pierre Smits]

Hi all,

While working on a solution that involves bringing existing tables from a
postgresql database into the entity group and model definitions, I noticed
that some of the column definitions were not acceptable by OFBiz and thus
entities would not get created in the underlying OFBiz database.

I found in ModelEntityChecker.java has a list of reserved words, including
words like:

   - password
   - database
   - type

Many of the words listed there are not reserved according to [1]

Does anyone know where these reserved words came from and when they got
into the java file?
It seems to me that a big brush was used to get to the list, and not much
consideration was given to the context (variations in database
applicability).

What are your thoughts on correcting this?


https://www.postgresql.org/docs/8.1/sql-keywords-appendix.html

Best regards,
Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

Re: OFBIZ-12046

[Pierre Smits]

Good morning,

Where was this reported?

Regards
Pierre

Op za 2 okt. 2021 14:04 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:

> Hi,
>
> As I mentioned there
>
> As Lalit reported it's not really a bug. But an annoying service
> transformation of updateProductPromo to entity-auto (I checked using
> R15.12). Note
> that createProductPromo is not affected.
> I'm not sure other update services using entity-auto are not affected...
>
> TIA to possibly check
>
> Jacques
>
>

Re: Clojure service engine proposal for inclusion

[Pierre Smits]

Hi Nicolas,

I wasn't aware of that constraint. Thanks for the insight.


Pierre

Op do 29 jul. 2021 17:40 schreef Nicolas Malin :

> Hello,
>
> @Eugeu
>
> Yeah nice, I added some suggest to the PR, and create the linked jira
> issue and we can push it on trunk
>
> @Pierre
>
> The service engine don't support an extension by plugins, you can't load
> a new engine without change the framework.
>
> In this case I prefer to load the minimal quantity of code to
> demonstrate an engine on the OFBiz framework instead of
>
> separate it in plugin and load it by apply a path or manually change the
> configuration.
>
> Nicolas
>
> On 29/07/2021 10:58, Pierre Smits wrote:
> > Hi Ioan,
> >
> > Would it not be better for the community to be able to implement this set
> > of functionalities by means of a downloadable plugin?
> >
> > It seems to me that - in a way - this levels up to plugins like the
> > indexing (lucene) or the REST plugins. Not every adopters would be keen
> to
> > have this by default OOTB.
> >
> > Best regards,
> > Pierre Smits
> >
> > On Wed, Jul 28, 2021 at 10:23 PM Eugen Stan 
> wrote:
> >
> >> Hello Nicolas,
> >>
> >> Thanks for the suggestions.
> >> I've made a PR for this:
> >> https://github.com/apache/ofbiz-framework/pull/317
> >>
> >> * has a service test
> >> * has a service example
> >>
> >>
> >> (defn echo-service
> >>"Echo back all the parameters"
> >>[dctx ctx]
> >>(doto (new java.util.LinkedHashMap)
> >>  (.putAll ctx)
> >>  (.put ModelService/RESPONSE_MESSAGE ModelService/RESPOND_SUCCESS)))
> >>
> >>
> >> On 07.07.2021 09:58, Nicolas Malin wrote:
> >>> Hello,
> >>>
> >>> Thanks for this detail email and your works.
> >>>
> >>> I'm not opposed to load closure in OFBiz code base for same reason that
> >>> you exposed.
> >>>
> >>> For success the inclusion, I suggest to rename the namespace to
> >>> org.apache.ofbiz, add test one framework/service/testdef and an example
> >>> "hello world" service.
> >>>
> >>> Thanks Eugen !
> >>>
> >>> Nicolas
> >> --
> >> Eugen Stan
> >> +40720 898 747 / netdava.com
> >>
>

Re: Clojure service engine proposal for inclusion

[Pierre Smits]

Hi Ioan,

Would it not be better for the community to be able to implement this set
of functionalities by means of a downloadable plugin?

It seems to me that - in a way - this levels up to plugins like the
indexing (lucene) or the REST plugins. Not every adopters would be keen to
have this by default OOTB.

Best regards,
Pierre Smits

On Wed, Jul 28, 2021 at 10:23 PM Eugen Stan  wrote:

> Hello Nicolas,
>
> Thanks for the suggestions.
> I've made a PR for this:
> https://github.com/apache/ofbiz-framework/pull/317
>
> * has a service test
> * has a service example
>
>
> (defn echo-service
>"Echo back all the parameters"
>[dctx ctx]
>(doto (new java.util.LinkedHashMap)
>  (.putAll ctx)
>  (.put ModelService/RESPONSE_MESSAGE ModelService/RESPOND_SUCCESS)))
>
>
> On 07.07.2021 09:58, Nicolas Malin wrote:
> > Hello,
> >
> > Thanks for this detail email and your works.
> >
> > I'm not opposed to load closure in OFBiz code base for same reason that
> > you exposed.
> >
> > For success the inclusion, I suggest to rename the namespace to
> > org.apache.ofbiz, add test one framework/service/testdef and an example
> > "hello world" service.
> >
> > Thanks Eugen !
> >
> > Nicolas
> --
> Eugen Stan
> +40720 898 747 / netdava.com
>

Re: SonarQube plugin for Gradle

[Pierre Smits]

Great!

Pierre Smits


On Sun, Jul 11, 2021 at 3:49 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> I have just created https://issues.apache.org/jira/browse/INFRA-22099 for
> that
>
> Jacques
>
> Le 27/06/2021 à 18:52, Jacques Le Roux a écrit :
> > Hi,
> >
> > I checked, the GH actions are in
> https://github.com/apache/ofbiz-framework/blob/trunk/.github/workflows/gradle.yaml
> >
> > Clearly SonarQube is not there. So it's indeed Infra thing. I'll check
> with them, after checking what it means to use it in Gradle...
> >
> > Jacques
> >
> > Le 01/06/2021 à 11:23, Jacques Le Roux a écrit :
> >> Hi Pierre,
> >>
> >> I'm not sure. I think it's an Infra thing, I'll check that.
> >>
> >> Jacques
> >>
> >> Le 01/06/2021 à 10:12, Pierre Smits a écrit :
> >>> Hi Jacques,
> >>>
> >>> Did we implement a GitHub action to invoke the SonarQube analysis?
> >>>
> >>> Best regards,
> >>> Pierre Smits
> >>>
> >>> On Mon, May 31, 2021 at 6:02 PM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Just stumbled upon this :
> >>>>
> >>>>  < situations
> >>>>
> >>>>* Your code is built with Gradle: use the SonarQube plugin for
> >>>> Gradle during the build>>
> >>>>
> >>>>
> >>>>
> https://github.com/SonarSource/sonarcloud-github-action#user-content-do-not-use-this-github-action-if-you-are-in-the-following-situations
> >>>>
> >>>> So I think we should remove it from GH and rather use it with Gradle.
> Not
> >>>> sure about all that though...
> >>>>
> >>>> Opinions ?
> >>>>
> >>>> Jacques
> >>>>
> >>>>
>

Re: I'm working on an OFBiz helm chart for kubernetes

[Pierre Smits]

Hi Ioan,

My apologies for the late reaction.

IMO we can forget about the Derby route for this. Derby is not production
grade, and often adopters/implementers already have their preferred RDBMS
for production in play or decided upon.  Configuration of such is the
entityengine.xml file, and deployment of such for the various
environments/instances like UAT or PROD can easily managed and deployed via
VCS.

Best regards,
Pierre Smits


On Sun, May 9, 2021 at 9:13 PM Eugen Stan  wrote:

>
>
> Hello,
>
> NOTE: I previously sent this email from an un-subscribed email address,
> please ignore that one.
>
> I'm working on a Helm chart for OFBiz
> https://github.com/ieugen/charts/tree/main/ofbiz .
>
> The goal is to have OFBiz running in Kubernetes.
>
> Right now it's a rough start: it starts OFBiz with Derby and that's
> about it.
>
> I'll keep pushing updates as soon as I have them.
>
> I'm interested in your feedback.
> If you plan on testing it and using it let me know.
> I do accept and encourage collaboration.
>
> If this is interesting I might push it upstream but it uses the binary
> build of OFBiz in Docker.
>
>
> I'm using docker images built from trunk on jdk-11.
> There are amd64 and arm64 (Raspberry PI4) images.
>
> Some issues that need solving are the many configuration files that
> OFBiz has.
>
> This details creates a lot of configuration when deploying in Docker /
> Kubernetes as they need to be mounted in a volume with many entries or
> multiple volumes.
>
> There are many potential solutions to this but it boils down to:
> * It would be nice to load max 1-2 or 3 configuration file with multiple
> sections instead of the currently many configs split over the code base.
> * It would be nice to support configuration (overwrite) via ENV vars for
> some things like DB connection.
>
>
> Regards.
> Eugen
>

Re: SonarQube plugin for Gradle

[Pierre Smits]

Hi Jacques,

Did we implement a GitHub action to invoke the SonarQube analysis?

Best regards,
Pierre Smits

On Mon, May 31, 2021 at 6:02 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> Just stumbled upon this :
>
> <
>   * Your code is built with Gradle: use the SonarQube plugin for
> Gradle during the build>>
>
>
> https://github.com/SonarSource/sonarcloud-github-action#user-content-do-not-use-this-github-action-if-you-are-in-the-following-situations
>
> So I think we should remove it from GH and rather use it with Gradle. Not
> sure about all that though...
>
> Opinions ?
>
> Jacques
>
>

Re: More Demo Data

[Pierre Smits]

Of course it is a good idea to keep working on our demo data set. It not
only helps adopters and contributors to understand how OFBiz works.

What is missing?

Mvg

Pierre

Op di 13 okt. 2020 12:43 schreef Emad Radwan :

> Hi There,
>
> Is there a way to get more data for tables that are not populated with
> data at all with the default seed. The reason for this is that some
> tables/columns purpose isn't clear while for sure useful and having some
> data will save asking for the reason for their existence.
>
> Regards,
>
> Emad.
>

Re: OFBiz Integrations

[Pierre Smits]

I second that.

Mvg

Pierre

Op wo 30 sep. 2020 11:38 schreef Pritam Kute :

> Thanks, Rishi for sharing this.
>
> We have already started work on moving all custom integrations as a
> separate plugin from the framework component. Alongside we will be working
> on checking if the integrations are updated and working as expected. I feel
> that this will be a good step to add a page on confluence which will become
> a single point of reference for all available integrations in the Apache
> OFBiz.
>
> Kind Regards,
> --
> Pritam Kute
>
>
> On Wed, Sep 30, 2020 at 3:44 AM Rishi Solanki 
> wrote:
>
> > Dear All,
> > In another thread on "Integration with facebook ecommerce platform" one
> > good suggestion came from user Andrew Williams to integrate OFBiz with
> > WooCommerce and WordPress. I would like to extend it to all required
> > integrations.
> >
> > Below are the areas as per my understanding where we would require
> > integrations which is in general expected.
> >
> > 1) Payment (Amazon, Apple, PayPal, First Data etc)
> > 2) Shipping (UPS, UPS, FEDEX, DHL etc.)
> > 3) Other Selling Portals and Channels (Amazon, WooCommerce, Wordpress,
> > Shopify etc.)
> > 4) Communication related integration. (Email, SMS, Chatbot, Whatapp etc)
> > 5) Supporting modules like Reports tool, Sales Force etc.
> > 6) Data Import Tool like JSON, Excel, CSV etc.
> >
> > Please add more in the list. Once will have all items listed, we will
> push
> > that list over the confluence page, and all supporting docs link. Later
> we
> > can pick one by one and mark them complete from there, in this way from
> the
> > open list everyone will have the opportunity to pick any and contribute.
> >
> > We can also think of creating open tickets from the approved list to work
> > on. Looking forward.
> >
> > Rishi Solanki
> > *CTO, Mindpath Technology*
> > Intelligent Solutions
> > cell: +91-98932-87847
> > http://www.mindpathtech.com
> > LinkedIn 
> >
>

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

[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
>
>

Re: [PROPOSAL] First Data Payment Gateway Integration

[Pierre Smits]

Hi Pritam,

I concur: we should have separate repositories for each of the existing 3rd
Party Solution Integrations (whether they be Fintech oriented, Logistics
oriented or other).

With the removal of the existing integrations from ofbiz-framework, we
reduce the footprint there (which is good), but putting them into
ofbiz-plugins doesn't make a difference for adopters. They will get more
than they may need.

IMO, you could/should start with putting the code regarding the 'First Data
Payment' integration plugin into a separate plugin.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Mon, Jun 29, 2020 at 11:18 AM Pritam Kute 
wrote:

> Hello Pierre and all,
>
> IMO, we should have a separate OFBiz repository in which we can push the
> third party integration code.
>
> Very soon we will start working on the ticket in which we are going to move
> 3rd party payment integrations from applications to plugins [OFBIZ-7415].
> Instead of moving them to plugins, I would recommend using
> a separate repository structure in which we can commit the 3rd party
> integration plugins like payment gateways, SMS gateways, shipping gateways,
> storefront integrations, etc.
>
> Let me know your thoughts. Pierre, please correct me if I am
> missing anything here.
>
> Kind Regards,
> --
> Pritam Kute
>
>
> On Sun, Jun 28, 2020 at 1:59 PM Pierre Smits 
> wrote:
>
> > Hi all,
> >
> > Under ticket OFBIZ-11837 we saw Pritam made great strides forward in
> > establishing a plugin for the 'First Data" Payment gateway in
> > https://github.com/pritambkute/ofbiz-plugins, and subsequently
> providing a
> > PullRequest (and pulling it back again).
> >
> > I applaud Pritam for the initiative to bring a new feature set to the
> > community of OFBiz adopters.
> >
> > But should we, as the OFBiz community, want any new 3rd *Solution
> > Integration brought forward by a committer (or any other contributor) to
> be
> > included in the ofbiz-plugins repository?
> >
> > WDYT??
> >
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Thu, Jun 25, 2020 at 7:48 AM Pritam Kute <
> pritam.k...@hotwaxsystems.com
> > >
> > wrote:
> >
> > > Hello Devs,
> > >
> > > While integrating the First Data payment gateway with Apache OFBiz, we
> > > found that the re-authorization request is supported by First Data only
> > if
> > > we send card security code (CVV) along with the card information. In
> > other
> > > payment gateways like Authorize.net, they allow the re-authorization
> > > transactions without CVV. So we want to know the thoughts from the dev
> > > community if we can add CVV as a mandatory/optional parameter while
> doing
> > > re-authorization.
> > >
> > > Also, we are going to implement token-based transaction capability with
> > > First Data in which we will not be storing the customer's card
> > information
> > > in OFBiz instead it will be stored at First Data servers and they
> return
> > us
> > > the token against that card data. That token can be used for further
> > > transactions of that customer. Here we may need to introduce couple of
> > new
> > > entities or need to extend the existing OFBiz entities and a
> configurable
> > > setting at the product store level if the user wants to use the
> > token-based
> > > transactions or regular card transactions.
> > >
> > > Here we suggest a design in which we can extend
> > ProductStorePaymentSetting
> > > entity to provide an option to user to configure the token-based
> > > transaction vs regular card-based transactions. Also, we can extend the
> > > CreditCard entity and code to store the token returned from the payment
> > > gateway for further transactions and displa

Re: [Propsoal] Is there any interest in supporting blockchain through Hyperledger Fabric

[Pierre Smits]

Hi Jeff,

I  grok your dream/intention. Think big, start small. The road is long and
starts with the first step.

Given the enormity of the integrations in OFBiz and thus the interwovenness
of data, having transactional data stored in a blockchain should - at the
moment - be complementing current functionality.

It seems to me that using an OFBiz plugin to get the Hyperledger Fabric
configured and started (including the 4 aspects mentioned earlier about the
use of correct party data) would be the easy part.
The next level of difficulty is having the data of an OFBiz transaction
(whatever the transaction) correctly appear in an initiated blockchain.

That is all on the sending end (e.g. company A using OFBiz + the
HyperLedger Fabric Integration plugin).

But then the other aspect of the transaction comes into play: company B
using OFBiz + the HyperLedger Fabric Integration plugin) being on the
receiving end. This company needs to:

   1. match the data in the blockchain about the sender (company A) with
   existing party* records, and
   2. recreate the OFBiz transaction in accordance with its viewpoint of
   the relationship and the transaction (inline with its OFBiz setup, consider
   difference in UoMs, Currencies, etc.)

With blockchain integration the following becomes even more true: it takes
2 to tango.

Like I said: the road is long, but starts with the first step(s).

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Sun, Jun 28, 2020 at 6:48 AM Jeff Prickett  wrote:

> Pierre,
> I have been reading some books. I had not thought of the case that
> hyperledger could allow you to view the transactions in a generic
> hyperledger blockchain. I was thinking more about creating a persistence
> layer that would store the data in OfBiz in a hyperledger blockchain
> instead of an SQL database, but I like the idea. I have a lot of research
> to do yet on how this could work, but hopefully we can someday have a
> hyperledger integrated into OfBiz.
>
> Jeff
>
>
> On Sat, Jun 27, 2020 at 4:22 AM Pierre Smits 
> wrote:
>
> > Hi Jeff,
> >
> > Thank you for picking up this baton and helping to move it further. I
> have
> > been pondering a while ago about this and would consider it a benefit for
> > the feature set of the OFBiz product if such a plugin would be available.
> > Unfortunately, I didn't have the time to move it further beyond pondering
> > about it, nor will I have such time soon.
> >
> > What I looked at back then, amongst others, was:
> >
> >-
> >
> >
> https://developer.ibm.com/technologies/blockchain/tutorials/hyperledger-fabric-java-sdk-for-tls-enabled-fabric-network/
> >- https://github.com/hyperledger/fabric-sdk-java
> >
> >
> >
> > Nevertheless, here were some of my thoughts regarding the subject to get
> it
> > started (for me):
> >
> >- Have a new plugin that would enable OFBiz to act as a front-end for
> >the HyperLedger (Fabric) implementation, throguh using publicly
> >available code, like libraries from mavencentral or by using  e.g.
> >https://github.com/hyperledger/fabric-sdk-java  (didn't investigate
> > what
> >to use further);
> >- Store configuration details of the plugin (for the HyperLedger
> Fabric
> >configuration) where possible as SystemProperty records for the
> > component
> >- Use data from the OFBiz entities (through service and entity
> engines)
> >to get the HyperLedger configured and running, for/to:
> >   - enroll the HyperLedger admin;
> >   - set the user context;
> >   - set the user enrollment (for the HyperLedger admin) in the user
> >   context
> >   - register and enroll appropriate OFBiz parties as the HyperLedger
> >   users
> >- Use the OFBiz plugin to invoke (etc.) the chaincode
> >
> > Maybe I am wrong in points, but that is as far as I got. I would be happy
> > though to explore this further.
> >
> > If you're going to take this further, I am looking forward to seeing your
> > plugin appear as a repository in Github and help you mature it.
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion

Re: [PROPOSAL] First Data Payment Gateway Integration

[Pierre Smits]

Hi all,

Under ticket OFBIZ-11837 we saw Pritam made great strides forward in
establishing a plugin for the 'First Data" Payment gateway in
https://github.com/pritambkute/ofbiz-plugins, and subsequently providing a
PullRequest (and pulling it back again).

I applaud Pritam for the initiative to bring a new feature set to the
community of OFBiz adopters.

But should we, as the OFBiz community, want any new 3rd *Solution
Integration brought forward by a committer (or any other contributor) to be
included in the ofbiz-plugins repository?

WDYT??



Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Thu, Jun 25, 2020 at 7:48 AM Pritam Kute 
wrote:

> Hello Devs,
>
> While integrating the First Data payment gateway with Apache OFBiz, we
> found that the re-authorization request is supported by First Data only if
> we send card security code (CVV) along with the card information. In other
> payment gateways like Authorize.net, they allow the re-authorization
> transactions without CVV. So we want to know the thoughts from the dev
> community if we can add CVV as a mandatory/optional parameter while doing
> re-authorization.
>
> Also, we are going to implement token-based transaction capability with
> First Data in which we will not be storing the customer's card information
> in OFBiz instead it will be stored at First Data servers and they return us
> the token against that card data. That token can be used for further
> transactions of that customer. Here we may need to introduce couple of new
> entities or need to extend the existing OFBiz entities and a configurable
> setting at the product store level if the user wants to use the token-based
> transactions or regular card transactions.
>
> Here we suggest a design in which we can extend ProductStorePaymentSetting
> entity to provide an option to user to configure the token-based
> transaction vs regular card-based transactions. Also, we can extend the
> CreditCard entity and code to store the token returned from the payment
> gateway for further transactions and display of saved card information to
> the customer (This we can fetch from payment gateways using the token
> against the card). So if the user opts to token-based transactions, the
> credit card data will not be stored in OFBiz in any case. This helps in
> marking the website a PCI DSS compliant. We will put the overall design on
> the ticket soon [1].
>
> Let us know your thoughts/ideas to implement this feature.
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-11841
>
> Kind Regards,
> --
> Pritam Kute
>
> On Thu, Jun 25, 2020 at 10:53 AM Pritam Kute <
> pritam.k...@hotwaxsystems.com>
> wrote:
>
> > Hello Devs,
> >
> > We have pushed the plugin for First Data payment gateway integration and
> > raised PR for the same at
> https://github.com/apache/ofbiz-plugins/pull/34
> >
> > We are going to improve it further and add token-based transactions to
> > support PCI DSS compliance. We are going to make it configurable for the
> > end-user. We have created a separate sub-ticket for these improvements
> > [OFBIZ-11841].
> >
> > Kind Regards,
> > --
> > Pritam Kute
> >
> >
> > On Fri, Jun 19, 2020 at 2:01 PM Devanshu Vyas  >
> > wrote:
> >
> >> Hello Pritam,
> >>
> >> A nice initiative to move the custom gateway code from framework to
> >> plugins.
> >> I would like to extend my help to you for this task.
> >>
> >> Thanks & Regards,
> >> Devanshu Vyas.
> >>
> >>
> >> On Fri, Jun 19, 2020 at 1:19 PM Pritam Kute <
> >> pritam.k...@hotwaxsystems.com>
> >> wrote:
> >>
> >> > Thanks, Nicolas, and all devs for putting your thoughts.
> >> >
> >> > We will push the contribution as a separate plugin. Also, we would
> like
> >> to
> >> > pick the task to move all custom gateways code from
> >> framework/accounting to
> >> > separate plugins for separate gateway implementations. This will
> provide
> >> > the facility to users to install the plugin of the payment gateway
> which
> >> > they want to use.
> >> >
> >> > We have created a new ticket in JIRA [OFBIZ-11837] for this
> >> contribution.
> >> > We will add

Re: [Propsoal] Is there any interest in supporting blockchain through Hyperledger Fabric

[Pierre Smits]

Hi Jeff,

Thank you for picking up this baton and helping to move it further. I have
been pondering a while ago about this and would consider it a benefit for
the feature set of the OFBiz product if such a plugin would be available.
Unfortunately, I didn't have the time to move it further beyond pondering
about it, nor will I have such time soon.

What I looked at back then, amongst others, was:

   -
   
https://developer.ibm.com/technologies/blockchain/tutorials/hyperledger-fabric-java-sdk-for-tls-enabled-fabric-network/
   - https://github.com/hyperledger/fabric-sdk-java



Nevertheless, here were some of my thoughts regarding the subject to get it
started (for me):

   - Have a new plugin that would enable OFBiz to act as a front-end for
   the HyperLedger (Fabric) implementation, throguh using publicly
   available code, like libraries from mavencentral or by using  e.g.
   https://github.com/hyperledger/fabric-sdk-java  (didn't investigate what
   to use further);
   - Store configuration details of the plugin (for the HyperLedger Fabric
   configuration) where possible as SystemProperty records for the component
   - Use data from the OFBiz entities (through service and entity engines)
   to get the HyperLedger configured and running, for/to:
  - enroll the HyperLedger admin;
  - set the user context;
  - set the user enrollment (for the HyperLedger admin) in the user
  context
  - register and enroll appropriate OFBiz parties as the HyperLedger
  users
   - Use the OFBiz plugin to invoke (etc.) the chaincode

Maybe I am wrong in points, but that is as far as I got. I would be happy
though to explore this further.

If you're going to take this further, I am looking forward to seeing your
plugin appear as a repository in Github and help you mature it.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Fri, Jun 26, 2020 at 12:22 PM Jeff Prickett  wrote:

> Hello Everyone
>
> The subject says it all. I have an interest in blockchain and thought that
> there could be integration of blockchain into Ofbiz.
>
> Would there be interest in creating a persistence layer for Apache Open For
> Business that is blockchain based on Hyperledger Fabric. Instead of pulling
> data from the SQL back end it would pull from the data from a  Hyperledger
> blockchain.
>
> I am asking as someone who would be interested in picking up the mantle to
> make it happen.
>
> Thanks in avance
> Jeff Prickett
>

Re: REST implementation

[Pierre Smits]

Hi Al,

Great to see you still present.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Wed, Jun 10, 2020 at 6:19 PM Al Byers  wrote:

> I am curious as to whether or not you have looked at what Moqui has done?
> I'm not up to speed on it enough to comment on how it stacks up against
> your list, but it seems logical to look at it since OFBiz and Moqui share a
> lot of DNA.
>
> Al Byers
>
> On Wed, Jun 10, 2020 at 9:43 AM Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com> wrote:
>
> > Hi All
> >
> > I am again bringing up this discussion on having a REST implementation
> for
> > OFBiz. I know we have had discussions before and I was looking at some of
> > the past discussions about this topic and seems we are not there quite
> yet
> > (correct me if I am wrong).
> >
> > I had developed a POC plug-in based on Jersey (that I am currently
> > enhancing) and recently started evaluating Apache Juneau as well. I
> wanted
> > to bring everybody on the same page as far as REST implementation is
> > concerned so I had initiated a discussion on slack today. I am listing
> down
> > a few points below that can be perceived as
> comment/question/understanding
> > based on my general understanding of the matter and today's slack
> > discussion.
> >
> >- Anything we start on can be part of a plug-in for the start and
> later
> >can become part of the framework (as separate plug-in) once it is
> >developed. A dedicated API application will allow it to be lightweight
> > in
> >terms of request processing. Should have separate auth mechanism
> > bypassing
> >ControlerServlet/ContextFiler/ControlFilter. I opine we do not need
> the
> > API
> >request to go through these three. Please correct me.
> >- We want to have mechanism to expose services (export=true) to be
> >available as a REST resources. Possibly extending existing service
> >definition by a new attribute verb="get|post". Also, if we also want
> to
> >expose out REST interface as an OpenApi specification, then it will
> >possibly help if we show in the spec an example of request for a
> > specific
> >service. In that case, the service definition can be expanded to allow
> > for
> >defining a JSON example (in a CDATA element)?
> >-  Any service that declares one of the verbs and not called with
> >declared verb will result in 405(Method not found) or 404(Resource
> does
> > not
> >exist) error.
> >   - GET /api/services/{serviceName}?inParams={JSON}
> >   - POST /api/services/{serviceName} (Request Body will contain in
> >   params as JSON)
> >   - GET /api/services : We list all services(export=true) along with
> >   HATEOS Links (self link describing where the specific service can
> be
> >   located)
> >- Do we want to have a similar resource for entities?. I think
> entities
> >should not be exposed directly as a REST resource even though they
> are a
> >good example of being a resource.
> >- We can take one day at a time approach here and just start with
> >exposing services as REST.
> >- Auth : I had provided JWT based auth for the plug-in I had
> developed.
> >This can further be expanded and allow for Digest auth as well? Can
> have
> >separate API endpoint to generate JWT token.
> >
> > Please share your thoughts on this and apologies for long email.
> >
> > Best Regards,
> > Girish
> >
>

Re: [DISCUSSION] Having OFBiz web apps listed as components in Jira

[Pierre Smits]

Done
Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Sun, Jun 7, 2020 at 10:08 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pierre,
>
> If you have done the research already, yes please.
>
> I mean should we consider not obvious webapps like ordermgr-js (which is a
> pretty weird one, see initial commit in history)?
>
> Jacques
>
> Le 06/06/2020 à 22:29, Pierre Smits a écrit :
> > Thanks Jacques. Shall I raise a ticket listing all appropriate web apps?
> >
> > Op za 6 jun. 2020 20:21 schreef Jacques Le Roux <
> > jacques.le.r...@les7arts.com>:
> >
> >> Hi Pierre,
> >>
> >> Sure I'll
> >>
> >> Jacques
> >>
> >> Le 06/06/2020 à 09:54, Pierre Smits a écrit :
> >>> I guess we can conclude that there are no objections to bring this into
> >> play.
> >>> Jacques, will you implement?
> >>>
> >>>
> >>> Met vriendelijke groet,
> >>>
> >>> Pierre Smits
> >>> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> >> 2008 (without privileges)
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>>
> >>> On Tue, Jun 2, 2020 at 8:51 AM Pierre Smits  >> <mailto:pierresm...@apache.org>> wrote:
> >>>  Jacques,
> >>>
> >>>  I don't foresee a problem there, if and when we follow the same
> >> principle as we do for framework subsets.
> >>>  Met vriendelijke groet,
> >>>
> >>>  Pierre Smits
> >>>  *Proud* *contributor** of* Apache OFBiz <
> https://ofbiz.apache.org/> since
> >> 2008 (without privileges)
> >>>  *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>>  *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>  Apache Incubator <https://incubator.apache.org>, committer
> >>>  Apache Steve <https://steve.apache.org>, committer
> >>>
> >>>
> >>>  On Tue, Jun 2, 2020 at 8:48 AM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com <mailto:jacques.le.r...@les7arts.com>>
> wrote:
> >>>  Hi Pierre,
> >>>
> >>>  That sounds like a good idea to me. We would though keep the
> >> existing components like product, else I don't know what would happen
> to the
> >>>  related issues.
> >>>
> >>>  Jacques
> >>>
> >>>  Le 02/06/2020 à 08:42, Pierre Smits a écrit :
> >>>  > Hi All,
> >>>      >
> >>>  > Multiple components in the applications and plugins stack
> have
> >> more than 1
> >>>  > web application (e.g. product having catalog and facility,
> >> marketing having
> >>>  > marketing and sfa).
> >>>  >
> >>>  > In order to better facilitate the community (and others)
> >> regarding insight
> >>>  > in issues (meaning categorisation/filtering), we should opt
> >> for having the
> >>>  > web apps listed in JIRA as component extensions, like:
> >>>  >
> >>>  > - product/catalog
> >>>  > - product/facility
> >>>  > - etc.
> >>>  >
> >>>  > WDYT?
> >>>  >
> >>>  > Met vriendelijke groet,
> >>>  >
> >>>  > Pierre Smits
> >>>  > *Proud* *contributor** of* Apache OFBiz <
> >> https://ofbiz.apache.org/> since
> >>>  > 2008 (without privileges)
> >>>  >
> >>>  > *Apache Trafodion <https://trafodion.apache.org>, Vice
> >> President*
> >>>  > *Apache Directory <https://directory.apache.org>, PMC
> Member*
> >>>  > Apache Incubator <https://incubator.apache.org>, committer
> >>>  > Apache Steve <https://steve.apache.org>, committer
> >>>
>

Re: [DISCUSSION] Having OFBiz web apps listed as components in Jira

[Pierre Smits]

Thanks Jacques. Shall I raise a ticket listing all appropriate web apps?

Op za 6 jun. 2020 20:21 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:

> Hi Pierre,
>
> Sure I'll
>
> Jacques
>
> Le 06/06/2020 à 09:54, Pierre Smits a écrit :
> > I guess we can conclude that there are no objections to bring this into
> play.
> >
> > Jacques, will you implement?
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
> 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Tue, Jun 2, 2020 at 8:51 AM Pierre Smits  <mailto:pierresm...@apache.org>> wrote:
> >
> >     Jacques,
> >
> > I don't foresee a problem there, if and when we follow the same
> principle as we do for framework subsets.
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> 
> > since
> 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Tue, Jun 2, 2020 at 8:48 AM Jacques Le Roux <
> jacques.le.r...@les7arts.com <mailto:jacques.le.r...@les7arts.com>> wrote:
> >
> > Hi Pierre,
> >
> > That sounds like a good idea to me. We would though keep the
> existing components like product, else I don't know what would happen to the
> > related issues.
> >
> > Jacques
> >
> > Le 02/06/2020 à 08:42, Pierre Smits a écrit :
> > > Hi All,
> > >
> > > Multiple components in the applications and plugins stack have
> more than 1
> > > web application (e.g. product having catalog and facility,
> marketing having
> > > marketing and sfa).
> > >
> > > In order to better facilitate the community (and others)
> regarding insight
> > > in issues (meaning categorisation/filtering), we should opt
> for having the
> > > web apps listed in JIRA as component extensions, like:
> > >
> > > - product/catalog
> > > - product/facility
> > > - etc.
> > >
> > > WDYT?
> > >
> > > Met vriendelijke groet,
> > >
> > > Pierre Smits
> > > *Proud* *contributor** of* Apache OFBiz <
> https://ofbiz.apache.org/> since
> > > 2008 (without privileges)
> > >
> > > *Apache Trafodion <https://trafodion.apache.org>, Vice
> President*
> > > *Apache Directory <https://directory.apache.org>, PMC Member*
> > > Apache Incubator <https://incubator.apache.org>, committer
> > > Apache Steve <https://steve.apache.org>, committer
> >
>

Re: Removal of Price information from Pick Sheet Report

[Pierre Smits]

We should not compound additional functions (even though these are
corrections) into apps that are clearly not intended for parties outside of
the domain (in this case warehouse managers to the order app).

Enhanced data in PR #117 shows that such is not needed. We should close the
ticket and create a new one to remove the functions.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Tue, Jun 2, 2020 at 3:10 PM Pierre Smits  wrote:

> A warehouse manager has ample functions available in the facility app to
> view pick sheets, correct?
> If not so, why are there screens like:
> [1]
> https://demo-stable.ofbiz.apache.org/facility/control/PicklistManage?facilityId=MyRetailStore
> [2]
> https://demo-stable.ofbiz.apache.org/facility/control/PicklistOptions?facilityId=MyRetailStore
> [3] https://demo-stable.ofbiz.apache.org/facility/control/VerifyPick
>
> to be used by the warehouse manager to see what sheet is available to
> process?
>
> Did we include the pick sheet in the order app to circumvent something? A
> warehouse manager should not have access to functions/widgets/etc. in the
> order component.
>
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
> 2008 (without privileges)
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Tue, Jun 2, 2020 at 2:42 PM Pawan Verma 
> wrote:
>
>> Hello Devs,
>>
>> I've discussed with Arun Patidar who added this support and as per the
>> conclusion, this report is for warehouse manager not for the picker.
>>
>> OFBIZ-11781 is a valid issue, we should correct the currency symbol.
>>
>> @Suraj Khurana  your proposition looks good, we
>> can change this confusing label like Print Order Sheet? Thoughts?
>> --
>> Thanks & Regards
>> Pawan Verma
>> Technical Consultant
>> *HotWax Systems*
>> *Enterprise open source experts*
>> http://www.hotwaxsystems.com
>>
>>
>> On Mon, Jun 1, 2020 at 10:09 PM Pierre Smits 
>> wrote:
>>
>> > With the enhancements provided through PR #117 (see [1]), I have
>> created a
>> > few demo party records for only warehousing roles to enhance the user
>> > experience for such parties (having only access to the facility app):
>> >
>> > See below:
>> >
>> > *For a warehouse manager*
>> > 
>> > > > statusId="PARTY_ENABLED"/>
>> > > > firstName="DemoEmployee" middleName="34"/>
>> > > > fromDate="2001-05-13 00:00:00.0"/>
>> > > > fromDate="2001-05-13 00:00:00.0"/>
>> > > > statusDate="2001-01-01 12:00:00.0"/>
>> > > > currentPassword="{SHA}47b56994cbc2b6d10aa1be30f70165adb305a41a"
>> > requirePasswordChange="N"/>
>> >
>> > *For a picker*
>> > 
>> > > > statusId="PARTY_ENABLED"/>
>> > > firstName="DemoEmployee"
>> > middleName="39"/>
>> > > > fromDate="2001-05-13 00:00:00.0"/>
>> > > > fromDate="2001-05-13 00:00:00.0"/>
>> > > > statusDate="2001-01-01 12:00:00.0"/>
>> > > > currentPassword="{SHA}47b56994cbc2b6d10aa1be30f70165adb305a41a"
>> > requirePasswordChange="N"/>
>> >
>> > *For a packer *
>> > 
>> > > > statusId="PARTY_ENABLED"/>
>> > > firstName="DemoEmployee"
>> > middleName="36"/>
>> > > > fromDate="2001-05-13 00:00:00.0"/>
>> > > > fromDate="2001-05-13 00:00:00.0"/>
>> > > > statusDate="2001-01-01 12:00:00.0"/>
>> > > > currentPassword="{SHA}47b56994cbc2b6d10aa1be30f70165adb305a41a"
>> > requirePasswordChange="N"/>
>> >
>> > [1] Improved: Update 

Re: Removal of Price information from Pick Sheet Report

[Pierre Smits]

A warehouse manager has ample functions available in the facility app to
view pick sheets, correct?
If not so, why are there screens like:
[1]
https://demo-stable.ofbiz.apache.org/facility/control/PicklistManage?facilityId=MyRetailStore
[2]
https://demo-stable.ofbiz.apache.org/facility/control/PicklistOptions?facilityId=MyRetailStore
[3] https://demo-stable.ofbiz.apache.org/facility/control/VerifyPick

to be used by the warehouse manager to see what sheet is available to
process?

Did we include the pick sheet in the order app to circumvent something? A
warehouse manager should not have access to functions/widgets/etc. in the
order component.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Tue, Jun 2, 2020 at 2:42 PM Pawan Verma 
wrote:

> Hello Devs,
>
> I've discussed with Arun Patidar who added this support and as per the
> conclusion, this report is for warehouse manager not for the picker.
>
> OFBIZ-11781 is a valid issue, we should correct the currency symbol.
>
> @Suraj Khurana  your proposition looks good, we
> can change this confusing label like Print Order Sheet? Thoughts?
> --
> Thanks & Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
> *Enterprise open source experts*
> http://www.hotwaxsystems.com
>
>
> On Mon, Jun 1, 2020 at 10:09 PM Pierre Smits 
> wrote:
>
> > With the enhancements provided through PR #117 (see [1]), I have created
> a
> > few demo party records for only warehousing roles to enhance the user
> > experience for such parties (having only access to the facility app):
> >
> > See below:
> >
> > *For a warehouse manager*
> > 
> >  > statusId="PARTY_ENABLED"/>
> >  > firstName="DemoEmployee" middleName="34"/>
> >  > fromDate="2001-05-13 00:00:00.0"/>
> >  > fromDate="2001-05-13 00:00:00.0"/>
> >  > statusDate="2001-01-01 12:00:00.0"/>
> >  > currentPassword="{SHA}47b56994cbc2b6d10aa1be30f70165adb305a41a"
> > requirePasswordChange="N"/>
> >
> > *For a picker*
> > 
> >  > statusId="PARTY_ENABLED"/>
> >  firstName="DemoEmployee"
> > middleName="39"/>
> >  > fromDate="2001-05-13 00:00:00.0"/>
> >  > fromDate="2001-05-13 00:00:00.0"/>
> >  > statusDate="2001-01-01 12:00:00.0"/>
> >  > currentPassword="{SHA}47b56994cbc2b6d10aa1be30f70165adb305a41a"
> > requirePasswordChange="N"/>
> >
> > *For a packer *
> > 
> >  > statusId="PARTY_ENABLED"/>
> >  firstName="DemoEmployee"
> > middleName="36"/>
> >  > fromDate="2001-05-13 00:00:00.0"/>
> >  > fromDate="2001-05-13 00:00:00.0"/>
> >  > statusDate="2001-01-01 12:00:00.0"/>
> >  > currentPassword="{SHA}47b56994cbc2b6d10aa1be30f70165adb305a41a"
> > requirePasswordChange="N"/>
> >
> > [1] Improved: Update Data Sets
> > <https://github.com/apache/ofbiz-framework/pull/117>
> >
> > With those enhancements in play in trunk, we can see what particular role
> > playing parties can and can't do.
> > <https://github.com/apache/ofbiz-framework/pull/117>
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Mon, Jun 1, 2020 at 6:20 PM Pierre Smits 
> > wrote:
> >
> > > So we're talking about the pdf generated for a picksheet in the order
> app
> > > (see [1])?
> > >
> > > A warehouse manager has functions available in the facility app to view
> > > what needs to be picked and assign that to a picker (see [2] and [3],
> > > correct?
> > > Then why would 

[DISCUSSION] Having OFBiz web apps listed as components in Jira

[Pierre Smits]

Hi All,

Multiple components in the applications and plugins stack have more than 1
web application (e.g. product having catalog and facility, marketing having
marketing and sfa).

In order to better facilitate the community (and others) regarding insight
in issues (meaning categorisation/filtering), we should opt for having the
web apps listed in JIRA as component extensions, like:

   - product/catalog
   - product/facility
   - etc.

WDYT?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer

Re: Removal of Price information from Pick Sheet Report

[Pierre Smits]

With the enhancements provided through PR #117 (see [1]), I have created a
few demo party records for only warehousing roles to enhance the user
experience for such parties (having only access to the facility app):

See below:

*For a warehouse manager*








*For a picker*








*For a packer *








[1] Improved: Update Data Sets
<https://github.com/apache/ofbiz-framework/pull/117>

With those enhancements in play in trunk, we can see what particular role
playing parties can and can't do.
<https://github.com/apache/ofbiz-framework/pull/117>
Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Mon, Jun 1, 2020 at 6:20 PM Pierre Smits  wrote:

> So we're talking about the pdf generated for a picksheet in the order app
> (see [1])?
>
> A warehouse manager has functions available in the facility app to view
> what needs to be picked and assign that to a picker (see [2] and [3],
> correct?
> Then why would he need access to the order app?
>
>
> [1]
> https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderview?orderId=DEMO10090
> [2]
> https://demo-trunk.ofbiz.apache.org/facility/control/PicklistOptions?facilityId=WebStoreWarehouse
> [3]
> https://demo-trunk.ofbiz.apache.org/facility/control/PicklistManage?facilityId=WebStoreWarehouse
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
> 2008 (without privileges)
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Mon, Jun 1, 2020 at 1:38 PM Suraj Khurana 
> wrote:
>
>> Hello Pawan,
>>
>> IMO, this label is confusing/misleading, this is order pick list or
>> basically order details for warehouse manager to keep as a copy with
>> himself. It will be always on each order level on the create picklist
>> page.
>> So that before creating a picklist he can check/select which orders to
>> pick.
>>
>> Actual pick sheet (used by picker) is something available under manage
>> picklist i.e. after picklist is created, which tells picker which item to
>> pick from which location, no further order details.
>>
>> Am I missing something?
>>
>> --
>> Best Regards,
>> Suraj Khurana
>> SENIOR TECHNICAL CONSULTANT
>> mobile: +91 9669750002
>> email: suraj.khur...@hotwax.co
>> *www.hotwax.co <http://www.hotwax.co/>*
>>
>>
>> On Mon, Jun 1, 2020 at 3:09 PM Pawan Verma > >
>> wrote:
>>
>> > Hello Devs,
>> >
>> > While working on OFBIZ-11781, issue of the distorted currency symbol.
>> > Pierre asked: Are we confident that prices and currency symbols are a
>> > requirement for a pick sheet?
>> >
>> > The important information for picket is Item, quantity, and location.
>> > Pickers really don't need the unit price, subtotal, or other
>> price-related
>> > information.
>> >
>> > Should we remove the unit price and subtotal information from a pick
>> sheet
>> > report? Or should we fix OFBIZ-11781 only?
>> >
>> > Your suggestions are appreciated!
>> > --
>> > Thanks & Regards
>> > Pawan Verma
>> > Technical Consultant
>> > *HotWax Systems*
>> > *Enterprise open source experts*
>> > http://www.hotwaxsystems.com
>> >
>>
>

Re: Removal of Price information from Pick Sheet Report

[Pierre Smits]

So we're talking about the pdf generated for a picksheet in the order app
(see [1])?

A warehouse manager has functions available in the facility app to view
what needs to be picked and assign that to a picker (see [2] and [3],
correct?
Then why would he need access to the order app?


[1]
https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderview?orderId=DEMO10090
[2]
https://demo-trunk.ofbiz.apache.org/facility/control/PicklistOptions?facilityId=WebStoreWarehouse
[3]
https://demo-trunk.ofbiz.apache.org/facility/control/PicklistManage?facilityId=WebStoreWarehouse

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Mon, Jun 1, 2020 at 1:38 PM Suraj Khurana 
wrote:

> Hello Pawan,
>
> IMO, this label is confusing/misleading, this is order pick list or
> basically order details for warehouse manager to keep as a copy with
> himself. It will be always on each order level on the create picklist page.
> So that before creating a picklist he can check/select which orders to
> pick.
>
> Actual pick sheet (used by picker) is something available under manage
> picklist i.e. after picklist is created, which tells picker which item to
> pick from which location, no further order details.
>
> Am I missing something?
>
> --
> Best Regards,
> Suraj Khurana
> SENIOR TECHNICAL CONSULTANT
> mobile: +91 9669750002
> email: suraj.khur...@hotwax.co
> *www.hotwax.co <http://www.hotwax.co/>*
>
>
> On Mon, Jun 1, 2020 at 3:09 PM Pawan Verma 
> wrote:
>
> > Hello Devs,
> >
> > While working on OFBIZ-11781, issue of the distorted currency symbol.
> > Pierre asked: Are we confident that prices and currency symbols are a
> > requirement for a pick sheet?
> >
> > The important information for picket is Item, quantity, and location.
> > Pickers really don't need the unit price, subtotal, or other
> price-related
> > information.
> >
> > Should we remove the unit price and subtotal information from a pick
> sheet
> > report? Or should we fix OFBIZ-11781 only?
> >
> > Your suggestions are appreciated!
> > --
> > Thanks & Regards
> > Pawan Verma
> > Technical Consultant
> > *HotWax Systems*
> > *Enterprise open source experts*
> > http://www.hotwaxsystems.com
> >
>

Re: Adopting Github Workflow

[Pierre Smits]

HI Jacques,

IMO, we can. But I would give it another few days (the customary minimum)
to see whether others care to differ.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Mon, May 25, 2020 at 6:54 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi All,
>
> I believe we are now pragmatically using JIRA + Patch, or GH + PR.
>
> Remains the question about allowing the creation of issues in GH. It seems
> to me that nobody actually asked for that since Jira is enough for our
> needs.
>
> So I should not need more than what we use currently and can put
> https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both
> in Attic now, right?
>
> Jacques
>
> Le 18/03/2020 à 18:22, Michael Brohl a écrit :
> > +1 James!
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 18.03.20 um 17:13 schrieb James Yong:
> >> Hi all,
> >>
> >> I personally feel we should allow both JIRA and Github for issue
> management, and let contributers use their own judgement on which one to
> use. JIRA
> >> contains wealth of information and many open issues for review, while
> Github allows easier review of source codes.
> >> So do either JIRA + Patch, or GH + PR.
> >>
> >> Regards,
> >> James
> >>
> >> On 2020/03/14 10:43:31, Jacques Le Roux 
> wrote:
> >>> Hi Benjamin, All,
> >>>
> >>> That's a good point indeed. And we 1st need to clearly define what are
> the old and the new processes. Here is a try:
> >>>
> >>> The "old process" (not so old, changed with Git replacing Svn, hence
> the discussion) is
> >>>
> >>>* use Jira to create issues with possibly attached patches and
> discussion there. With all what Jira affords...
> >>>* You can also link a GH PR from Jira. And have a patch, then it
> begins to be confusing (which one is the later, etc.)
> >>>* You can create a PR in GH and discuss it there, nothing else.
> There should not be crossed discussions in Jira and GH
> >>>* I certainly miss other points, that's the gist
> >>>
> >>> The new process is not clearly defined, here are 2 possible versions:
> >>>
> >>>* Jira is only used for history reason, no more issue creations
> allowed
> >>>* GH is used not only for PR but also to create issues (needs a PMC
> agreement). It's then a replacement of Jira and we need to be quite careful
> >>>  doing so.
> >>>
> >>>* Jira continues to be used as is. With IMO some restrictions,
> like: if you have a patch you don't create a PR, it's one or the other way.
> >>>* GH is used not only for PR but also to create issues (needs a PMC
> agreement) an discuss them there. PR or attached patch can be used to
> >>> contribute.
> >>>
> >>> As you see, for me the question is not  "GitHub or Jira"  but "GitHub
> or Jira or both" I have changed the title of the related wiki page
> accordingly:
> >>>
> >>>
> https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both
> >>>
> >>> HTH
> >>>
> >>> Jacques
> >>>
> >>> Le 13/03/2020 à 17:41, Benjamin Jugl a écrit :
> >>>> I have been following this discussion for a while.  However, I still
> wonder if this discussion is about which of the two options is the better
> one.
> >>>> In my opinion, the discussion should rather be about whether the
> potential benefits of a new process justify the effort to change the old
> one. It
> >>>> seems to me at least that this aspect is being neglected a bit.
> >>>>
> >>>> Am 13.03.20 um 10:24 schrieb Michael Brohl:
> >>>>> Hi all,
> >>>>>
> >>>>> I'd like to encourage everyone to visit the wiki page
> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT,
> read
> >>>>> carefully, check, dicuss and ask questions to get to a good
> information base for an important decision to make.
> >>>>>
> >>>>> Thanks everyone,
> >>>>>
> >>>>> Michael Brohl
> >>>>>
> >>>>> ecomify GmbH - www.ecomify.de
> >>>>>
> >>>>>
> >>>>> Am 12.03.20 um 17:28 schrieb Jacques Le Roux:
> >>>>>> You are all invited to review, discuss in comments and possibly add
> pro and cons on this page
> >>>>>>
> >>>>>>
> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT
> >>>>>>
> >>>>>> It would else become unreadable here...
> >>>>>>
> >>>>>> Hopefully we will get to a consensus...
> >>>>>>
> >>>>>> Jacques
> >>>>>>
> >>>>>>
> >
>

Re: LineLength for checkstyle

[Pierre Smits]

How many files would violate that 2000-lines rule?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Tue, May 26, 2020 at 8:11 AM Suraj Khurana 
wrote:

> +1 for setting rule. Also we can think of some configured values instead of
> 2000 (default). may be we should set it to 3000 instead.
>
> And then as Daniel mentioned, work on refactoring those offending source
> files where possible.
>
> --
>
> Best Regards,
> Suraj Khurana
> Senior Technical Consultant
>
>
> On Mon, May 25, 2020 at 8:49 PM Carsten Schinzer <
> cars...@dcs-verkaufssysteme.de> wrote:
>
> > +1 for setting the max lines rule
> >
> > > Am 25.05.2020 um 17:05 schrieb Daniel Watford :
> > >
> > > Hi Jacques,
> > >
> > > I would vote for setting an explicit rule to have the max line length
> set
> > > at 2000 lines and then work on refactoring those offending source files
> > > where possible.
> > >
> > > If we find some files cannot be split up then I think we can add
> > exceptions
> > > to prevent the max line length rule from being applied to them. But
> that
> > > should be done on a file by file basis.
> > >
> > > I still have OFBIZ-11456 on my todo list to refactor MacroFormRenderer.
> > > Work has been progressing slowly but development has slowed during the
> > > pandemic. I hope to get back on top of this soon.
> > >
> > > Thanks,
> > >
> > > Dan.
> > >
> > > On Mon, 25 May 2020 at 15:43, Jacques Le Roux <
> > jacques.le.r...@les7arts.com>
> > > wrote:
> > >
> > >> Hi All,
> > >>
> > >> Suraj rightly mentioned that we have no FileLength checkstyle rule and
> > the
> > >> max default is 2000 lines:
> > >> https://checkstyle.sourceforge.io/config_sizes.html#FileLength
> > >>
> > >> We have some very large Java files in trunk and few (19) are longer
> than
> > >> 2000 lines.
> > >> The question is should we increase FileLength checkstyle rule to hide
> > the
> > >> issue or try to split those files?
> > >>
> > >> I have created https://issues.apache.org/jira/browse/OFBIZ-11740 for
> > that
> > >>
> > >> Jacques
> > >>
> > >> https://checkstyle.sourceforge.io/config_sizes.html#FileLength
> > >>
> > >> Le 25/05/2020 à 15:09, Suraj Khurana a écrit :
> > >>> This is done in rev # d6ebef619349f809062641d1b558cacdec3da208
> > >>>
> > >>> --
> > >>> Best Regards,
> > >>> Suraj Khurana
> > >>> Senior Technical Consultant
> > >>>
> > >>>
> > >>> On Mon, May 25, 2020 at 2:16 PM Suraj Khurana <
> suraj.khur...@hotwax.co
> > >
> > >>> wrote:
> > >>>
> > >>>> Thanks everyone,
> > >>>>
> > >>>> Here[1] is the ticket to track this improvement.
> > >>>>
> > >>>> [1]: https://issues.apache.org/jira/browse/OFBIZ-11737
> > >>>>
> > >>>> --
> > >>>> Best Regards,
> > >>>> Suraj Khurana
> > >>>> Senior Technical Consultant
> > >>>>
> > >>>>
> > >>>> On Sun, May 24, 2020 at 1:58 PM Olivier Heintz <
> > >>>> holivier.li...@ofbizextra.org> wrote:
> > >>>>
> > >>>>> +1
> > >>>>>
> > >>>>> Le 23/05/2020 à 17:29, Suraj Khurana a écrit :
> > >>>>>> Hello Devs,
> > >>>>>>
> > >>>>>> Recently we are facing some checkstyle issues and one cause of it
> is
> > >>>>>> LineLength property.
> > >>>>>> Currently we have set it to 120, I think we should make it to 150
> > >>>>> instead.
> > >>>>>> It is pretty visible in 13/14 font sizes as well.
> > >>>>>>
> > >>>>>> Please share your thoughts on this.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Best Regards,
> > >>>>>> Suraj Khurana
> > >>>>>> Senior Technical Consultant
> > >>>>>>
> > >>
> > >
> > >
> > > --
> > > Daniel Watford
> >
> >
>

Re: Difficulties to support the Community Days

[Pierre Smits]

Thanks Carsten.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Mon, May 25, 2020 at 11:49 AM Carsten Schinzer <
cars...@dcs-verkaufssysteme.de> wrote:

> https://issues.apache.org/jira/browse/OFBIZ-11738
>
> :)
>
>
> > Am 25.05.2020 um 11:43 schrieb Pierre Smits :
> >
> > Ahh. Yes, there is also Fisheye (another Atlassian product,  and still in
> > play). That aspect of our tooling hasn't been adjusted yet (showing
> (links
> > to) commits in Github.
> >
> > Please be so kind to raise an issue regarding this, so that it can be
> > followed through.
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> >>
>
>

Re: Difficulties to support the Community Days

[Pierre Smits]

Ahh. Yes, there is also Fisheye (another Atlassian product,  and still in
play). That aspect of our tooling hasn't been adjusted yet (showing (links
to) commits in Github.

Please be so kind to raise an issue regarding this, so that it can be
followed through.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


>

Re: OFBiz contributions & Github Pull Requests

[Pierre Smits]

Hi all,

In this thread we discussed improvements to the Contributing via Git and
Github page in Confluence (see [1]). Some were then adamant that the page
should have the WIP status referenced in the subject/title.

However, since then the page hasn't changed. If nothing comes forward in
the coming days, I will remove the WIP status from the subject/title. After
that, contributors can continue to improve the page, like they can improve
any other page that doesn't have the WIP status in the subject/title


[1]
https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github+-+WIP
Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Sat, Feb 22, 2020 at 10:12 AM Michael Brohl 
wrote:

> It seems you just removed the work in progess notes from the page
> without waiting for the review I've announced.
>
> The page should be marked as WIP until we agree on the processes
> described there, IMO.
>
> Thanks,
>
> Michael
>
>
> Am 22.02.20 um 08:59 schrieb Pierre Smits:
> > @Michal,
> >
> > Your comments have been addressed and noted. You can continue to review,
> > discuss and suggest changes...
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor* (but unfortunately without privileges)* of* Apache
> > OFBiz <https://ofbiz.apache.org/>, since 2008
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Fri, Feb 21, 2020 at 9:24 AM Michael Brohl 
> > wrote:
> >
> >> I made a comment just yesterday. The page needs review and this might
> >> take some time.
> >>
> >> Michael
> >>
> >>
> >> Am 21.02.20 um 09:20 schrieb Pierre Smits:
> >>> Hi All,
> >>>
> >>> It seems feedback on the 'Contributing via Git and Github' page in our
> >> wiki
> >>> has subsided. Shortly I will apply lazy consensus to remove its WiP
> >> status.
> >>> Met vriendelijke groet,
> >>>
> >>> Pierre Smits
> >>> *Proud* *contributor* (but unfortunately without privileges)* of*
> Apache
> >>> OFBiz <https://ofbiz.apache.org/>, since 2008
> >>>
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>>
> >>> On Fri, Feb 14, 2020 at 1:55 PM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> Jacques
> >>>>
> >>>> Le 14/02/2020 à 12:29, Pierre Smits a écrit :
> >>>>> Hi Nicolas,
> >>>>>
> >>>>> Your suggestion to show only open PRs is way better.
> >>>>>
> >>>>> I will update the page.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Pierre Smits
> >>>>> *Proud* *contributor* (but without privileges)* of* Apache OFBiz
> >>>>> <https://ofbiz.apache.org/>, since 2008
> >>>>>
> >>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>
> >>>>>
> >>>>> On Fri, Feb 14, 2020 at 12:15 PM Nicolas Malin <
> >> nicolas.ma...@nereide.fr
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>> On 31/01/2020 15:53, Pierre Smits wrote:
> >>>>>>
> >>>>>> Pull Request available on Github can be seen in the local clone. In
> >>>> order
> >>>>>> to have this working, the following line should be added to the git
> >>>>>> configuration of the local clone:
> >>>>>>
> >>>>>> fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
> >>>>>>
> >>>>>>
> >>>>>> Preferably this line should exist before the 'fetch =
> >>>>>> +refs/heads/*:refs/remotes/origin/*' of the 'Github' remote.
> >>>>>>
> >>>>>> After some tries I propose to use
> >>>>>>
> >>>>>>   fetch = +refs/pull/*/merge:refs/remotes/pr/*
> >>>>>>
> >>>>>> instead of
> >>>>>>
> >>>>>>   fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
> >>>>>>
> >>>>>> The first list pull request available to merge, and the second list
> >> all
> >>>>>> pull request (closed included)
> >>>>>>
> >>>>>> Nicolas
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>
>
>

Re: Difficulties to support the Community Days

[Pierre Smits]

Hi Carsten,

Welcome back.

re: 1
Indeed things has changes. Yet there is no dependency on Fishbowl. In fact
there is no mention at all in any of our mailing lists regarding an
integration with fishbowl. The tools still in use by the project: Jira (for
issue management, release management, etc), GitHub (public repos, pull
requests from forks and local clones), Confluence for documentation.

re: 2
The consensus within the community is that feature/bug branches exist in
the local clones (from forks or directly from the public repos) until
maturity. After that proposed changes are handled though pull requests.
This enables community members to collaborate on feature/bug branch (by
forking/cloning from the community member's repo, while at the same time
avoiding a cluttered and confusing public repo).  the See [1] and [2].

There is also a page in our wiki regarding this. see [3]


[1] https://github.com/apache/ofbiz-framework/pulls
[2] https://github.com/apache/ofbiz-plugins/pulls
[3]
https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github+-+WIP


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Mon, May 25, 2020 at 11:06 AM Carsten Schinzer <
cars...@dcs-verkaufssysteme.de> wrote:

> Hello all,
>
>
> Admittedly I have been away for a very long time and things have changed.
> I seem to be having difficulties to contribute to the Community Days, but
> maybe simply rookie issues, so any helping hand is appreciated.
>
> I have this status:
> * OFBiz code bases (framework and plugins) cloned from git
> * local framework testing completed
> * JIRA Access working - I can see and follow the current sprint
> * Confluence Access working - surprising after almost 9 years of silence;
> that’s what I call continuity :)
>
> I am stuck here:
> 1) While I can see Jira tickets, when I want to investigate commits, I
> need to log on to Fishbowl, but that appears to be a new account. Who can
> grant me access?
>
> 2) I do see the three main branches on git, but I fail to see any (feature
> or bug) branches with ongoing development. Are you working with local
> branching and limiting the main branch interactions to pull requests? Am I
> just missing permission?
>
> Thanks for helping me to get up to speed.
> Warm regards
>
>
> Carsten
>
>

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Pierre Smits]

Wow
You seem vexed.

We're not rotating branches every other week...


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Sun, May 24, 2020 at 7:18 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> The idea is that the branches are rotating (R16 was stable 2 months ago)
> and it would be a pain to change that each time.
>
> Do you get that or should I explain more?
>
> Le 24/05/2020 à 18:55, Pierre Smits a écrit :
> > Even when opting to keep it the simple way as you envision it, it would
> > still be better to name the sub folder like the branch it is intended for
> > (instead of stable).
> >
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Sun, May 24, 2020 at 6:24 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Pierre,
> >>
> >> Because there should be almost no differences (if any) in the
> >> documentation of 17.12.01 and 17.12.03
> >>
> >> So my idea is to keep it simple: each supported branches would have a
> >> documentation and that's it.
> >>
> >> Else:
> >>
> >>   1. each release we would have to move things.
> >>   2. The documentation is generated by BuibBot. So the script would
> have to
> >> be modified.
> >>   3. And we would have to ask Infra to create another tree.
> >>
> >> It's already some work to change things when we create a new release
> >> branch...
> >>
> >> We could discuss that more but I feel a documentation by supported
> release
> >> branch is enough.
> >>
> >> Jacques
> >>
> >> Le 24/05/2020 à 18:04, Pierre Smits a écrit :
> >>> Jacques,
> >>>
> >>> You seem to be missing my point.
> >>>
> >>> it doesn't matter whether a release contains only bug-fixes,
> >> improvements,
> >>> new features or a combination of those to have a documentation start
> >> point
> >>> under projects/ofbiz/site/
> >>>
> >>> Stable is not something we release, but it is a link to a specific
> >>> reference point in the main repo. In our case, the release. It is also
> >> not
> >>> the branch in our repo where the release was taken from.
> >>>
> >>> So again my question: ' Why don't we use the release id under
> >>> projects/ofbiz/site/'?
> >>>
> >>>
> >>>
> >>> Met vriendelijke groet,
> >>>
> >>> Pierre Smits
> >>> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> >> since
> >>> 2008 (without privileges)
> >>>
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>>
> >>> On Sun, May 24, 2020 at 12:51 PM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>>> Hi Pierre,
> >>>>
> >>>> Between (eg) 17.12.01 and 17.12.03 there are no new features only bug
> >>>> fixes, hence not doc changes.
> >>>>
> >>>> Le 24/05/2020 à 12:25, Pierre Smits a écrit :
> >>>>> Doesn't demo-stable relates to a particular release? Instead of a
> >> branch?
> >>>>> Then why don't we the release id not mentioned under
> >> projects/ofbiz/site/
> >>>>> becoming:
> >>>>>
> >>>>>   - projects/ofbiz/site/17.12.01
> >>>>>   - p

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Pierre Smits]

Even when opting to keep it the simple way as you envision it, it would
still be better to name the sub folder like the branch it is intended for
(instead of stable).



Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Sun, May 24, 2020 at 6:24 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Pierre,
>
> Because there should be almost no differences (if any) in the
> documentation of 17.12.01 and 17.12.03
>
> So my idea is to keep it simple: each supported branches would have a
> documentation and that's it.
>
> Else:
>
>  1. each release we would have to move things.
>  2. The documentation is generated by BuibBot. So the script would have to
> be modified.
>  3. And we would have to ask Infra to create another tree.
>
> It's already some work to change things when we create a new release
> branch...
>
> We could discuss that more but I feel a documentation by supported release
> branch is enough.
>
> Jacques
>
> Le 24/05/2020 à 18:04, Pierre Smits a écrit :
> > Jacques,
> >
> > You seem to be missing my point.
> >
> > it doesn't matter whether a release contains only bug-fixes,
> improvements,
> > new features or a combination of those to have a documentation start
> point
> > under projects/ofbiz/site/
> >
> > Stable is not something we release, but it is a link to a specific
> > reference point in the main repo. In our case, the release. It is also
> not
> > the branch in our repo where the release was taken from.
> >
> > So again my question: ' Why don't we use the release id under
> > projects/ofbiz/site/'?
> >
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Sun, May 24, 2020 at 12:51 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Hi Pierre,
> >>
> >> Between (eg) 17.12.01 and 17.12.03 there are no new features only bug
> >> fixes, hence not doc changes.
> >>
> >> Le 24/05/2020 à 12:25, Pierre Smits a écrit :
> >>> Doesn't demo-stable relates to a particular release? Instead of a
> branch?
> >>>
> >>> Then why don't we the release id not mentioned under
> projects/ofbiz/site/
> >>>
> >>> becoming:
> >>>
> >>>  - projects/ofbiz/site/17.12.01
> >>>  - projects/ofbiz/site/17.12.03
> >>>  - etc.
> >>>
> >>>
> >>> Met vriendelijke groet,
> >>>
> >>> Pierre Smits
> >>> *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> >> since
> >>> 2008 (without privileges)
> >>>
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>>
> >>> On Sun, May 24, 2020 at 10:26 AM Olivier Heintz <
> >>> holivier.li...@ofbizextra.org> wrote:
> >>>
> >>>> Hi Jacques,
> >>>>
> >>>> I have created https://issues.apache.org/jira/browse/INFRA-20311 "we
> >> need
> >>>> directories per release under ci.apache.org/projects/ofbiz/site/"
> >>>>
> >>>> Currently there is :
> >>>> projects/ofbiz/site/
> >>>> ├── javadocs
> >>>> ├── ofbizdoc
> >>>> └── pluginsdoc
> >>>>
> >>>> we want
> >>>> projects/ofbiz/site/
> >>>> ├── stable
> >>>> | ├── javadocs
> >>>> | ├── ofbizdoc
> >>>> | └── pluginsdoc

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Pierre Smits]

Jacques,

You seem to be missing my point.

it doesn't matter whether a release contains only bug-fixes, improvements,
new features or a combination of those to have a documentation start point
under projects/ofbiz/site/

Stable is not something we release, but it is a link to a specific
reference point in the main repo. In our case, the release. It is also not
the branch in our repo where the release was taken from.

So again my question: ' Why don't we use the release id under
projects/ofbiz/site/'?



Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Sun, May 24, 2020 at 12:51 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pierre,
>
> Between (eg) 17.12.01 and 17.12.03 there are no new features only bug
> fixes, hence not doc changes.
>
> Le 24/05/2020 à 12:25, Pierre Smits a écrit :
> > Doesn't demo-stable relates to a particular release? Instead of a branch?
> >
> > Then why don't we the release id not mentioned under projects/ofbiz/site/
> >
> > becoming:
> >
> > - projects/ofbiz/site/17.12.01
> > - projects/ofbiz/site/17.12.03
> > - etc.
> >
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Sun, May 24, 2020 at 10:26 AM Olivier Heintz <
> > holivier.li...@ofbizextra.org> wrote:
> >
> >> Hi Jacques,
> >>
> >> I have created https://issues.apache.org/jira/browse/INFRA-20311 "we
> need
> >> directories per release under ci.apache.org/projects/ofbiz/site/"
> >>
> >> Currently there is :
> >> projects/ofbiz/site/
> >>├── javadocs
> >>├── ofbizdoc
> >>└── pluginsdoc
> >>
> >> we want
> >> projects/ofbiz/site/
> >>├── stable
> >>| ├── javadocs
> >>| ├── ofbizdoc
> >>| └── pluginsdoc
> >>├── next
> >>| ├── javadocs
> >>| ├── ofbizdoc
> >>| └── pluginsdoc
> >>└── trunk
> >> ├── javadocs
> >> ├── ofbizdoc
> >> └── pluginsdoc
> >>
> >>
> >> I have prepared modification in buildbot/.../ofbiz.conf
> >> who can commit it when new directory will be created,
> >> me or you prefer I create a OFBiz Jira ?
> >>
> >> Olivier
> >>
> >> Le 23/05/2020 à 11:51, Jacques Le Roux a écrit :
> >>> Hi Olivier:
> >>>
> >>> It's only in R17, see content of a
> >> https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins build
> >>> If you want to know more look at 'f_ofb_branch17_framework_plugins' in
> >>>
> >>
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/ofbiz.conf/
> >> (only committers)
> >>> All builds mention: "The Documentation is only generated for the next
> >> stable version, at the moment R17"
> >>> Jobs to do are:
> >>>
> >>> Adds the same in trunk and R18
> >>>
> >>> And especially before ask the same than in
> >> https://issues.apache.org/jira/browse/INFRA-17258 distinguishing each
> >> case. Better call them stable, next
> >>> and trunk than R17, R18 and trunk (OK trunk never "change" ;) )...
> >>>
> >>> HTH
> >>>
> >>> Jacques
> >>>
> >>> Le 23/05/2020 à 11:27, Olivier Heintz a écrit :
> >>>> Thanks Jacques for the clarification,
> >>>>
> >>>> But, I'm not sure to understand,
> >>>> currently, doc is generated only for R17 and are only included in
> >> buildbot job for trunkFrameworkPlugin  ?
> >>>> Work to do is to add for job R17Framework and R18Framework ?
> >>>> Infra help is needed