Re: [Proposal] Support for more decimals in price fields

[Vaibhav Jain]

+1 Taher

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

On Tue, Oct 3, 2017 at 1:09 PM, Deepak Dixit  wrote:

> Looks good Taher.
>
>
> On Sun, Oct 1, 2017 at 2:18 PM, Taher Alkhateeb <
> slidingfilame...@gmail.com>
> wrote:
>
> > So this is one area where I faced many problems in the past, with
> > units generally and money specifically. You could be surprised how
> > many times something like rounding and accuracy can end up being a
> > _big_ problem in systems.
> >
> > I think to really achieve flexibility (which is one of the strong
> > points of OFBiz) then we should have a general purpose accuracy
> > system. We can perhaps implement it as follows:
> > - Amount could be a free field with no restriction on accuracy (it
> > goes as far as the environment provides)
> > - Accuracy should be a parameter with a default value. However, the
> > parameter should be customizable to each unit of measurement
> > (currency) separately. So for example, you can set USD to 2, KWD to 3,
> > etc ...
> >
>
>
> https://www.currency-iso.org/en/home/tables/table-a1.html
>
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
>
>
>
>
> > - Rounding method should be a parameter with a default value. Examples
> > could be ROUND_UP, ROUND_DOWN, ROUND_NEAREST
> > - Rounding time should be a parameter with a default value. Perhaps
> > something like DURING_CALCULATION, AFTER_CALCULATION
> > - Then we implement all basic calculations in services or utility
> > methods that fully utilize the above parameters and settings.
> >
> > Sorry if I went overboard :) But I usually always lean towards root
> > solutions that solve many problems at once. Not sure if any folks are
> > interested but if you like the idea I'd be willing to help with it.
> >
> > On Wed, Sep 27, 2017 at 3:42 PM, Chinmay Patidar
> >  wrote:
> > > Hello Devs,
> > >
> > > Ofbiz places a restriction on saving more than 3 decimal places in
> price
> > > related entity-fields. But there can be a number of use cases where a
> > user
> > > needs to store more than 2 or 3 decimal places in the currency related
> > > entity-fields.
> > >
> > > I even saw some discussions related to this but didn't found any
> > > conclusions from them. Even one issue
> > >  has been created but
> > for
> > > limited fields. So, I would like to propose support for multiple or
> more
> > > than 2/3 decimals in price related fields.
> > >
> > > Following are some findings related to the currency fields which would
> be
> > > helpful to examine the requirement:
> > > Ofbiz uses two field types to store the currency related entity-fields.
> > > These two types are 'currency-amount' and 'currency-precise' with their
> > > respective types being NUMBER(18,2) and NUMBER(18,3).
> > >
> > > Upon initial research, one can conclude that changing the field
> > definitions
> > > of 'currency-amount' and 'currency-precise' would achieve the
> > requirement.
> > > But doing so will raise following questions which need to be answered.
> > Feel
> > > free to add in them.
> > >
> > >- What would be the precise value of precision(number of decimals)?
> > >- Will these changes can make the system inconsistent?
> > >
> > > In addition, I would like to know the significance of having two
> separate
> > > field types, i.e. 'currency-amount' and 'currency-precise'.
> > >
> > > Also, I have marked one improvement which will be needed to realize the
> > > solution. There are multiple occurrences where hardcoded scaling of 2
> has
> > > been set to either display or store a currency field. This needs to be
> > > changed and must be set dynamically.
> > >
> > > I'd like to hear your thoughts.
> > >
> > > Thanks,
> > > *Chinmay Patidar*
> >
>

Re: Make usage of EntitySyncRemove configurable

[Jacques Le Roux]

Hi Chandan,

Then indeed a new mechanism should be introduced to prevent

this.saveEntitySyncRemoveInfo(value.getPrimaryKey());

in GenericDelegator.removeValue()

It seems to me that this should be set in entityengine.xml by delegator. Or 
maybe even simpler with a general property.

Jacques


Le 03/10/2017 à 13:07, Chandan Khandelwal a écrit :

Hi Jacques,

cleanSyncRemoveInfo service will be used to clean/delete the
EntitySyncRemove records of specific time interval.

When any records are removed the primary key will be saved in the
EntitySyncRemove entity's for syncing purpose, I am talking about to not
create EntitySyncRemove records (disable the usage of ENTITY_SYNC*
entities) if not needed.

Re: Make usage of EntitySyncRemove configurable

