Re: Reviving the OFBiz community day

[Swapnil M Mane]

Thanks so much Sharan for your kind help :-)

I have created sprint - "OFBiz Community Day (May 2019)" and associated it
with an issue for testing purpose.
Everything is working as expected.

P.S. To set the sprint on any issue, simply click on the "Edit" option on
the issue and select the sprint field.


- Best Regards,
Swapnil M Mane,
ofbiz.apache.org



On Fri, May 17, 2019 at 2:07 AM Sharan Foga  wrote:

> Hi All
>
> One of things we did for the community days is to use Jira Sprints to
> identify the issues to work on.  As Swapnil is co-ordinating this effort -
> I've added him to the Jira admins so that he can create sprints. I have
> just created a scrum board that we can use.
>
> Please feel to try it and if it doesn't work well for the community days
> then we can delete  the board, sprints etc and try something else.
>
> Thanks
> Sharan
>
> On 2019/05/15 11:21:22, Swapnil M Mane  wrote:
> > Thanks team!
> > I will post the detailed information about upcoming community day on the
> > user mailing list.
> >
> >
> > - Best Regards,
> > Swapnil M Mane,
> > ofbiz.apache.org
> >
> > On Fri, May 10, 2019 at 12:33 PM Devanshu Vyas <
> vyas.devansh...@gmail.com>
> > wrote:
> >
> > > Great initiative and love to be a part of it. +1
> > >
> > >
> > > Thanks & Regards,
> > > Devanshu Vyas.
> > >
> > >
> > > On Thu, May 9, 2019 at 4:05 PM Swapnil M Mane  >
> > > wrote:
> > >
> > > > Thanks so much everyone for your comments.
> > > >
> > > > The community days are organized once per quarter so a total of four
> (4)
> > > > events throughout the year. Since we skipped the February 2019 month.
> > > Here
> > > > are the proposed dates for this year's community day.
> > > > Contributors can select any single day based on there availability
> and
> > > > preferences.
> > > >
> > > >
> > > >- Q1 - Community Days *February 2019*  - N/A
> > > >
> > > >
> > > >- Q2 - Community Days *May 2019* are *Friday 24th, Saturday 25th,
> > > Sunday
> > > >26th, Monday 27th and Tuesday 28th*
> > > >
> > > >
> > > >- Q3 - Community Days *August 2019* are *Friday 23rd, Saturday
> 24th,
> > > >Sunday 25th, Monday 26th and Tuesday 27th*
> > > >
> > > >
> > > >- Q4 - Community Days* November 2019 *are *Friday 22nd, Saturday
> 23rd,
> > > >Sunday 24th, Monday 25th and Tuesday 26nd*
> > > >
> > > >
> > > > If we are fine these days, I will share the *detailed* updates on
> user's
> > > > mailing list.
> > > >
> > > >
> > > > - Thanks & Regards,
> > > > Swapnil M Mane,
> > > > ofbiz.apache.org
> > > >
> > > >
> > > >
> > > > On Fri, Apr 26, 2019 at 2:06 PM Nicolas Malin <
> nicolas.ma...@nereide.fr>
> > > > wrote:
> > > >
> > > > > I follow you on this way :)
> > > > >
> > > > > On 26/04/2019 09:09, Sanjay Yadav wrote:
> > > > > > Nice initiative, Swapnil. I am in for community day.
> > > > > >
> > > > > > Best Regards,
> > > > > >
> > > > > > *Sanjay Yadav* | Manager, QA
> > > > > > HotWax Systems 
> > > > > > 80, Scheme No. 78, Indore, M.P. 452010, India
> > > > > > Mobile Phone: 787 918 8830 | Linkedin: Sanjay-Yadav
> > > > > > 
> > > > > >
> > > > > >
> > > > > > On Thu, Apr 25, 2019 at 10:54 AM Swapnil M Mane <
> > > > swapnilmm...@apache.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Hello team,
> > > > > >> We are having a great community, I would like to thank everyone
> for
> > > > > their
> > > > > >> participation.
> > > > > >>
> > > > > >> In year 2017, we start celebrating the OFBiz community days [1].
> > > > > >> The contribution during community days played very significant
> role
> > > in
> > > > > >> improvement of framework.
> > > > > >> Should we start this celebration again, thought?
> > > > > >>
> > > > > >>
> > > > > >> [1]
> > > > >
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Community+Days
> > > > > >>
> > > > > >>
> > > > > >> - Best Regards,
> > > > > >> Swapnil M Mane,
> > > > > >> ofbiz.apache.org
> > > > > >>
> > > > >
> > > >
> > >
> >
>

