Re: Welcome Rishi Solanki as a New Committer!

[Yashwant Dhakad]

Many Congratulations Rishi !!

Thanks & Regards
--
Yashwant Dhakad
HotWax Systems
http://www.hotwaxsystems.com/

On Thu, Aug 10, 2017 at 11:34 AM, Mohammed Rehan Khan <
rehan.k...@hotwaxsystems.com> wrote:

> Congratulations Rishi !!
>
>
> --
> Thanks and Regards,
> Rehan Khan
>
>
> On Wed, Aug 9, 2017 at 2:26 PM, Sharan Foga  wrote:
>
> > The OFBiz PMC has invited Rishi Solanki to become a new committer and are
> > happy to announce that he has accepted.
> >
> > Some of the key factors considered for inviting him were as follows:
> >
> > - He has been involved with the OFBiz project for quite a while which
> > shows dedication and commitment
> > - He has a lot of good knowledge that he is happy to share which shows he
> > is a good team player
> > - His work is consistent, has good code quality and he has provided a
> > range of patches
> > - He is friendly, respectful and keen to help out others in the community
> >
> > Please join me in welcoming and congratulating Rishi!
> >
> > Thanks
> > Sharan
> >
>

Re: Welcome Akash Jain as a New Committer!

[Yashwant Dhakad]

Many Congratulations Akash !!!

Thanks & Regards
--
Yashwant Dhakad
HotWax Systems
http://www.hotwaxsystems.com/

On Thu, Aug 10, 2017 at 11:35 AM, Mohammed Rehan Khan <
rehan.k...@hotwaxsystems.com> wrote:

> Congratulations Akash !!
>
>
> --
> Thanks and Regards,
> Rehan Khan
>
>
>
> On Wed, Aug 9, 2017 at 2:28 PM, Sharan Foga  wrote:
>
> > The OFBiz PMC has invited Akash Jain to become a new committer and are
> > happy to announce that he has accepted.
> >
> > Some of the key factors considered for inviting him were as follows:
> >
> > - He has been involved with the OFBiz project for quite a while which
> > shows his dedication and commitment
> > - He has a lot of good knowledge (both functional and technical) that he
> > is happy to share which shows he is a good team player
> > - He is very active, positive and respectful to others in the community
> > - He has contributed patches and shows a willingness to learn which is
> > really important as the project continues to go through changes
> >
> > Please join me in welcoming and congratulating Akash.
> >
> > Thanks
> > Sharan
> >
>

Re: [PROPOSAL] Lead Source should be associated with the Lead only

[Aditya Sharma]

Thanks Jacques.
Moving the conversation to dev ML.

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Thu, Aug 10, 2017 at 12:06 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Aditya,
>
> I believe this conversation should rather be on dev ML
>
> Thanks
>
> Jacques
>
>
> Le 04/08/2017 à 16:23, Aditya Sharma a écrit :
>
>> Lead Source is essential information for assessing the effectiveness of
>> marketing campaigns. It defines the primary source from which the given
>> lead came from i.e. how the lead found the organization.
>>
>> While working in SFA component, I observed that when we create a Lead &
>> select Lead Source from New Lead page it is not associated with lead. When
>> we provide Group Name it is associated with Group and not with the Lead.
>> However. when we add Lead Source from the Lead Profile page, it is
>> associated with the lead only.
>>
>> These 2 pages contradict each other in terms of their business process.
>>
>> The sole purpose of Lead Source is to define the source of a lead, not the
>> source of a group.
>>
>> I propose that we should update "createLead" service to associate Lead
>> Source to Lead only.
>>
>> Please enlighten me if I missed out something here.
>>
>> Links to verify
>> New Lead Page: https://demo-trunk.ofbiz.apache.org/sfa/control/NewLead
>> Lead Profile Page:
>> https://demo-trunk.ofbiz.apache.org/sfa/control/viewprofile?
>> roleTypeId=LEAD&partyId=sfa101
>>
>> Thanks and Regards,
>>
>> *Aditya Sharma* | Enterprise Software Engineer
>> HotWax Systems 
>> 
>>
>>
>