[Chandan Khandelwal]

Hi Jacques,

cleanSyncRemoveInfo service will be used to clean/delete the
EntitySyncRemove records of specific time interval.

When any records are removed the primary key will be saved in the
EntitySyncRemove entity's for syncing purpose, I am talking about to not
create EntitySyncRemove records (disable the usage of ENTITY_SYNC*
entities) if not needed.


-- 
Thanks & Regards,
Chandan Khandelwal
HotWax Systems
Direct: +91-9893481076
http://www.hotwaxsystems.com/

On Tue, Oct 3, 2017 at 1:21 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Ah, actually EntitySyncRemove is automatically used by the "Clear
> EntitySyncRemove Info" job which uses cleanSyncRemoveInfo
>
> Maybe you only need to deactivate this job?
>
> Jacques
>
>
>
> Le 01/10/2017 à 10:51, Jacques Le Roux a écrit :
>
>> Hi Chandan,
>>
>> Could you give us more information please?
>>
>> In my mind EntitySyncRemove is only used on demand, but I could be wrong.
>>
>> Did you find that EntitySyncRemove is automatically synced from somewhere?
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 23/09/2017 à 08:20, Chandan Khandelwal a écrit :
>>
>>> Hello All,
>>>
>>> I have reviewed the code and usage of EntitySyncRemove and found there
>>> are
>>> no configurations available to disable usage of EntitySyncRemove.
>>>
>>> It is creating problems when having a large database and frequent delete
>>> operations.
>>>
>>> Please provide your inputs to make EntitySyncRemove configurable.
>>>
>>>
>>
>>
>

Re: [Site] OFBIZ-9665

[Aditya Sharma]

Interesting. Thanks Deepak for sharing that.

+1 for having target="external" at all places as consistency is key to good
user experience.

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Tue, Oct 3, 2017 at 2:00 PM, Devanshu Vyas 
wrote:

> Thanks Deepak, I looked for similar info, but was unable to find. And in
> the meantime, got to know about the Rel attribute, so I thought the
> intended code was rel rather than target='external'.
> Now, with the new information at hand, I think target="_blank" or
> target="external" both are correct. All we need to decide is whether to
> open all links in separate tabs everytime link is clicked or just once.
>
> I think we should open all external links with target="external". WDYAS?
>
> Thanks & Regards,
> Devanshu Vyas.
>
> On Tue, Oct 3, 2017 at 1:58 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Ha thanks Deepak,
> >
> > This is interesting (and surprising), so we should change ALL
> > target="_blank" to target="external" rather for consistency sake
> >
> > If everybody agree I will do so
> >
> > Jacques
> >
> >
> >
> > Le 03/10/2017 à 10:18, Deepak Dixit a écrit :
> >
> >> Hi Devanshu,
> >>
> >> I think target="external" is correct.
> >>
> >> https://www.quackit.com/html/codes/html_open_link_in_new_window.cfm
> >>
> >> {info}
> >> Instead of calling your window _blank, you can give it a name of your
> >> choosing. Then all URLs will load in that same tab (as long as you use
> the
> >> same name).
> >>
> >> For example, if you have a policy of loading all external links in a
> >> separate tab, you could call that tab, say, external. Then each link
> that
> >> contains target="external" will open in that window/tab. Doing this
> >> ensures
> >> that new windows aren't going to be popping up every time a user clicks
> on
> >> a link.
> >>
> >> {info}
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Dixit
> >> www.hotwaxsystems.com
> >> www.hotwax.co
> >>
> >> On Tue, Oct 3, 2017 at 1:40 PM, Devanshu Vyas <
> vyas.devansh...@gmail.com>
> >> wrote:
> >>
> >> Hello,
> >>>
> >>> I agree with Jacques and Aditya, we should set all external links with
> >>> target="_blank". I have also mentioned the same on the JIRA ticket
> >>> .
> >>> I think the intended use is rel="external", which was somehow written
> as
> >>> target="external", refer: https://www.w3schools.com/Tags/att_a_rel.asp
> >>>
> >>> Hope this helps!
> >>>
> >>> Thanks & Regards,
> >>> Devanshu Vyas.
> >>>
> >>> On Tue, Oct 3, 2017 at 12:18 PM, Taher Alkhateeb <
> >>> slidingfilame...@gmail.com
> >>>
>  wrote:
>  AFAIK "_blank" is the only acceptable target in HTML 5 because frames
>  are deprecated. The website is modern and built on an HTML 5 template.
>  Hence every target should be "_blank"
> 
>  On Tue, Oct 3, 2017 at 9:42 AM, Jacques Le Roux
>   wrote:
> 
> > Hi,
> >
> > Aditya and I want to change all "external" targets to "_blank" but
> are
> > unsure of the reason of "external" targets
> >
> > Could someone please confirm it's not an issue and maybe explain why
> we
> >
>  have
> 
> > "external" targets
> >
> > Thanks
> >
> > Jacques
> >
> >
> >
>