Re: Reviving the OFBiz community day

[Sharan Foga]

Hi All

One of things we did for the community days is to use Jira Sprints to identify 
the issues to work on.  As Swapnil is co-ordinating this effort - I've added 
him to the Jira admins so that he can create sprints. I have just created a 
scrum board that we can use.

Please feel to try it and if it doesn't work well for the community days then 
we can delete  the board, sprints etc and try something else.

Thanks
Sharan

On 2019/05/15 11:21:22, Swapnil M Mane  wrote: 
> Thanks team!
> I will post the detailed information about upcoming community day on the
> user mailing list.
> 
> 
> - Best Regards,
> Swapnil M Mane,
> ofbiz.apache.org
> 
> On Fri, May 10, 2019 at 12:33 PM Devanshu Vyas 
> wrote:
> 
> > Great initiative and love to be a part of it. +1
> >
> >
> > Thanks & Regards,
> > Devanshu Vyas.
> >
> >
> > On Thu, May 9, 2019 at 4:05 PM Swapnil M Mane 
> > wrote:
> >
> > > Thanks so much everyone for your comments.
> > >
> > > The community days are organized once per quarter so a total of four (4)
> > > events throughout the year. Since we skipped the February 2019 month.
> > Here
> > > are the proposed dates for this year's community day.
> > > Contributors can select any single day based on there availability and
> > > preferences.
> > >
> > >
> > >- Q1 - Community Days *February 2019*  - N/A
> > >
> > >
> > >- Q2 - Community Days *May 2019* are *Friday 24th, Saturday 25th,
> > Sunday
> > >26th, Monday 27th and Tuesday 28th*
> > >
> > >
> > >- Q3 - Community Days *August 2019* are *Friday 23rd, Saturday 24th,
> > >Sunday 25th, Monday 26th and Tuesday 27th*
> > >
> > >
> > >- Q4 - Community Days* November 2019 *are *Friday 22nd, Saturday 23rd,
> > >Sunday 24th, Monday 25th and Tuesday 26nd*
> > >
> > >
> > > If we are fine these days, I will share the *detailed* updates on user's
> > > mailing list.
> > >
> > >
> > > - Thanks & Regards,
> > > Swapnil M Mane,
> > > ofbiz.apache.org
> > >
> > >
> > >
> > > On Fri, Apr 26, 2019 at 2:06 PM Nicolas Malin 
> > > wrote:
> > >
> > > > I follow you on this way :)
> > > >
> > > > On 26/04/2019 09:09, Sanjay Yadav wrote:
> > > > > Nice initiative, Swapnil. I am in for community day.
> > > > >
> > > > > Best Regards,
> > > > >
> > > > > *Sanjay Yadav* | Manager, QA
> > > > > HotWax Systems 
> > > > > 80, Scheme No. 78, Indore, M.P. 452010, India
> > > > > Mobile Phone: 787 918 8830 | Linkedin: Sanjay-Yadav
> > > > > 
> > > > >
> > > > >
> > > > > On Thu, Apr 25, 2019 at 10:54 AM Swapnil M Mane <
> > > swapnilmm...@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Hello team,
> > > > >> We are having a great community, I would like to thank everyone for
> > > > their
> > > > >> participation.
> > > > >>
> > > > >> In year 2017, we start celebrating the OFBiz community days [1].
> > > > >> The contribution during community days played very significant role
> > in
> > > > >> improvement of framework.
> > > > >> Should we start this celebration again, thought?
> > > > >>
> > > > >>
> > > > >> [1]
> > > > https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Community+Days
> > > > >>
> > > > >>
> > > > >> - Best Regards,
> > > > >> Swapnil M Mane,
> > > > >> ofbiz.apache.org
> > > > >>
> > > >
> > >
> >
> 

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

[Michael Brohl]

Hi Pierre,

I think there are more sophisticated concepts for some of the mentioned 
entities, for example


- OrderRole for orders allows to connect an unlimited number of parties 
with different roles


- CustRequestParty, QuoteRole, CustRequestRole - same principle

For these, introducing from/toPartyId would be no improvement IMO. *If* 
we would want to make a change, I would tend more to implementing the 
...Role principle where it is missing and get rid of the from/toPartyId 
pattern. But this would be a big change...


I'm not sure why we have these in some entities which also have the 
...Role entities, such as Invoice.