Re: Quantity UOM in Supplier Product

[Scott Gray]

Hi Vaibhav,

It's a good question and mailing list archives (that are available) don't
really answer the question clearly.  At the moment as far as I can tell,
the quantityUomId and unitsIncluded field do nothing, they're display only.

I think SupplierProduct.unitsIncluded is the same as
Product.quantityIncluded, the field types are the same and the names imply
similar things. I actually think unitsIncluded is a better name than
quantityIncluded which is confusing because the number doesn't relate to
any quantity fields we normally use.

>From the Product entity definition we have this explanation of the fields:
"If you have a six-pack of 12oz soda cans you would have
quantityIncluded=12, quantityUomId=oz, piecesIncluded=6"

piecesIncluded is missing from ProductSupplier but I think the definition
for quantityIncluded/unitsIncluded can stand without it.

So I think what we can conclude from this detail is that these fields are
informative and not functional, and they shouldn't have any bearing against
other fields such as lastPrice.

I think there could be room for making use of the fields, an example:
Let's say you are a house painter and you need to order 12 litres of paint
for a job.  The supplier has two products available, 2 litre tins @ $10 and
4 litre tins @ $15:



So you tell your amazing OFBiz system that you'd like to order 12 liters of
paint, OFBiz will then look at your SupplierProduct records and determine
which record gives you the best price and fits within the supplier's
purchasing rules (i.e. you can't order half a tin of paint). OFBiz
ultimately puts the selection into OrderItem.supplierProductId and sets the
unitPrice accordingly.  As a second function, OrderItem.supplierProductId
can then also serve to correctly format the PO that the supplier receives
so that instead of seeing:
"Send me 12 litres of paint @ $3.75/litre please"
they could instead see:
"Send me 3 units of 4 litre paint @ $15/unit please"
It wouldn't alter what we see in the OrderItem record, but it could be used
for information the supplier receives and perhaps also for shipment receipt
verification (if you wanted 4L tins and they sent you 2L tins, maybe that's
an issue that needs to be dealt with).

I hope that helps.  I've made a few assumptions here so if anyone thinks
I'm incorrect please speak up.

Regards
Scott





On 9 August 2017 at 23:31, Vaibhav Jain 
wrote:

> Hello all,
>
> There are two fields, *quant**ityUomId* and *unitsIncluded* in
> SupplierProduct entity.
> Can someone please elaborate the use of these fields?
>
> After creating a record of SupplierProduct with *quantityUomId*="box" and
> *unitsIncluded*="10", created a purchase order but didn't notice any
> change.
>
> How are these fields entertained in the purchase order?
>
> Thanks & Regards
> Vaibhav Jain
> Hotwax Systems,
> vaibhav.j...@hotwaxsystems.com
>

Keep deleteProductionRunRoutingTask?

[Jacques Le Roux]

Hi,

Please give your opinion on OFBIZ-9568 before I continue on OFBIZ-9185

Thanks

Jacques

Re: Rule to deprecated a service

[Scott Gray]

I think we've had these discussions before Jacques, I'd search the mailing
lists and then perhaps only continue the conversation if you have concerns
about what was agreed previously.

I'm pretty sure the policy was "remove after the next release is out", and
actually released, not just when a branch is cut.

Regards
Scott

On 9 August 2017 at 23:59, Jacques Le Roux 
wrote:

> Hi All,
>
> After Nicolas's work at OFBIZ-9558 I want to create a "Code deprecation
> rules" wiki page.
>
> Before doing so I think we need to get a consensus about when to remove
> deprecated code (Java, Groovy, XML, etc.) and services definitions.
>
> Then we could plan to remove all deprecated code in trunk when for
> instance creating a new release.
>
> I suggest that we don't wait too long and deprecate code when we create
> the first release of the last freezed branch
>
> Opinions?
>
> Jacques
>
>
> Le 07/08/2017 à 00:02, Scott Gray a écrit :
>
>> Some additional nice to haves:
>> - Add a "since" attribute to the "deprecated" element that would contain
>> either a date or a release candidate version string.  This would make it
>> easier for us to know when the service can be removed. (I can't remember
>> the policy for deprecation,  remove after the next release or after two?)
>> - For webtools, add a strikethrough on the service name in the Service
>> List
>> screen and add the information to the UI in the service definition screen.
>>
>> Regards
>> Scott
>>
>> On 7/08/2017 05:04, "Nicolas Malin"  wrote:
>>
>>
>> On Aug 6, 2017 8:47 AM, "Deepak Dixit" 
>> wrote:
>>
>> Hi Nicolas,
>>
>>> And ideally we have to mark services deprecate instead of removing, with
 expected release on which we will remove this deprecated code.



 On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin >>> >
 wrote:
 After a new ofbiz stable branche creation, we remove all deprecated
 service ?

 Any suggests, othet ideas, comments ?


>

Re: Rule to deprecated a service

[Jacques Le Roux]

Le 10/08/2017 à 13:25, Scott Gray a écrit :

I think we've had these discussions before Jacques, I'd search the mailing
lists and then perhaps only continue the conversation if you have concerns
about what was agreed previously.

I'm pretty sure the policy was "remove after the next release is out", and
actually released, not just when a branch is cut.

Oops, that's what I meant too with "deprecate code when we create the first release 
of the last freezed branch".
I tried to be more precise there than in my previous sentence "remove all deprecated 
code in trunk when for instance creating a new release."
But I did not notice I misused "deprecate code" for "remove deprecated code".

I think we are on the same page and don't want to wait loo long keeping 
deprecated code, first occasion is best ;)