Re: [Site] OFBIZ-9665

[Devanshu Vyas]

Thanks Deepak, I looked for similar info, but was unable to find. And in
the meantime, got to know about the Rel attribute, so I thought the
intended code was rel rather than target='external'.
Now, with the new information at hand, I think target="_blank" or
target="external" both are correct. All we need to decide is whether to
open all links in separate tabs everytime link is clicked or just once.

I think we should open all external links with target="external". WDYAS?

Thanks & Regards,
Devanshu Vyas.

On Tue, Oct 3, 2017 at 1:58 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Ha thanks Deepak,
>
> This is interesting (and surprising), so we should change ALL
> target="_blank" to target="external" rather for consistency sake
>
> If everybody agree I will do so
>
> Jacques
>
>
>
> Le 03/10/2017 à 10:18, Deepak Dixit a écrit :
>
>> Hi Devanshu,
>>
>> I think target="external" is correct.
>>
>> https://www.quackit.com/html/codes/html_open_link_in_new_window.cfm
>>
>> {info}
>> Instead of calling your window _blank, you can give it a name of your
>> choosing. Then all URLs will load in that same tab (as long as you use the
>> same name).
>>
>> For example, if you have a policy of loading all external links in a
>> separate tab, you could call that tab, say, external. Then each link that
>> contains target="external" will open in that window/tab. Doing this
>> ensures
>> that new windows aren't going to be popping up every time a user clicks on
>> a link.
>>
>> {info}
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Tue, Oct 3, 2017 at 1:40 PM, Devanshu Vyas 
>> wrote:
>>
>> Hello,
>>>
>>> I agree with Jacques and Aditya, we should set all external links with
>>> target="_blank". I have also mentioned the same on the JIRA ticket
>>> .
>>> I think the intended use is rel="external", which was somehow written as
>>> target="external", refer: https://www.w3schools.com/Tags/att_a_rel.asp
>>>
>>> Hope this helps!
>>>
>>> Thanks & Regards,
>>> Devanshu Vyas.
>>>
>>> On Tue, Oct 3, 2017 at 12:18 PM, Taher Alkhateeb <
>>> slidingfilame...@gmail.com
>>>
 wrote:
 AFAIK "_blank" is the only acceptable target in HTML 5 because frames
 are deprecated. The website is modern and built on an HTML 5 template.
 Hence every target should be "_blank"

 On Tue, Oct 3, 2017 at 9:42 AM, Jacques Le Roux
  wrote:

> Hi,
>
> Aditya and I want to change all "external" targets to "_blank" but are
> unsure of the reason of "external" targets
>
> Could someone please confirm it's not an issue and maybe explain why we
>
 have

> "external" targets
>
> Thanks
>
> Jacques
>
>
>

Re: [Site] OFBIZ-9665

[Jacques Le Roux]

Ha thanks Deepak,

This is interesting (and surprising), so we should change ALL target="_blank" to 
target="external" rather for consistency sake

If everybody agree I will do so

Jacques


Le 03/10/2017 à 10:18, Deepak Dixit a écrit :

Hi Devanshu,

I think target="external" is correct.

https://www.quackit.com/html/codes/html_open_link_in_new_window.cfm

{info}
Instead of calling your window _blank, you can give it a name of your
choosing. Then all URLs will load in that same tab (as long as you use the
same name).

For example, if you have a policy of loading all external links in a
separate tab, you could call that tab, say, external. Then each link that
contains target="external" will open in that window/tab. Doing this ensures
that new windows aren't going to be popping up every time a user clicks on
a link.

{info}

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Tue, Oct 3, 2017 at 1:40 PM, Devanshu Vyas 
wrote:


Hello,

I agree with Jacques and Aditya, we should set all external links with
target="_blank". I have also mentioned the same on the JIRA ticket
.
I think the intended use is rel="external", which was somehow written as
target="external", refer: https://www.w3schools.com/Tags/att_a_rel.asp