Maybe others can give more insights?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 13.05.19 um 13:41 schrieb Pierre Smits:

Hi All,

Currently several entities capture the (contractual) parties in fields like
fromPartyId and toPartyId. These parties commonly represent the internal
(accounting) organisation and the external party (the customer, supplier,
contact, account, carrier etc).

Such entities are:

- Agreement (in party)
- Employment (in humanres)
- Invoice (in accounting
- OrderReportPurchasesGroupByProduct
- PartyBenefit (in humanres)
- Payment (in accounting)
- PayHistory (in humanres)
- ReturnHeader (in Order)
- UnemploymentClaim (in humanres


However there are a (quite a) few entities that defy these 1-on-1
relationships (between internal party and the object, and the external
party and the object), like:

- OrderHeader: neither partyIdFrom nor partyIdTo
- Quote: neither partyIdFrom nor partyIdTo but having a partyId field
- CustRequest: only having fromPartyid (plus its role
- Subscription: having originatedFromPartyId (plus the role) and partyId
- ReorderGuideline: having partyId (plus the role)

And I am confident I am missing a few.

In oder to simplify processes for capturing the main parties in various
entity records I propose to realign these (master) entities to ensure that
both the primary internal and external parties (and their primary roles)
are captured.

What are your thoughts?

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jira] [Updated] (OFBIZ-11031) Improve SalesOrderItemFact table

[Pierre Smits]

Hi Aditya, All,

IMO, there are already to many tickets not worked on, but being managed.
And I don't see much progress initiated by the assignees of those tickets
to get the work of the underlying tasks completed. While parent tickets
(and sub tasks) work well for other parties with a more hierarchical and
contractually controlled structure, it does not work that well for an
organisation like the ASF (and projects under its umbrella) where
activities of contributors can't be dictated, nor managed by the assignee
of the parent ticket.

Furthermore, a parent ticket works well for task and new feature tickets.
And not that well for bug fix and improvement tickets.

If you (and others) want to keep track of progress, I believe, there are
ample ways to do that. JIRA provides plenty of tools to get an overview of
whatever. One of such is

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12310603

and I feel confident that anyone can create a good filter on OFBiz tickets
that will deliver on specific needs.

An other way to track progress regarding OFBiz Business Intelligence (aka
the BI component) is through the wiki pages associated with the subject,
see e.g.

https://cwiki.apache.org/confluence/display/OFBIZ/Business+Intelligence


Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Thu, May 16, 2019 at 2:45 PM Aditya Sharma 
wrote:

> Hi Pierre,
> It seems work is related to Business Intelligence[1] work. Thanks for your
> efforts in this direction.
>
> I would suggest that it would be much better if you could have a parent
> ticket for all these tasks that define the plan and purpose. It would quite
> easy to track the progress if the tickets are grouped together.
>
> 1. https://cwiki.apache.org/confluence/display/OFBIZ/Business+Intelligence
>
> On Thu, May 16, 2019 at 4:12 PM Pierre Smits (JIRA) 
> wrote:
>
> >
> >  [
> >
> https://issues.apache.org/jira/browse/OFBIZ-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > ]
> >
> > Pierre Smits updated OFBIZ-11031:
> > -
> > Labels: Fact SalesOrder SalesOrderItemFact birt dwh  (was: dwh)
> >
> > > Improve SalesOrderItemFact table
> > > 
> > >
> > > Key: OFBIZ-11031
> > > URL: https://issues.apache.org/jira/browse/OFBIZ-11031
> > > Project: OFBiz
> > >  Issue Type: Improvement
> > >  Components: bi
> > >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
> > >Reporter: Pierre Smits
> > >Priority: Major
> > >  Labels: Fact, SalesOrder, SalesOrderItemFact, birt, dwh
> > >
> > > Improve the SalesOrderFactTable to include additional dimensions
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v7.6.3#76005)
> >
>

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

[Pierre Smits]

Hi Rishi, All,

The agreement entity caters for capturing the principal two parties and
their appropriate roles. This caters for the majority of the agreements
struck between the representatives of the internal (accounting)
organisation and their business partners.

The use case you presented (one agreement between the internal organisation
and multiple supplier parties to pay those suppliers a fee based on sales)
is, IMO,:

   1. unlikely to happen. Any such agreement can be broken up into unique
   contracts between the internal organisation and each supplier, with each
   having their unique conditions. Besides, who would willingly agree to
   having the same conditions as its competitors. Each principal party aims to
   get the best deal for itself.
   2. needlessly complex to maintain. When the agreement is the precursor
   to the legal document (i.e. through the pdf) such would only be valid if
   and when the document is signed by all principal parties involved. And as a
   follow-up a copy of that signed document retained through the context
   object associated with the agreement.

I would say that, given the (potential) adopter audience, multi-principles
agreements are currently not the first thing on their mind in their process
to vet OFBiz for their business.But I may be mistaken, and there are
multiple (existing) adopters out there that work with such contracts. I
would love to hear from them.

In most cases, the AgreementRoles associated with an agreement are the
persons (of the internal organisation) involved in reviewing, viewing and
approving the contract, and the persons (contacts in various roles) of the
opposing party

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Tue, May 14, 2019 at 11:10 AM Rishi Solanki 
wrote:

> Dear Pierre,
> Few inputs for thoughts;
>
> One agreement from company to multiple parties may exists. For example;
> From Company if sale is more than $10,000 then company may credit/discount
> 10% of sale to its suppliers. Then it will be applicable to more than one
> supplier, then AgreementRole entity is suitable in that case.
>
> To be clarify I'm not against this proposal because other entities in the
> list are good candidate for this. Also following common pattern is good
> reason to go with this, may be we can add or filter some entities.
>
> But I will be able to say yes/no for the proposal after some more inputs
> come from community.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems 
> Linkedin: *Rishi Solanki*
> 
> Direct: +91-9893287847
>
>
> On Mon, May 13, 2019 at 5:11 PM Pierre Smits 
> wrote:
>
> > Hi All,
> >
> > Currently several entities capture the (contractual) parties in fields
> like
> > fromPartyId and toPartyId. These parties commonly represent the internal
> > (accounting) organisation and the external party (the customer, supplier,
> > contact, account, carrier etc).
> >
> > Such entities are:
> >
> >- Agreement (in party)
> >- Employment (in humanres)
> >- Invoice (in accounting
> >- OrderReportPurchasesGroupByProduct
> >- PartyBenefit (in humanres)
> >- Payment (in accounting)
> >- PayHistory (in humanres)
> >- ReturnHeader (in Order)
> >- UnemploymentClaim (in humanres
> >
> >
> > However there are a (quite a) few entities that defy these 1-on-1
> > relationships (between internal party and the object, and the external
> > party and the object), like:
> >
> >- OrderHeader: neither partyIdFrom nor partyIdTo
> >- Quote: neither partyIdFrom nor partyIdTo but having a partyId field
> >- CustRequest: only having fromPartyid (plus its role
> >- Subscription: having originatedFromPartyId (plus the role) and
> partyId
> >- ReorderGuideline: having partyId (plus the role)
> >
> > And I am confident I am missing a few.
> >
> > In oder to simplify processes for capturing the main parties in various
> > entity records I propose to realign these (master) entities to ensure
> that
> > both the primary internal and external parties (and their primary roles)
> > are captured.
> >
> > What are your thoughts?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> privileges)
> > since 2008*
> > Apache Steve , committer
> >
>

Re: JobSandbox temporal expression timezone

[Pawan Verma]

Hello Devs,

I have logged Jira for this improvement. Here is the link for the same:
https://issues.apache.org/jira/browse/OFBIZ-11035

Soon, I will add a patch for this. Suggestions are most welcome. Thanks!
-- 
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Wed, Mar 20, 2019 at 4:01 AM Scott Gray 
wrote:

> Hi Rishi,
>
> Thanks for taking a look!
>
> My only concern with using runAsUser would be that recurring services
> typically use the "system" UserLogin and using this approach might require
> multiple UserLogin/UserPreference records if there are different recurring
> services using different timezones.
>
> Also it should be fine to use RunTime data, as of now I could not see no
> > issues with that. The only thing is not possible is if system requires to
> > run a service always on specific time zone values and runtime could have
> > different values.
> >
>
> Yeah I think I don't like the RuntimeData idea after thinking about it, an
> opposite use case to my one might cause problems, e.g.:
> I want a report to run at midnight UTC every night but I want the
> timestamps converted to Pacific Time because that's where my users are so I
> would like to use timeZone "America/Los_Angeles" or similar for the service
> context.
>
> So I think unless other ideas come along, my preference would be for adding
> a new field to JobSandbox.  I'll create a ticket within the next few days
> and try to come up with a better field name.  Maybe "recurrenceTimeZone",
> seems clear and somewhat concise.
>
> Thanks
> Scott
>
> On Tue, 19 Mar 2019 at 22:24, Rishi Solanki 
> wrote:
>
> > Hello Scott,
> > Can we think of using JobSandbox.runAsUser='myuser' and UserPreference.
> >
> >  > userPrefGroupTypeId="GLOBAL_PREFERENCES"
> userPrefTypeId="defaultTimeZoneId"
> > userPrefValue="UTC"/>
> >
> > Also it should be fine to use RunTime data, as of now I could not see no
> > issues with that. The only thing is not possible is if system requires to
> > run a service always on specific time zone values and runtime could have
> > different values. So having value in database makes sense to me, and okay
> > with #1 of having it on JobSandbox level.
> >
> > I proposed UserPreference so that no field added with possible solution
> and
> > we can achieve it. Could not think of any side effect as of now if we use
> > it only for schedule, in case the same can be use for different purpose
> > while log in, then it may have several side effects.
> >
> > Best Regards,
> > --
> > *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > HotWax Systems 
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > Indore,
> > M.P 452010
> > Linkedin: *Rishi Solanki*
> > 
> > Direct: +91-9893287847
> >
> >
> > On Tue, Mar 19, 2019 at 10:56 AM Scott Gray <
> scott.g...@hotwaxsystems.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > Trying to decide on the best way to define a temporal expression for a
> > > recurring job where the temporal expression should be evaluated using a
> > > timezone other than whatever the default timezone is for the system.
> > >
> > > Use case is having a system that runs on UTC time, but needs to send a
> > > report at 5pm Pacific Time everyday regardless of whether or not
> daylight
> > > savings is in effect.
> > >
> > > I see two options:
> > > 1. Add a field to JobSandbox such as tempExprTzId (or better name!)
> > > 2. Use whatever timezone is available in the RunTime data service
> context
> > >
> > > #2 seems simplest but I'm not sure if there's scenarios where the
> service
> > > should be run with one timezone while the recurrence should be
> scheduled
> > > based on another?  I can't think of any.
> > >
> > > Regards
> > > Scott
> > >
> >
>

Re: Code Improvement for Groovy

[Jacques Le Roux]

Thanks Scott,

Quite helpful!

Jacques

Le 16/05/2019 à 10:12, Scott Gray a écrit :

Hi Pawan

Sounds good, just one point to be careful of:
maxRetry = 0
if (!maxRetry) {
  // Not set, use a default
  maxRetry = -1
}

Because groovy evaluates zero to be false, it wouldn't be possible to set
maxRetry to zero.  So it's best not to use groovy truth for null-checks on
numbers in some cases.  I thought it was worth mentioning since there's a
higher risk of making this mistake when making changes in bulk.

Regards
Scott

On Thu, 16 May 2019 at 00:29, Pawan Verma 
wrote:


Hello Devs,

As we all know, Groovy is a powerful language with great built-in
functions. Groovy Truth[1] is one of them, which is not used properly in
our code base. We have used UtilValidate Class to validate arguments for
Empty or NotEmpty, which can easily be done in groovy with built-in
functionality.

Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }

Groovy Built-in Code: if (locations) { ... }

IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
Please let me know your thoughts on this. Thanks!
[1] - http://groovy-lang.org/semantics.html#Groovy-Truth

--
Kind Regards
Pawan Verma
Technical Consultant
*HotWax Systems*

Re: Code Improvement for Groovy

[Scott Gray]

Hi Pawan

Sounds good, just one point to be careful of:
maxRetry = 0
if (!maxRetry) {
 // Not set, use a default
 maxRetry = -1
}

Because groovy evaluates zero to be false, it wouldn't be possible to set
maxRetry to zero.  So it's best not to use groovy truth for null-checks on
numbers in some cases.  I thought it was worth mentioning since there's a
higher risk of making this mistake when making changes in bulk.

Regards
Scott

On Thu, 16 May 2019 at 00:29, Pawan Verma 
wrote:

> Hello Devs,
>
> As we all know, Groovy is a powerful language with great built-in
> functions. Groovy Truth[1] is one of them, which is not used properly in
> our code base. We have used UtilValidate Class to validate arguments for
> Empty or NotEmpty, which can easily be done in groovy with built-in
> functionality.
>
> Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }
>
> Groovy Built-in Code: if (locations) { ... }
>
> IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
> Please let me know your thoughts on this. Thanks!
> [1] - http://groovy-lang.org/semantics.html#Groovy-Truth
>
> --
> Kind Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
>