Jacques



Regards
Scott

On 9 August 2017 at 23:59, Jacques Le Roux 
wrote:


Hi All,

After Nicolas's work at OFBIZ-9558 I want to create a "Code deprecation
rules" wiki page.

Before doing so I think we need to get a consensus about when to remove
deprecated code (Java, Groovy, XML, etc.) and services definitions.

Then we could plan to remove all deprecated code in trunk when for
instance creating a new release.

I suggest that we don't wait too long and deprecate when we create
the first release of the last freezed branch

Opinions?

Jacques


Le 07/08/2017 à 00:02, Scott Gray a écrit :


Some additional nice to haves:
- Add a "since" attribute to the "deprecated" element that would contain
either a date or a release candidate version string.  This would make it
easier for us to know when the service can be removed. (I can't remember
the policy for deprecation,  remove after the next release or after two?)
- For webtools, add a strikethrough on the service name in the Service
List
screen and add the information to the UI in the service definition screen.

Regards
Scott

On 7/08/2017 05:04, "Nicolas Malin"  wrote:


On Aug 6, 2017 8:47 AM, "Deepak Dixit" 
wrote:

Hi Nicolas,


And ideally we have to mark services deprecate instead of removing, with

expected release on which we will remove this deprecated code.



On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin 

Re: Quantity UOM in Supplier Product

[Vaibhav Jain]

Thank you so much Scott for sharing these details, indeed they are really
helpful.
Kindly see my comments inline.


On Thu, Aug 10, 2017 at 3:22 PM, Scott Gray 
wrote:

> Hi Vaibhav,
>
> It's a good question and mailing list archives (that are available) don't
> really answer the question clearly.  At the moment as far as I can tell,
> the quantityUomId and unitsIncluded field do nothing, they're display only.
>
> I think SupplierProduct.unitsIncluded is the same as
> Product.quantityIncluded, the field types are the same and the names imply
> similar things. I actually think unitsIncluded is a better name than
> quantityIncluded which is confusing because the number doesn't relate to
> any quantity fields we normally use.
>

  IMO, quantityIncluded name can be better choice, because as my