Hope this helps!

Thanks & Regards,
Devanshu Vyas.

On Tue, Oct 3, 2017 at 12:18 PM, Taher Alkhateeb <
slidingfilame...@gmail.com

wrote:
AFAIK "_blank" is the only acceptable target in HTML 5 because frames
are deprecated. The website is modern and built on an HTML 5 template.
Hence every target should be "_blank"

On Tue, Oct 3, 2017 at 9:42 AM, Jacques Le Roux
 wrote:

Hi,

Aditya and I want to change all "external" targets to "_blank" but are
unsure of the reason of "external" targets

Could someone please confirm it's not an issue and maybe explain why we

have

"external" targets

Thanks

Jacques

Re: [Site] OFBIZ-9665

[Deepak Dixit]

Hi Devanshu,

I think target="external" is correct.

https://www.quackit.com/html/codes/html_open_link_in_new_window.cfm

{info}
Instead of calling your window _blank, you can give it a name of your
choosing. Then all URLs will load in that same tab (as long as you use the
same name).

For example, if you have a policy of loading all external links in a
separate tab, you could call that tab, say, external. Then each link that
contains target="external" will open in that window/tab. Doing this ensures
that new windows aren't going to be popping up every time a user clicks on
a link.

{info}

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Tue, Oct 3, 2017 at 1:40 PM, Devanshu Vyas 
wrote:

> Hello,
>
> I agree with Jacques and Aditya, we should set all external links with
> target="_blank". I have also mentioned the same on the JIRA ticket
> .
> I think the intended use is rel="external", which was somehow written as
> target="external", refer: https://www.w3schools.com/Tags/att_a_rel.asp
>
> Hope this helps!
>
> Thanks & Regards,
> Devanshu Vyas.
>
> On Tue, Oct 3, 2017 at 12:18 PM, Taher Alkhateeb <
> slidingfilame...@gmail.com
> > wrote:
>
> > AFAIK "_blank" is the only acceptable target in HTML 5 because frames
> > are deprecated. The website is modern and built on an HTML 5 template.
> > Hence every target should be "_blank"
> >
> > On Tue, Oct 3, 2017 at 9:42 AM, Jacques Le Roux
> >  wrote:
> > > Hi,
> > >
> > > Aditya and I want to change all "external" targets to "_blank" but are
> > > unsure of the reason of "external" targets
> > >
> > > Could someone please confirm it's not an issue and maybe explain why we
> > have
> > > "external" targets
> > >
> > > Thanks
> > >
> > > Jacques
> > >
> >
>

Re: [Site] OFBIZ-9665

[Jacques Le Roux]

Thanks Devanshu,

It clarifies it all :)

I'll change to rel="external" and add target="_blank"

Jacques


Le 03/10/2017 à 10:10, Devanshu Vyas a écrit :

Hello,

I agree with Jacques and Aditya, we should set all external links with
target="_blank". I have also mentioned the same on the JIRA ticket
.
I think the intended use is rel="external", which was somehow written as
target="external", refer: https://www.w3schools.com/Tags/att_a_rel.asp

Hope this helps!

Thanks & Regards,
Devanshu Vyas.

On Tue, Oct 3, 2017 at 12:18 PM, Taher Alkhateeb 
wrote:
AFAIK "_blank" is the only acceptable target in HTML 5 because frames
are deprecated. The website is modern and built on an HTML 5 template.
Hence every target should be "_blank"

On Tue, Oct 3, 2017 at 9:42 AM, Jacques Le Roux
 wrote:

Hi,

Aditya and I want to change all "external" targets to "_blank" but are
unsure of the reason of "external" targets

Could someone please confirm it's not an issue and maybe explain why we

have

"external" targets

Thanks

Jacques

Re: [Site] OFBIZ-9665

[Devanshu Vyas]

Hello,

I agree with Jacques and Aditya, we should set all external links with
target="_blank". I have also mentioned the same on the JIRA ticket
.
I think the intended use is rel="external", which was somehow written as
target="external", refer: https://www.w3schools.com/Tags/att_a_rel.asp

Hope this helps!

Thanks & Regards,
Devanshu Vyas.

On Tue, Oct 3, 2017 at 12:18 PM, Taher Alkhateeb  wrote:

> AFAIK "_blank" is the only acceptable target in HTML 5 because frames
> are deprecated. The website is modern and built on an HTML 5 template.
> Hence every target should be "_blank"
>
> On Tue, Oct 3, 2017 at 9:42 AM, Jacques Le Roux
>  wrote:
> > Hi,
> >
> > Aditya and I want to change all "external" targets to "_blank" but are
> > unsure of the reason of "external" targets
> >
> > Could someone please confirm it's not an issue and maybe explain why we
> have
> > "external" targets
> >
> > Thanks
> >
> > Jacques
> >
>

Re: Make usage of EntitySyncRemove configurable

[Jacques Le Roux]

Ah, actually EntitySyncRemove is automatically used by the "Clear EntitySyncRemove 
Info" job which uses cleanSyncRemoveInfo

Maybe you only need to deactivate this job?

Jacques


Le 01/10/2017 à 10:51, Jacques Le Roux a écrit :

Hi Chandan,

Could you give us more information please?

In my mind EntitySyncRemove is only used on demand, but I could be wrong.

Did you find that EntitySyncRemove is automatically synced from somewhere?

Thanks

Jacques


Le 23/09/2017 à 08:20, Chandan Khandelwal a écrit :

Hello All,

I have reviewed the code and usage of EntitySyncRemove and found there are
no configurations available to disable usage of EntitySyncRemove.

It is creating problems when having a large database and frequent delete
operations.

Please provide your inputs to make EntitySyncRemove configurable.

Re: [Proposal] Support for more decimals in price fields

[Deepak Dixit]

Looks good Taher.


On Sun, Oct 1, 2017 at 2:18 PM, Taher Alkhateeb 
wrote:

> So this is one area where I faced many problems in the past, with
> units generally and money specifically. You could be surprised how
> many times something like rounding and accuracy can end up being a
> _big_ problem in systems.
>
> I think to really achieve flexibility (which is one of the strong
> points of OFBiz) then we should have a general purpose accuracy
> system. We can perhaps implement it as follows:
> - Amount could be a free field with no restriction on accuracy (it
> goes as far as the environment provides)
> - Accuracy should be a parameter with a default value. However, the
> parameter should be customizable to each unit of measurement
> (currency) separately. So for example, you can set USD to 2, KWD to 3,
> etc ...
>


https://www.currency-iso.org/en/home/tables/table-a1.html



Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co





> - Rounding method should be a parameter with a default value. Examples
> could be ROUND_UP, ROUND_DOWN, ROUND_NEAREST
> - Rounding time should be a parameter with a default value. Perhaps
> something like DURING_CALCULATION, AFTER_CALCULATION
> - Then we implement all basic calculations in services or utility
> methods that fully utilize the above parameters and settings.
>
> Sorry if I went overboard :) But I usually always lean towards root
> solutions that solve many problems at once. Not sure if any folks are
> interested but if you like the idea I'd be willing to help with it.
>
> On Wed, Sep 27, 2017 at 3:42 PM, Chinmay Patidar
>  wrote:
> > Hello Devs,
> >
> > Ofbiz places a restriction on saving more than 3 decimal places in price
> > related entity-fields. But there can be a number of use cases where a
> user
> > needs to store more than 2 or 3 decimal places in the currency related
> > entity-fields.
> >
> > I even saw some discussions related to this but didn't found any
> > conclusions from them. Even one issue
> >  has been created but
> for
> > limited fields. So, I would like to propose support for multiple or more
> > than 2/3 decimals in price related fields.
> >
> > Following are some findings related to the currency fields which would be
> > helpful to examine the requirement:
> > Ofbiz uses two field types to store the currency related entity-fields.
> > These two types are 'currency-amount' and 'currency-precise' with their
> > respective types being NUMBER(18,2) and NUMBER(18,3).
> >
> > Upon initial research, one can conclude that changing the field
> definitions
> > of 'currency-amount' and 'currency-precise' would achieve the
> requirement.
> > But doing so will raise following questions which need to be answered.
> Feel
> > free to add in them.
> >
> >- What would be the precise value of precision(number of decimals)?
> >- Will these changes can make the system inconsistent?
> >
> > In addition, I would like to know the significance of having two separate
> > field types, i.e. 'currency-amount' and 'currency-precise'.
> >
> > Also, I have marked one improvement which will be needed to realize the
> > solution. There are multiple occurrences where hardcoded scaling of 2 has
> > been set to either display or store a currency field. This needs to be
> > changed and must be set dynamically.
> >
> > I'd like to hear your thoughts.
> >
> > Thanks,
> > *Chinmay Patidar*
>