undestanding
unitsIncluded is used to define units of product (like each, pack etc.)
but we may have products in various UOMs like (weight UOM, Liquid/Volume
UOM e.t.c.)


> From the Product entity definition we have this explanation of the fields:
> "If you have a six-pack of 12oz soda cans you would have
> quantityIncluded=12, quantityUomId=oz, piecesIncluded=6"
>
> piecesIncluded is missing from ProductSupplier but I think the definition
> for quantityIncluded/unitsIncluded can stand without it.
>

As per my understanding the quantityIncluded defines the quantity included
in the respective quantityUomId and we do not need piecesIncluded here.

>> "If you have a six-pack of 12oz soda cans you would have
quantityIncluded=6 quantityUomId=pack"

As per my understanding, I think, "oz" is a weightUomId and this should be
managed at product level not at SupplierProduct. Please let me know your
thoughts on this.


> So I think what we can conclude from this detail is that these fields are
> informative and not functional, and they shouldn't have any bearing against
> other fields such as lastPrice.
>

Agreed!


> I think there could be room for making use of the fields, an example:
> Let's say you are a house painter and you need to order 12 litres of paint
> for a job.  The supplier has two products available, 2 litre tins @ $10 and
> 4 litre tins @ $15:
>  minimumOrderQuantity="1" orderQtyIncrements="1"/>
>  minimumOrderQuantity="1" orderQtyIncrements="1"/>
>
> So you tell your amazing OFBiz system that you'd like to order 12 liters of
> paint, OFBiz will then look at your SupplierProduct records and determine
> which record gives you the best price and fits within the supplier's
> purchasing rules (i.e. you can't order half a tin of paint). OFBiz
> ultimately puts the selection into OrderItem.supplierProductId and sets the
> unitPrice accordingly.  As a second function, OrderItem.supplierProductId
> can then also serve to correctly format the PO that the supplier receives
> so that instead of seeing:
> "Send me 12 litres of paint @ $3.75/litre please"
> they could instead see:
> "Send me 3 units of 4 litre paint @ $15/unit please"
> It wouldn't alter what we see in the OrderItem record, but it could be used
> for information the supplier receives and perhaps also for shipment receipt
> verification (if you wanted 4L tins and they sent you 2L tins, maybe that's
> an issue that needs to be dealt with).
>

It's a great use case, what I have concluded from this is,
We should use quantityUomId and quantityIncluded fields,
Just additional thought, if we use these fields then these fileds should be
the part of OrderItem entity as well. This will help in maintaining the
information at order item level.

Please correct me on this, if I understand anything incorrectly.


> I hope that helps.  I've made a few assumptions here so if anyone thinks
>

Indeed very helpful, thanks so much :)

I'm incorrect please speak up.
>
> Regards
> Scott
>
>
>
>
>
> On 9 August 2017 at 23:31, Vaibhav Jain 
> wrote:
>
> > Hello all,
> >
> > There are two fields, *quant**ityUomId* and *unitsIncluded* in
> > SupplierProduct entity.
> > Can someone please elaborate the use of these fields?
> >
> > After creating a record of SupplierProduct with *quantityUomId*="box" and
> > *unitsIncluded*="10", created a purchase order but didn't notice any
> > change.
> >
> > How are these fields entertained in the purchase order?
> >
> > Thanks & Regards
> > Vaibhav Jain
> > Hotwax Systems,
> > vaibhav.j...@hotwaxsystems.com
> >
>

Re: Keep deleteProductionRunRoutingTask?

[Vaibhav Jain]

Hello Jacques,

Just for easy reference

>>Please give your opinion on OFBIZ-9568
before I continue on
OFBIZ-9185 

Thanks & Regards

Vaibhav Jain
Hotwax Systems,
vaibhav.j...@hotwaxsystems.com

On Thu, Aug 10, 2017 at 3:26 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> Please give your opinion on OFBIZ-9568 before I continue on OFBIZ-9185
>
> Thanks
>
> Jacques
>
>

Re: Request for enhance entity:SystemProperty.

[Wai]

Sorry it took so long to reply. I was not notified by Nabble that anybody
responded.When I use the term "access", it is _not_ related to ofbiz
security. Perhaps I should have used a different term to describe these
fields.  I shall replace "access" with readWriteType.readWriteType means how
ofbiz treats the property when a user interacts with it.  Of course, only
users with the proper ofbiz authorization may access the properties. Some
properties are mean to be viewed and not modified (ie.
readWriteType=readOnly).  Some are hidden altogether (ie.
readWriteType=hidden).Example of a read only property field:An ofbiz owner
may subscribe to a third party service via oauth2 authentication.  This 3rd
party service is used by ofbiz to provide a functionality.  A user with
proper ofbiz authorization may modify the oauth2 authentication
parameters(ie. readWriteType=readWrite) and can also view the current oauth2
status (ie. readWriteType=readOnly). (Note: this is not related to ofbiz
passport component).In the case of readWriteType=hidden, lets define 2
terms. ofbizOwner and ofbizTenantOwner.  ofbizOwner is an entity that owns
an ofbiz system. Such an entity is responsible for installation, setup,
upgrades, database upgrades and tenant administrations. A ofbizInstanceOwner
is a tenant of an ofbiz system configured for multitenant mode of operation. 
A property with readWriteType=hidden is one which is administered by the
ofbizOwner and stored in the database of an ofbizTenantOwner and affects the
instance of that tenant.  As such, the ofbizTenantOwner cannot view nor edit
such a property.Hope this clear things up.



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-Request-for-enhance-entity-SystemProperty-tp4709235p4709445.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Request for enhance entity:SystemProperty.

[Wai]

There was also a second question for this posting.  It was whether another
entity should be created to address party specific properties.

Arun Patidar-2, made reference to entity:PartyAcctgPreference. I shall take
a look at that to see if that would meet my needs.

Thanks.



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-Request-for-enhance-entity-SystemProperty-tp4709235p4709446.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Request for enhance entity:SystemProperty.

[Wai]

Regarding the need for a user specific entity to store user specific
settings, the structure for entity:UserPreference looks like a good match
for what I need. Seeing that there is only one value defined for
userPrefGroupTypeId (ie. GLOBAL_PREFERENCES), I can define USER_PREFERENCES
for this field.

Thanks.



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-Request-for-enhance-entity-SystemProperty-tp4709235p4709448.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[Proposal] - Leverage the CMS capability for Product Store's Email

[Swapnil Mane]

Hello Devs,

While looking into the support of email templates for Product Store, we
found it is managed by screens.

Like for Order Completion



Here you can see, we are having dependency on screens (i.e. templates
defined in file system)
Due to this, the user is unable to edit the email template on the fly.

We can enhance this mechanism by making the template as content driven.
Here is the design plan,

We can extend the ProductStoreEmailSetting entity by contentId field.
While rendering email based on its type, if the contentId is present, this
content will render, else system will look for bodyScreenLocation (our
existing implementation)

Using this we can leverage the CMS capability of the OFBiz.
Right now if end user (client) wants to make any change in the email
template, it required the changes in the file.
If we manage this by content, the user can edit this on the fly with the
help of CMS.

All the inputs and suggestions are welcome!


- Best Regards,
Swapnil M Mane
www.hotwaxsystems.com
www.hotwax.co

Re: [Proposal] - Leverage the CMS capability for Product Store's Email

[Pierre Smits]

Hi Swapnil,

Great idea!

Best regards,


Pierre

On Fri, 11 Aug 2017 at 08:01 Swapnil Mane 
wrote:

> Hello Devs,
>
> While looking into the support of email templates for Product Store, we
> found it is managed by screens.
>
> Like for Order Completion
>
> 
> bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="ofbizt...@example.com"
> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
> #${orderId}"/>
>
> Here you can see, we are having dependency on screens (i.e. templates
> defined in file system)
> Due to this, the user is unable to edit the email template on the fly.
>
> We can enhance this mechanism by making the template as content driven.
> Here is the design plan,
>
> We can extend the ProductStoreEmailSetting entity by contentId field.
> While rendering email based on its type, if the contentId is present, this
> content will render, else system will look for bodyScreenLocation (our
> existing implementation)
>
> Using this we can leverage the CMS capability of the OFBiz.
> Right now if end user (client) wants to make any change in the email
> template, it required the changes in the file.
> If we manage this by content, the user can edit this on the fly with the
> help of CMS.
>
> All the inputs and suggestions are welcome!
>
>
> - Best Regards,
> Swapnil M Mane
> www.hotwaxsystems.com
> www.hotwax.co
>
-- 
Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: [Proposal] - Leverage the CMS capability for Product Store's Email

[Jacques Le Roux]

+1

Jacques


Le 11/08/2017 à 08:29, Pierre Smits a écrit :

Hi Swapnil,

Great idea!

Best regards,


Pierre

On Fri, 11 Aug 2017 at 08:01 Swapnil Mane 
wrote:


Hello Devs,

While looking into the support of email templates for Product Store, we
found it is managed by screens.

Like for Order Completion



Here you can see, we are having dependency on screens (i.e. templates
defined in file system)
Due to this, the user is unable to edit the email template on the fly.

We can enhance this mechanism by making the template as content driven.
Here is the design plan,

We can extend the ProductStoreEmailSetting entity by contentId field.
While rendering email based on its type, if the contentId is present, this
content will render, else system will look for bodyScreenLocation (our
existing implementation)

Using this we can leverage the CMS capability of the OFBiz.
Right now if end user (client) wants to make any change in the email
template, it required the changes in the file.
If we manage this by content, the user can edit this on the fly with the
help of CMS.

All the inputs and suggestions are welcome!


- Best Regards,
Swapnil M Mane
www.hotwaxsystems.com
www.hotwax.co

Re: Welcome Akash Jain as a New Committer!

[Akash Jain]

Thanks to all for the wonderful wishes!

Thanks and Regards
--
Akash Jain

On Wed, Aug 9, 2017 at 2:28 PM, Sharan Foga  wrote:

> The OFBiz PMC has invited Akash Jain to become a new committer and are
> happy to announce that he has accepted.
>
> Some of the key factors considered for inviting him were as follows:
>
> - He has been involved with the OFBiz project for quite a while which
> shows his dedication and commitment
> - He has a lot of good knowledge (both functional and technical) that he
> is happy to share which shows he is a good team player
> - He is very active, positive and respectful to others in the community
> - He has contributed patches and shows a willingness to learn which is
> really important as the project continues to go through changes
>
> Please join me in welcoming and congratulating Akash.
>
> Thanks
> Sharan
>

Re: Welcome Rishi Solanki as a New Committer!

[Akash Jain]

Many Congratulations Rishi!

Thanks and Regards
--
Akash Jain

On Wed, Aug 9, 2017 at 2:26 PM, Sharan Foga  wrote:

> The OFBiz PMC has invited Rishi Solanki to become a new committer and are
> happy to announce that he has accepted.
>
> Some of the key factors considered for inviting him were as follows:
>
> - He has been involved with the OFBiz project for quite a while which
> shows dedication and commitment
> - He has a lot of good knowledge that he is happy to share which shows he
> is a good team player
> - His work is consistent, has good code quality and he has provided a
> range of patches
> - He is friendly, respectful and keen to help out others in the community
>
> Please join me in welcoming and congratulating Rishi!
>
> Thanks
> Sharan
>