date:20160922


Hi,

I suggest we include the "Groovy Style guide" http://www.groovy-lang.org/style-guide.html at 
https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions


It's not about formatting, I did not find anything on Groovy formatting in a 
quick research, but is still interesting.

Jacques

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]


Le 22/09/2016 à 18:06, Michael Brohl a écrit :

Hi Rupert, Jacques, all,

if I search Google for it, I find many different opinions. For example, here is a viarant from the Git documentation 
http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;h=ece3c77482b3ff006b973f1ed90b708e26556862;hb=HEAD


Just to add that it's why I suggested to use verbs variations, like do GitHub. 
To allow users to use the one they prefer, but



"the body should provide a meaningful commit message, which:
- uses the imperative, present tense: "change", not "changed" or "changes"."

All in all, we simply want to achieve something UNIFIED and Jacques is still 
the only one objecting to use the proposed format. Noone else did.

But if we can't agree on past/present or whatever tense, I have a different 
proposal which might be acceptable by all and end this stupid discussion:

What if we state what this issue is or covers: a Bug, an Improvement, a 
Documentation etc.?

The template then would look like:

===

[Implementation|Improvement|Bug|Task|Documentation|Revert]: [Jira title|Free 
text]
[(OFBIZ-)]

[More detailed explanation of what has been done and what the fix achieves,
sideeffects etc.]

[Thanks:] [ for ... and  for]

===

I would be happy to change to this format if we can all agree to use the same 
without exceptions.


Revert then should be Reversion: 
http://www.etymonline.com/index.php?term=reversion

Jacques



I really wish to end this and appreciate your benevolent consideration.

Thanks,

Michael


Am 22.09.16 um 17:21 schrieb Rupert Howell:

Hi yes, reading with interest, I agree with Jacques.
Commit messages should be Present Tense Imperative, Imperative Style.
There's plenty of links on Google as to why this is the widely adopted
industry standard.

On 22 September 2016 at 16:06, Jacques Le Roux  wrote:

Done


Jacques


Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :

Hi,


In some cases we need to revert a commit done for a Jira after we
discover it causes an issue. We have not yet other means that using
the fix
word.
I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as
it
please you) word in the commit template for this reason.
Because it's a different thing than really fixing the

Re: getNextSeqId and multiple sequence on entity


It seems this has never be implement, any reasons?

Thanks

Jacques


Le 01/04/2010 à 15:52, Brett Palmer a écrit :

Nicolas,

Thanks I'll take a look at it.

Brett

On Thu, Apr 1, 2010 at 6:48 AM, Nicolas Malin  wrote:




After some reflection on this subject, I arrive to :
getNextSeqId is use normaly to get an single id that identify an
entity : Invoice.invoiceId, Order.orderId, Party.partyId etc ...
It's easier to remove the problematic instruction but bypasses
getNextSeqId purpose.

For multiple sequence on Entity I suggest to create new function on
delegator : getNextSequence (String entityName, String diff, long
staggerMax) that manage sequence as getNextSeqId but analyse just the
validity of entityName and generate sequenceValueId : entityName.diff.

As this, Delegator continue to work only on entity and not use for other
not in relation with entitymodel.

For sequence not in relation with entity, I can extend sequenceUtil to
have a function SequenceUtil.getNextSequence(String key, long
staggerMax).

Brett can you give me an example for your proposal ? I don't really
understand your improvement.

If you wait to read, Have a nice end year ;)
Nicolas


Le mercredi 23 décembre 2009 à 13:49 -0700, Brett Palmer a écrit :
  > I confirmed that if you use the delegator.getNextSeqId() you will get
an



exception every time it is used with a complaint that an entity doesn't
exist for the sequence you requested.  It does give still generate an ID



but



the exception is a little concerning when you are running in a
production
environment.  This exception probably isn't intended but is a
consequence



of



the call to look for the entity name.

I would prefer we just outputted a warning log and not threw an



exception.



Another request for the sequence generator is the ability to specify the



gap



between the next sequence ID update.  This can be configured in the



entity



engine but only for those IDs that have a corresponding entity.  If you



try



to use a generic sequencer with no attached entity the default is 10



which



can be low for a production environment with multiple servers.  Could we



add



a column to the SequenceValueItem to include

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]


Hi Jinghai,

Yes you are right, something we should remember. I'll try...

Jacques


Le 23/09/2016 à 03:04, Shi Jinghai a écrit :

Ha, English, my favorite part. When I was 10, I learned my first 2 sentences of 
English:
1. Long life Chairman Mao!
2. Good morning comrade ... Gray

We are a worldwide community, please keep communication as simple as possible.

Good morning comrade everybody,

Shi Jinghai

-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2016年9月22日 23:07
收件人: dev@ofbiz.apache.org
主题: Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit 
template?]

Scott,

Reading your message I guess you did not read my previous explanation on why I 
prefer to use present instead of past. You may find more details in digging in 
previous emails.

But long story short, I'm French so I can't compete in English with someone 
like you for who English is the mother tongue.

The reason I use present is because I got this habit while working with Rupert 
Howell. You know, the guy who wrote the first OFBiz book. I don't reveal 
anything saying he is from Southampton (at least he lives there). I was then 
used to use past also in commit messages. A habit I got while seeing others 
committing in OFBiz. But when I saw Rupert  using present, it immediately made 
sense to me: at the moment you commit, you are doing an action. So I should use 
present, I'm doing the commit, it's not yet done.

I don't know if Rupert will read or appreciate this message, but it's the truth!

Anyway I believe it's a moot point, and we should have the freedom to write as 
we prefer, like it's done in a successful project like GitHub...

Jacques


Le 22/09/2016 à 14:52, Scott Gray a écrit :

I can't believe you're being so stubborn about something so minor
Jacques, it seems like very strange behavior to me.  For what it's
worth as a native English speaker, reading a commit message written in
present-tense feels very strange to me.  I'm looking at a history and
reading something as though it is current, it doesn't feel logical.

Regards
Scott

On 22 September 2016 at 19:36, Jacques Le Roux
 wrote:

Done

Jacques


Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :

Hi,

In some cases we need to revert a commit done for a Jira after we
discover it causes an issue. We have not yet other means that
using the fix word.
I suggest we put in the "Reverts" (or "Revert for" or "Reverted"
as it please you) word in the commit template for this reason.
Because it's a different thing than really fixing the initial
issue reported in the Jira but it's sill related to it

What do you think?

Jacques

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]

2016-09-22 Thread Shi Jinghai

Ha, English, my favorite part. When I was 10, I learned my first 2 sentences of 
English:
1. Long life Chairman Mao!
2. Good morning comrade ... Gray

We are a worldwide community, please keep communication as simple as possible.

Good morning comrade everybody,

Shi Jinghai

-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 
发送时间: 2016年9月22日 23:07
收件人: dev@ofbiz.apache.org
主题: Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit 
template?]

Scott,

Reading your message I guess you did not read my previous explanation on why I 
prefer to use present instead of past. You may find more details in digging in 
previous emails.

But long story short, I'm French so I can't compete in English with someone 
like you for who English is the mother tongue.

The reason I use present is because I got this habit while working with Rupert 
Howell. You know, the guy who wrote the first OFBiz book. I don't reveal 
anything saying he is from Southampton (at least he lives there). I was then 
used to use past also in commit messages. A habit I got while seeing others 
committing in OFBiz. But when I saw Rupert  using present, it immediately made 
sense to me: at the moment you commit, you are doing an action. So I should use 
present, I'm doing the commit, it's not yet done.

I don't know if Rupert will read or appreciate this message, but it's the truth!

Anyway I believe it's a moot point, and we should have the freedom to write as 
we prefer, like it's done in a successful project like GitHub...

Jacques

Le 22/09/2016 à 14:52, Scott Gray a écrit :
> I can't believe you're being so stubborn about something so minor 
> Jacques, it seems like very strange behavior to me.  For what it's 
> worth as a native English speaker, reading a commit message written in 
> present-tense feels very strange to me.  I'm looking at a history and 
> reading something as though it is current, it doesn't feel logical.
>
> Regards
> Scott
>
> On 22 September 2016 at 19:36, Jacques Le Roux 
> > wrote:
>> Jacopo,
>>
>> I saw you answered on Confluence where I 1st asked 
>> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+
>> commit+message+template?focusedCommentId=65871637#comment-65871637
>>
>> Now, I understand that we need to pick a word, but why not being more 
>> flexible, similarly at what does GitHub 
>> https://help.github.com/articl es/closing-issues-via-commit-messages/ ?
>>
>> I already suggested in previous threads that I could help if the 
>> process Michael uses to create the blog monthly report needs to be adapted.
>> In relation, I also created in the "Wiki page for the "monthly Jira 
>> issues list" creation in the blog" thread, without any answers so far 
>> :/
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 22/09/2016 à 08:45, Jacques Le Roux a écrit :
>>
>>> Hi Jacopo,
>>>
>>> What is the logical behind this? It's not the first time I ask and 
>>> I'd really like to have a clarification.
>>>
>>> We have "Fix for" and "Documentation". Why not "Fixed" and "Documented"?
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> Le 21/09/2016 à 19:09, Jacopo Cappellato a écrit :
>>>
 I have changed it to "Reverted" for consistency reasons.

 Jacopo

 On Wed, Sep 21, 2016 at 7:01 PM, Jacques Le Roux < 
 jacques.le.r...@les7arts.com> wrote:

 Done
> Jacques
>
>
> Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :
>
> Hi,
>> In some cases we need to revert a commit done for a Jira after we 
>> discover it causes an issue. We have not yet other means that 
>> using the fix word.
>> I suggest we put in the "Reverts" (or "Revert for" or "Reverted" 
>> as it please you) word in the commit template for this reason.
>> Because it's a different thing than really fixing the initial 
>> issue reported in the Jira but it's sill related to it
>>
>> What do you think?
>>
>> Jacques
>>
>>
>>
>>
>>>

Re: Use ecomseo on demo rather than ecommerce

Well for me it's a -1 until I hear some positive reviews from other users
(and ideally committers).  I don't like having two ecommerce webapps and my
preference would be to merge the two into one, but I can't promote that
idea without any group consensus that the SEO approach is good and well
architected.  A document describing the architecture would make that much
easier and I'm amazed one wasn't supplied with the proposal, no wonder it
sat there without much attention for so long.  But since one doesn't exist
we'll just have to wait until people have time/care to review it and/or use
it and provide feedback.

Regards
Scott

On 23 September 2016 at 00:07, Jacques Le Roux  wrote:

> https://issues.apache.org/jira/browse/OFBIZ-5312
>
> More at https://issues.apache.org/jira/browse/OFBIZ-2214?jql=project
> %20%3D%20OFBIZ%20AND%20text%20~%20%22seo%22
>
> Jacques
>
>
>
> Le 22/09/2016 à 13:25, Scott Gray a écrit :
>
>> By the way, is there any technical or user documentation for it?  I
>> haven't
>> looked at it and don't have time to review the actual implementation right
>> now.  The link you provided doesn't offer much more than a sales pitch.
>>
>> Regards
>> Scott
>>
>> On 22 September 2016 at 23:22, Scott Gray 
>> wrote:
>>
>> This mostly to somehow battle test it, even if I know it works well
>>>
>>>
>>> So does it need battle testing or does it work well?  Have you deployed
>>> it
>>> to any production instances?  Has anyone else?
>>>
>>> Regards
>>> Scott
>>>
>>> On 19 September 2016 at 01:27, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> Hi,

 Maybe you don't know about or did not try it, but we have ecomseo a
 clone
 of the ecommerce component tailored for SEO

 https://cwiki.apache.org/confluence/display/OFBIZ/Search+Eng
 ine+Optimisation,+SEO+in+ecommerce

 I propose to use it as the default ecommerce demo. This mostly to
 somehow
 battle test it, even if I know it works well.

 As it's based on ecommerce, users should not experience a big changes,
 apart the changed URLs

 What do you think?

 Jacques

>

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml


Thanks a lot Jacques for this sentence

Nicolas


Le 22/09/2016 à 17:55, Jacques Le Roux a écrit :
Now I'm thinking: there is a reason why people think <>.


So I will add a small sentence saying to look before for a possible 
FormFieldTitle_ in the autocompletion help (widget-form.xsd)


Jacques


Le 22/09/2016 à 14:22, Jacques Le Roux a écrit :
Thanks for the reminder Nicolas, since nobody opposes I reverted at 
revision: 1761923


Jacques


Le 22/09/2016 à 13:36, Nicolas Malin a écrit :
I see no  improvement to use a dedicate title as same the 
FormFieldTitle.


More a form is light, more is readable and maintainable. Yes I'm 
lazy, and it's good for my healthy :)


If we change or improve the engine for the label, all specific use 
would be manage direclty.


On the other way, if you want surcharge the label, you can do on 
your component, or/and surcharge the form with the specific label.


Nicolas


Le 21/09/2016 à 17:45, Jacques Le Roux a écrit :
I'm not against reverting myself. Doing so it also means that 
everybody agree about continuing to use the FormFieldTitle_ feature


So if you really don't like it and have arguments, it's the moment 
to raise your hand. Before I revert in, say 2 days, and put this 
discussion back in the limbo


Jacques


Le 21/09/2016 à 16:04, Michael Brohl a écrit :

Jacques,

please take care of the revert, this will keep the commit history 
cleaner.


Thanks,

Michael


Am 21.09.16 um 14:04 schrieb Jacques Le Roux:
I'm not against reverting it, it's a moot point to me. Please 
help yourselves (Michael or Taher. Or maybe Christian? :D)


Jacques


Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit :
I suggest also to revert. If we want to apply such a change in 
the future
then we must take a decision to stop using 
convention-over-configuration
for _all_ widget fields. And if we do not want to use that 
convention then

we should remove the related code accordingly.

On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl 


wrote:


I'd suggest to revert this commit.

Thanks,

Michael

Am 21.09.16 um 09:47 schrieb gil portenseigne:


Hi Jacques,

Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kindof improvements. Adding a title 
when and
FormFieldTitle_XXX properties exists is not good in my opinion 
(i did not

check these ones).


Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :


Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687=rev
Log:
Improves: Maximise the utilisation of common labels in various
applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. 
Often these

field
definitions have led to unique label definitions, where a shared
(common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could 
be used)
* the various Type fields (where for most label CommonType 
could be used)


This is a placeholder ticket, intended to capture applicable 
issues as

sub tasks
   to address the aspect of maximising the utilisation of 
labels in the

CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: 
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
myportal/widget/PortalAdmForms.xml?rev=1761687
=1761686=1761687=diff

==
--- 
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

(original)
+++ 
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml 
Wed

Sep 21 07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
   
   title="${uiLabelMap.CommonName

}">
   position="2">
ld>
-
+title="${uiLabelMap.CommonDesc

ription}">
   
   title="${uiLabelMap.CommonFind}"
widget-style="smallSubmit">button-type="button"/>

   
@@ -88,8 +88,8 @@ under the License.
   
   
   position="2">

-
-size="60"/>
+title="${uiLabelMap.CommonName

}">
+title="${uiLabelMap.CommonDescription}"

position="2">

Re: Formatting in *.gradle files


This seems basically done with r1761998, not much was actually needed

Jacques

Le 22/09/2016 à 19:04, Jacques Le Roux a écrit :

Hi,

This is mostly for Taher but concern all of us.

I noticed several times that we don't always format *.gradle files following 
the Java Code Conventions we follow for the rest (ie *.java and *.groovy)

https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions

We should use the same for *.gradle file. I think we can easily infer how to indent new idioms following "old" Java else we can add 
http://www.groovy-lang.org/style-guide.html


Jacques

Re: Formatting in *.gradle files


In Eclipse, after checking the Minimalist Gradle Editor, The Gradle Build 
Script editor and the Groovy Editor have no formatting options,
I tried to automatically format common.gradle (which is actually well 
formatted) using the Java editor and the result is worse (less legible)

Index: common.gradle
===
--- common.gradle(revision 1761976)
+++ common.gradle(working copy)
@@ -33,14 +33,8 @@
 applyFunction 
file("${rootDir}/specialpurpose/"+component.@"component-location")
 }

-file("${rootDir}/themes").eachDir { component ->
-applyFunction(component)
-}
-file("${rootDir}/hot-deploy").eachDir { component ->
-applyFunction(component)
-}
+file("${rootDir}/themes").eachDir { component -> applyFunction(component) }
+file("${rootDir}/hot-deploy").eachDir { component -> 
applyFunction(component) }
 }

-ext{
-iterateOverActiveComponents = this.
-}
\ No newline at end of file
+ext{ iterateOverActiveComponents = this. }

===

So we need to do it by hand, and wait for an hypothetical formatter 
https://stackoverflow.com/questions/23273098/formatting-build-gradle-automatically

Fortunately the main build.gradle seems mostly well formatted :)

Jacques


Le 22/09/2016 à 19:04, Jacques Le Roux a écrit :

Hi,

This is mostly for Taher but concern all of us.

I noticed several times that we don't always format *.gradle files following 
the Java Code Conventions we follow for the rest (ie *.java and *.groovy)

https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions

We should use the same for *.gradle file. I think we can easily infer how to indent new idioms following "old" Java else we can add 
http://www.groovy-lang.org/style-guide.html


Jacques

Re: About our LICENSE and NOTICE requirements


After reading this page and what it tells about "/only bundled bits matter."/ I 
trust we can remove all the lines which concern *.jar files

Then it will easier to think about the other bits and we will need to keep 
lines like

framework/images/webapp/images/date/timezones/*
framework/resources/fonts/NotoSans/*

If no lines remain for a specific license then the license text itself can be 
removed.

Using these simple rules will help to greatly reduce OFBiz LICENSE files

I'm yet unsure about the NOTICE files

HTH

Jacques

Le 22/09/2016 à 21:02, Jacopo Cappellato a écrit :

Hi all,

after carefully reading the Apache licensing howto [*], my understanding is
that our LICENSE and NOTICE files must be drastically simplified because,
since we are no more bundling the external dependencies, these shall not be
included in them.
Please read the document referenced below (it is a short one) and confirm
if my undersatnding is correct; then we can proceed with the editing.

Thank you,

Jacopo

[*]
http://www.apache.org/dev/licensing-howto.html

Re: About our LICENSE and NOTICE requirements

2016-09-22 Thread Taher Alkhateeb

+1 .. thank you for the research

On Sep 22, 2016 10:35 PM, "Michael Brohl"  wrote:

> Jacopo,
>
> I agree, seems to be clearly stated:
>
> "LICENSE and NOTICE must always be tailored to the content of the specific
> distribution they reside within. Dependencies which are not included in the
> distribution MUST NOT be added to LICENSE and NOTICE. As far as LICENSE and
> NOTICE are concerned, only bundled bits matter."
>
> Cheers,
>
> Michael
>
>
> Am 22.09.16 um 21:02 schrieb Jacopo Cappellato:
>
>> Hi all,
>>
>> after carefully reading the Apache licensing howto [*], my understanding
>> is
>> that our LICENSE and NOTICE files must be drastically simplified because,
>> since we are no more bundling the external dependencies, these shall not
>> be
>> included in them.
>> Please read the document referenced below (it is a short one) and confirm
>> if my undersatnding is correct; then we can proceed with the editing.
>>
>> Thank you,
>>
>> Jacopo
>>
>> [*]
>> http://www.apache.org/dev/licensing-howto.html
>>
>>
>
>

Re: About our LICENSE and NOTICE requirements

2016-09-22 Thread Michael Brohl


Jacopo,

I agree, seems to be clearly stated:

"LICENSE and NOTICE must always be tailored to the content of the 
specific distribution they reside within. Dependencies which are not 
included in the distribution MUST NOT be added to LICENSE and NOTICE. As 
far as LICENSE and NOTICE are concerned, only bundled bits matter."


Cheers,

Michael


Am 22.09.16 um 21:02 schrieb Jacopo Cappellato:

Hi all,

after carefully reading the Apache licensing howto [*], my understanding is
that our LICENSE and NOTICE files must be drastically simplified because,
since we are no more bundling the external dependencies, these shall not be
included in them.
Please read the document referenced below (it is a short one) and confirm
if my undersatnding is correct; then we can proceed with the editing.

Thank you,

Jacopo

[*]
http://www.apache.org/dev/licensing-howto.html






smime.p7s
Description: S/MIME Cryptographic Signature

About our LICENSE and NOTICE requirements

Hi all,

after carefully reading the Apache licensing howto [*], my understanding is
that our LICENSE and NOTICE files must be drastically simplified because,
since we are no more bundling the external dependencies, these shall not be
included in them.
Please read the document referenced below (it is a short one) and confirm
if my undersatnding is correct; then we can proceed with the editing.

Thank you,

Jacopo

[*]
http://www.apache.org/dev/licensing-howto.html

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]

On Thu, Sep 22, 2016 at 5:21 PM, Rupert Howell 
wrote:

> Hi yes, reading with interest, I agree with Jacques.
> Commit messages should be Present Tense Imperative, Imperative Style.
>

well, now I am a bit confused because Jacques is using Present Tense in
Third Person ("fixes") and not the Imperative Style ("fix")... but now I am
walking on the thin ice since English is not my mother tongue! From what I
understand the "present tense imperative" is the suggested style for Git
repositories... and this reminds me that we should start talking about
migrating from Svn to Git :-)

Jacopo

PS: Welcome back Rupert!

Formatting in *.gradle files


Hi,

This is mostly for Taher but concern all of us.

I noticed several times that we don't always format *.gradle files following 
the Java Code Conventions we follow for the rest (ie *.java and *.groovy)

https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions

We should use the same for *.gradle file. I think we can easily infer how to indent new idioms following "old" Java else we can add 
http://www.groovy-lang.org/style-guide.html


Jacques

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]


Michael,

Thanks for calling the conversation stupid, you could have refrained on this :/

For the rest I'm done, I tried to put a bit more of flexibility in this template, but since nobody cares (apart Rupert, thanks!), let it be. Now you 
ALL must comply...


-0  (minus zero)

Jacques


Le 22/09/2016 à 18:06, Michael Brohl a écrit :

Hi Rupert, Jacques, all,

if I search Google for it, I find many different opinions. For example, here is a viarant from the Git documentation 
http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;h=ece3c77482b3ff006b973f1ed90b708e26556862;hb=HEAD


"the body should provide a meaningful commit message, which:
- uses the imperative, present tense: "change", not "changed" or "changes"."

All in all, we simply want to achieve something UNIFIED and Jacques is still 
the only one objecting to use the proposed format. Noone else did.

But if we can't agree on past/present or whatever tense, I have a different 
proposal which might be acceptable by all and end this stupid discussion:

What if we state what this issue is or covers: a Bug, an Improvement, a 
Documentation etc.?

The template then would look like:

===

[Implementation|Improvement|Bug|Task|Documentation|Revert]: [Jira title|Free 
text]
[(OFBIZ-)]

[More detailed explanation of what has been done and what the fix achieves,
sideeffects etc.]

[Thanks:] [ for ... and  for]

===

I would be happy to change to this format if we can all agree to use the same 
without exceptions.

I really wish to end this and appreciate your benevolent consideration.

Thanks,

Michael


Am 22.09.16 um 17:21 schrieb Rupert Howell:

Hi yes, reading with interest, I agree with Jacques.
Commit messages should be Present Tense Imperative, Imperative Style.
There's plenty of links on Google as to why this is the widely adopted
industry standard.

On 22 September 2016 at 16:06, Jacques Le Roux  wrote:

Done


Jacques


Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :

Hi,


In some cases we need to revert a commit done for a Jira after we
discover it causes an issue. We have not yet other means that using
the fix
word.
I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as
it
please you) word in the commit template for this

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]

2016-09-22 Thread Michael Brohl


Hi Rupert, Jacques, all,

if I search Google for it, I find many different opinions. For example, 
here is a viarant from the Git documentation 
http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;h=ece3c77482b3ff006b973f1ed90b708e26556862;hb=HEAD


"the body should provide a meaningful commit message, which:
- uses the imperative, present tense: "change", not "changed" or "changes"."

All in all, we simply want to achieve something UNIFIED and Jacques is 
still the only one objecting to use the proposed format. Noone else did.


But if we can't agree on past/present or whatever tense, I have a 
different proposal which might be acceptable by all and end this stupid 
discussion:


What if we state what this issue is or covers: a Bug, an Improvement, a 
Documentation etc.?


The template then would look like:

===

[Implementation|Improvement|Bug|Task|Documentation|Revert]: [Jira title|Free 
text]
[(OFBIZ-)]

[More detailed explanation of what has been done and what the fix achieves,
sideeffects etc.]

[Thanks:] [ for ... and  for]

===

I would be happy to change to this format if we can all agree to use the 
same without exceptions.


I really wish to end this and appreciate your benevolent consideration.

Thanks,

Michael


Am 22.09.16 um 17:21 schrieb Rupert Howell:

Hi yes, reading with interest, I agree with Jacques.
Commit messages should be Present Tense Imperative, Imperative Style.
There's plenty of links on Google as to why this is the widely adopted
industry standard.

On 22 September 2016 at 16:06, Jacques Le Roux  wrote:

Done


Jacques


Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :

Hi,


In some cases we need to revert a commit done for a Jira after we
discover it causes an issue. We have not yet other means that using
the fix
word.
I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as
it
please you) word in the commit template for this reason.
Because it's a different thing than really fixing the initial issue
reported in the Jira but it's sill related to it

What do you think?

Jacques












smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml


Now I'm thinking: there is a reason why people think <>.

So I will add a small sentence saying to look before for a possible 
FormFieldTitle_ in the autocompletion help (widget-form.xsd)

Jacques


Le 22/09/2016 à 14:22, Jacques Le Roux a écrit :

Thanks for the reminder Nicolas, since nobody opposes I reverted at revision: 
1761923

Jacques


Le 22/09/2016 à 13:36, Nicolas Malin a écrit :

I see no  improvement to use a dedicate title as same the FormFieldTitle.

More a form is light, more is readable and maintainable. Yes I'm lazy, and it's 
good for my healthy :)

If we change or improve the engine for the label, all specific use would be 
manage direclty.

On the other way, if you want surcharge the label, you can do on your 
component, or/and surcharge the form with the specific label.

Nicolas


Le 21/09/2016 à 17:45, Jacques Le Roux a écrit :

I'm not against reverting myself. Doing so it also means that everybody agree 
about continuing to use the FormFieldTitle_ feature

So if you really don't like it and have arguments, it's the moment to raise your hand. Before I revert in, say 2 days, and put this discussion 
back in the limbo


Jacques


Le 21/09/2016 à 16:04, Michael Brohl a écrit :

Jacques,

please take care of the revert, this will keep the commit history cleaner.

Thanks,

Michael


Am 21.09.16 um 14:04 schrieb Jacques Le Roux:

I'm not against reverting it, it's a moot point to me. Please help yourselves 
(Michael or Taher. Or maybe Christian? :D)

Jacques


Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit :

I suggest also to revert. If we want to apply such a change in the future
then we must take a decision to stop using convention-over-configuration
for _all_ widget fields. And if we do not want to use that convention then
we should remove the related code accordingly.

On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl 
wrote:


I'd suggest to revert this commit.

Thanks,

Michael

Am 21.09.16 um 09:47 schrieb gil portenseigne:


Hi Jacques,

Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kindof improvements. Adding a title when and
FormFieldTitle_XXX properties exists is not good in my opinion (i did not
check these ones).


Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :


Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687=rev
Log:
Improves: Maximise the utilisation of common labels in various
applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these
field
definitions have led to unique label definitions, where a shared
(common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as
sub tasks
   to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
myportal/widget/PortalAdmForms.xml?rev=1761687
=1761686=1761687=diff

==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
(original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed
Sep 21 07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
   
   
   
-
+
   
   
   
@@ -88,8 +88,8 @@ under the License.
   
   
   
-
-
+
+

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]

2016-09-22 Thread Rupert Howell

Hi yes, reading with interest, I agree with Jacques.
Commit messages should be Present Tense Imperative, Imperative Style.
There's plenty of links on Google as to why this is the widely adopted
industry standard.

On 22 September 2016 at 16:06, Jacques Le Roux  wrote:

> Scott,
>
> Reading your message I guess you did not read my previous explanation on
> why I prefer to use present instead of past. You may find more details in
> digging in previous emails.
>
> But long story short, I'm French so I can't compete in English with
> someone like you for who English is the mother tongue.
>
> The reason I use present is because I got this habit while working with
> Rupert Howell. You know, the guy who wrote the first OFBiz book. I don't
> reveal anything saying he is from Southampton (at least he lives there). I
> was then used to use past also in commit messages. A habit I got while
> seeing others committing in OFBiz. But when I saw Rupert  using present, it
> immediately made sense to me: at the moment you commit, you are doing an
> action. So I should use present, I'm doing the commit, it's not yet done.
>
> I don't know if Rupert will read or appreciate this message, but it's the
> truth!
>
> Anyway I believe it's a moot point, and we should have the freedom to
> write as we prefer, like it's done in a successful project like GitHub...
>
> Jacques
>
>
> Le 22/09/2016 à 14:52, Scott Gray a écrit :
>
>> I can't believe you're being so stubborn about something so minor Jacques,
>> it seems like very strange behavior to me.  For what it's worth as a
>> native
>> English speaker, reading a commit message written in present-tense feels
>> very strange to me.  I'm looking at a history and reading something as
>> though it is current, it doesn't feel logical.
>>
>> Regards
>> Scott
>>
>> On 22 September 2016 at 19:36, Jacques Le Roux <
>> jacques.le.r...@les7arts.com
>>
>>> wrote:
>>> Jacopo,
>>>
>>> I saw you answered on Confluence where I 1st asked
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+
>>> commit+message+template?focusedCommentId=65871637#comment-65871637
>>>
>>> Now, I understand that we need to pick a word, but why not being more
>>> flexible, similarly at what does GitHub https://help.github.com/articl
>>> es/closing-issues-via-commit-messages/ ?
>>>
>>> I already suggested in previous threads that I could help if the process
>>> Michael uses to create the blog monthly report needs to be adapted.
>>> In relation, I also created in the "Wiki page for the "monthly Jira
>>> issues
>>> list" creation in the blog" thread, without any answers so far :/
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>> Le 22/09/2016 à 08:45, Jacques Le Roux a écrit :
>>>
>>> Hi Jacopo,

 What is the logical behind this? It's not the first time I ask and I'd
 really like to have a clarification.

 We have "Fix for" and "Documentation". Why not "Fixed" and "Documented"?

 Thanks

 Jacques

 Le 21/09/2016 à 19:09, Jacopo Cappellato a écrit :

 I have changed it to "Reverted" for consistency reasons.
>
> Jacopo
>
>
>
> On Wed, Sep 21, 2016 at 7:01 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> Done
>
>> Jacques
>>
>>
>> Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :
>>
>> Hi,
>>
>>> In some cases we need to revert a commit done for a Jira after we
>>> discover it causes an issue. We have not yet other means that using
>>> the fix
>>> word.
>>> I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as
>>> it
>>> please you) word in the commit template for this reason.
>>> Because it's a different thing than really fixing the initial issue
>>> reported in the Jira but it's sill related to it
>>>
>>> What do you think?
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>>

>


-- 
Rupert Howell

Provolve Ltd
Front Office, Deale House, 16 Lavant Street, Petersfield, GU32 3EW, UK

t: 01730 267868 / m: 079 0968 5308
e:  ruperthow...@provolve.com
w: http://www.provolve.com

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]

Scott,

Reading your message I guess you did not read my previous explanation on why I prefer to use present instead of past. You may find more details in
digging in previous emails.

But long story short, I'm French so I can't compete in English with someone
like you for who English is the mother tongue.

The reason I use present is because I got this habit while working with Rupert Howell. You know, the guy who wrote the first OFBiz book. I don't
reveal anything saying he is from Southampton (at least he lives there). I was then used to use past also in commit messages. A habit I got while
seeing others committing in OFBiz. But when I saw Rupert using present, it immediately made sense to me: at the moment you commit, you are doing an
action. So I should use present, I'm doing the commit, it's not yet done.

I don't know if Rupert will read or appreciate this message, but it's the truth!

Anyway I believe it's a moot point, and we should have the freedom to write as
we prefer, like it's done in a successful project like GitHub...

Jacques

Le 22/09/2016 à 14:52, Scott Gray a écrit :

I can't believe you're being so stubborn about something so minor Jacques,
it seems like very strange behavior to me. For what it's worth as a native
English speaker, reading a commit message written in present-tense feels
very strange to me. I'm looking at a history and reading something as
though it is current, it doesn't feel logical.

Regards
Scott

On 22 September 2016 at 19:36, Jacques Le Roux wrote:

Done

Jacques

Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :

Hi,

In some cases we need to revert a commit done for a Jira after we
discover it causes an issue. We have not yet other means that using
the fix
word.
I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it
please you) word in the commit template for this reason.
Because it's a different thing than really fixing the initial issue
reported in the Jira but it's sill related to it

What do you think?

Jacques

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]

I can't believe you're being so stubborn about something so minor Jacques,
it seems like very strange behavior to me.  For what it's worth as a native
English speaker, reading a commit message written in present-tense feels
very strange to me.  I'm looking at a history and reading something as
though it is current, it doesn't feel logical.

Regards
Scott

On 22 September 2016 at 19:36, Jacques Le Roux  wrote:

> Jacopo,
>
> I saw you answered on Confluence where I 1st asked
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+
> commit+message+template?focusedCommentId=65871637#comment-65871637
>
> Now, I understand that we need to pick a word, but why not being more
> flexible, similarly at what does GitHub https://help.github.com/articl
> es/closing-issues-via-commit-messages/ ?
>
> I already suggested in previous threads that I could help if the process
> Michael uses to create the blog monthly report needs to be adapted.
> In relation, I also created in the "Wiki page for the "monthly Jira issues
> list" creation in the blog" thread, without any answers so far :/
>
> Thanks
>
> Jacques
>
>
> Le 22/09/2016 à 08:45, Jacques Le Roux a écrit :
>
>> Hi Jacopo,
>>
>> What is the logical behind this? It's not the first time I ask and I'd
>> really like to have a clarification.
>>
>> We have "Fix for" and "Documentation". Why not "Fixed" and "Documented"?
>>
>> Thanks
>>
>> Jacques
>>
>> Le 21/09/2016 à 19:09, Jacopo Cappellato a écrit :
>>
>>> I have changed it to "Reverted" for consistency reasons.
>>>
>>> Jacopo
>>>
>>>
>>>
>>> On Wed, Sep 21, 2016 at 7:01 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> Done

 Jacques


 Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :

 Hi,
>
> In some cases we need to revert a commit done for a Jira after we
> discover it causes an issue. We have not yet other means that using
> the fix
> word.
> I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it
> please you) word in the commit template for this reason.
> Because it's a different thing than really fixing the initial issue
> reported in the Jira but it's sill related to it
>
> What do you think?
>
> Jacques
>
>
>
>
>>
>>
>

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml


Thanks for the reminder Nicolas, since nobody opposes I reverted at revision: 
1761923

Jacques


Le 22/09/2016 à 13:36, Nicolas Malin a écrit :

I see no  improvement to use a dedicate title as same the FormFieldTitle.

More a form is light, more is readable and maintainable. Yes I'm lazy, and it's 
good for my healthy :)

If we change or improve the engine for the label, all specific use would be 
manage direclty.

On the other way, if you want surcharge the label, you can do on your 
component, or/and surcharge the form with the specific label.

Nicolas


Le 21/09/2016 à 17:45, Jacques Le Roux a écrit :

I'm not against reverting myself. Doing so it also means that everybody agree 
about continuing to use the FormFieldTitle_ feature

So if you really don't like it and have arguments, it's the moment to raise your hand. Before I revert in, say 2 days, and put this discussion back 
in the limbo


Jacques


Le 21/09/2016 à 16:04, Michael Brohl a écrit :

Jacques,

please take care of the revert, this will keep the commit history cleaner.

Thanks,

Michael


Am 21.09.16 um 14:04 schrieb Jacques Le Roux:

I'm not against reverting it, it's a moot point to me. Please help yourselves 
(Michael or Taher. Or maybe Christian? :D)

Jacques


Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit :

I suggest also to revert. If we want to apply such a change in the future
then we must take a decision to stop using convention-over-configuration
for _all_ widget fields. And if we do not want to use that convention then
we should remove the related code accordingly.

On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl 
wrote:


I'd suggest to revert this commit.

Thanks,

Michael

Am 21.09.16 um 09:47 schrieb gil portenseigne:


Hi Jacques,

Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kindof improvements. Adding a title when and
FormFieldTitle_XXX properties exists is not good in my opinion (i did not
check these ones).


Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :


Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687=rev
Log:
Improves: Maximise the utilisation of common labels in various
applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these
field
definitions have led to unique label definitions, where a shared
(common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as
sub tasks
   to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
myportal/widget/PortalAdmForms.xml?rev=1761687
=1761686=1761687=diff

==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
(original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed
Sep 21 07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
   
   
   
-
+
   
   
   
@@ -88,8 +88,8 @@ under the License.
   
   
   
-
-
+
+

Re: Use ecomseo on demo rather than ecommerce


https://issues.apache.org/jira/browse/OFBIZ-5312

More at 
https://issues.apache.org/jira/browse/OFBIZ-2214?jql=project%20%3D%20OFBIZ%20AND%20text%20~%20%22seo%22

Jacques


Le 22/09/2016 à 13:25, Scott Gray a écrit :

By the way, is there any technical or user documentation for it?  I haven't
looked at it and don't have time to review the actual implementation right
now.  The link you provided doesn't offer much more than a sales pitch.

Regards
Scott

On 22 September 2016 at 23:22, Scott Gray 
wrote:


This mostly to somehow battle test it, even if I know it works well


So does it need battle testing or does it work well?  Have you deployed it
to any production instances?  Has anyone else?

Regards
Scott

On 19 September 2016 at 01:27, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

Maybe you don't know about or did not try it, but we have ecomseo a clone
of the ecommerce component tailored for SEO

https://cwiki.apache.org/confluence/display/OFBIZ/Search+Eng
ine+Optimisation,+SEO+in+ecommerce

I propose to use it as the default ecommerce demo. This mostly to somehow
battle test it, even if I know it works well.

As it's based on ecommerce, users should not experience a big changes,
apart the changed URLs

What do you think?

Jacques

Re: Use ecomseo on demo rather than ecommerce


Le 22/09/2016 à 13:22, Scott Gray a écrit :

This mostly to somehow battle test it, even if I know it works well

So does it need battle testing or does it work well?

It works well for me.

Have you deployed it to any production instances?

Not directly, that's why I want it as default OFBiz demo

Has anyone else?

At least
https://www.buchhandel.de/
https://oem.ofbizci.net/oci-2
I guess you can find more starting from  OFBIZ-5312

Jacques



Regards
Scott

On 19 September 2016 at 01:27, Jacques Le Roux

Re: svn commit: r1761111 - /ofbiz/trunk/specialpurpose/scrum/widget/

2016-09-22 Thread Amardeep Singh Jhajj

Here is the jira ticket- https://issues.apache.org/jira/browse/OFBIZ-8318

Thanks,
--
Amardeep Singh Jhajj

On Thu, Sep 22, 2016 at 5:22 PM, Michael Brohl 
wrote:

> Hi Amardeep,
>
> thank you very much for reporting!
>
> Would you mind creating a Jira, I'll fix it this evening.
>
> Thanks,
>
> Michael
>
>
> Am 22.09.16 um 13:24 schrieb Amardeep Singh Jhajj:
>
>> Hi Michael,
>>
>> Scrum main page is not working. Getting error:
>>
>> org.xml.sax.SAXParseException; systemId: file:/sandbox/ofbiz/specialpur
>> pose/scrum/widget/scrumScreens.xml; lineNumber: 2342; columnNumber: 107;
>> Open quote is expected for attribute "name" associated with an element
>> type
>> "include-form".
>>
>> One of the quote is missing in included form name -
>> ListSprintMemberNoAction
>>
>> Regards
>> --
>> Amardeep Singh Jhajj
>>
>>
>> On Sat, Sep 17, 2016 at 4:15 AM,  wrote:
>>
>> Author: mbrohl
>>> Date: Fri Sep 16 22:45:08 2016
>>> New Revision: 176
>>>
>>> URL: http://svn.apache.org/viewvc?rev=176=rev
>>> Log:
>>> Improved: Scrum: Consistent form name.
>>> (OFBIZ-8108)
>>>
>>> Change all form names to upper camel case for consistency.
>>>
>>> Thanks: Tanmay Muley for reporting and providing the patch.
>>>
>>> Modified:
>>>  ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/LookupScreens.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/MyWorkScreens.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/OpenTestForms.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/OpenTestScreens.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/ProjectForms.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/TaskForms.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/TaskScreens.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/scrumForms.xml
>>>  ofbiz/trunk/specialpurpose/scrum/widget/scrumScreens.xml
>>>
>>> Modified: ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventFo
>>> rms.xml
>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/scru
>>> m/widget/CommunicationEventForms.xml?rev=176=1761110&
>>> r2=176=diff
>>> 
>>> ==
>>> --- ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
>>> (original)
>>> +++ ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
>>> Fri Sep 16 22:45:08 2016
>>> @@ -85,7 +85,7 @@ under the License.
>>>   >> type="date"/>
>>>   
>>>   
>>> ->> target="uploadAttachFiletoEmail?productId=${parameters.produ
>>> ctId}custRequestId=${parameters.custRequestId}">
>>> +>> target="uploadAttachFiletoEmail?productId=${parameters.produ
>>> ctId}custRequestId=${parameters.custRequestId}">
>>>   >> value="${parameters.custReques
>>> tId}"/>
>>>   
>>>   
>>> @@ -116,7 +116,7 @@ under the License.
>>>   (document.uploadContent.submit())"/>
>>>   
>>>   
>>> ->> list-name="contentDataResourceList" paginate-target="/ListCommContent"
>>> target="removeAttachFile"
>>> +>> list-name="contentDataResourceList" paginate-target="/ListCommContent"
>>> target="removeAttachFile"
>>>   odd-row-style="alternate-row" default-table-style="basic-table
>>> hover-bar">
>>>   
>>>   >> list="contentDataResourceList">
>>> @@ -188,7 +188,7 @@ under the License.
>>>   >> disabled="true"/> 
>>>   >> read-only="true"/> 
>>>   
>>> ->> extends="listCommContent" list-name="contentDataResourceList"
>>> paginate-target="/ListCommContent" target="removeAttachFileForProduct"
>>> +>> extends="ListCommContent" list-name="contentDataResourceList"
>>> paginate-target="/ListCommContent" target="removeAttachFileForProduct"
>>>   odd-row-style="alternate-row" default-table-style="basic-table
>>> hover-bar">
>>>
>>>
>>> @@ -201,7 +201,7 @@ under the License.
>>>   
>>>   
>>>   
>>> ->> extends="uploadContent" target="uploadAttachFiletoEmai
>>> lForProduct?productId=${parameters.productId}">
>>> +>> extends="UploadContent" target="uploadAttachFiletoEmai
>>> lForProduct?productId=${parameters.productId}">
>>>
>>>   
>>>   
>>> 
>>>
>>> Modified: ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/scru
>>> m/widget/FieldLookupForms.xml?rev=176=1761110=1761
>>> 111=diff
>>> 
>>> ==
>>> --- ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
>>> (original)
>>> +++ ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml Fri Sep
>>> 16 22:45:08 2016
>>> @@ -21,7 +21,7 @@ under the License.
>>>

Re: svn commit: r1761111 - /ofbiz/trunk/specialpurpose/scrum/widget/

2016-09-22 Thread Michael Brohl


Hi Amardeep,

thank you very much for reporting!

Would you mind creating a Jira, I'll fix it this evening.

Thanks,

Michael


Am 22.09.16 um 13:24 schrieb Amardeep Singh Jhajj:

Hi Michael,

Scrum main page is not working. Getting error:

org.xml.sax.SAXParseException; systemId: file:/sandbox/ofbiz/specialpur
pose/scrum/widget/scrumScreens.xml; lineNumber: 2342; columnNumber: 107;
Open quote is expected for attribute "name" associated with an element type
"include-form".

One of the quote is missing in included form name - ListSprintMemberNoAction

Regards
--
Amardeep Singh Jhajj


On Sat, Sep 17, 2016 at 4:15 AM,  wrote:


Author: mbrohl
Date: Fri Sep 16 22:45:08 2016
New Revision: 176

URL: http://svn.apache.org/viewvc?rev=176=rev
Log:
Improved: Scrum: Consistent form name.
(OFBIZ-8108)

Change all form names to upper camel case for consistency.

Thanks: Tanmay Muley for reporting and providing the patch.

Modified:
 ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
 ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
 ofbiz/trunk/specialpurpose/scrum/widget/LookupScreens.xml
 ofbiz/trunk/specialpurpose/scrum/widget/MyWorkScreens.xml
 ofbiz/trunk/specialpurpose/scrum/widget/OpenTestForms.xml
 ofbiz/trunk/specialpurpose/scrum/widget/OpenTestScreens.xml
 ofbiz/trunk/specialpurpose/scrum/widget/ProjectForms.xml
 ofbiz/trunk/specialpurpose/scrum/widget/TaskForms.xml
 ofbiz/trunk/specialpurpose/scrum/widget/TaskScreens.xml
 ofbiz/trunk/specialpurpose/scrum/widget/scrumForms.xml
 ofbiz/trunk/specialpurpose/scrum/widget/scrumScreens.xml

Modified: ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventFo
rms.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/scru
m/widget/CommunicationEventForms.xml?rev=176=1761110&
r2=176=diff

==
--- ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
(original)
+++ ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
Fri Sep 16 22:45:08 2016
@@ -85,7 +85,7 @@ under the License.
  
  
  
-
+
  
  
  
@@ -116,7 +116,7 @@ under the License.
  (document.uploadContent.submit())"/>
  
  
-
  
  
@@ -188,7 +188,7 @@ under the License.
   
   
  
-
   
   
@@ -201,7 +201,7 @@ under the License.
  
  
  
-
+
   
  
  


Modified: ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/scru
m/widget/FieldLookupForms.xml?rev=176=1761110=176=diff

==
--- ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
(original)
+++ ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml Fri Sep
16 22:45:08 2016
@@ -21,7 +21,7 @@ under the License.
  http://www.w3.org/2001/XMLSchema-instance;
  xmlns="http://ofbiz.apache.org/Widget-Form; xsi:schemaLocation="
http://ofbiz.apache.org/Widget-Form http://ofbiz.apache.org/dtds/w
idget-form.xsd">

-
  
  
@@ -38,7 +38,7 @@ under the License.
  
  
  
-
  
  

Modified: ofbiz/trunk/specialpurpose/scrum/widget/LookupScreens.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/scru
m/widget/LookupScreens.xml?rev=176=1761110=176=diff

==
--- ofbiz/trunk/specialpurpose/scrum/widget/LookupScreens.xml (original)
+++ ofbiz/trunk/specialpurpose/scrum/widget/LookupScreens.xml Fri Sep 16
22:45:08 2016
@@ -40,10 +40,10 @@ under the License.
  
  
  
-
+
  
  
-
+
  
  
  

Modified: ofbiz/trunk/specialpurpose/scrum/widget/MyWorkScreens.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/scru
m/widget/MyWorkScreens.xml?rev=176=1761110=176=diff

==
--- ofbiz/trunk/specialpurpose/scrum/widget/MyWorkScreens.xml (original)
+++ ofbiz/trunk/specialpurpose/scrum/widget/MyWorkScreens.xml Fri Sep 16
22:45:08 2016
@@ -58,7 +58,7 @@ under the License.
  
  
  
-
+

Re: Apache POI 3.15 released

+1, the only one reason to don't update a extern lib is le 
testIntegration failure


Nicolas


Le 22/09/2016 à 06:42, Taher Alkhateeb a écrit :

+1 always to update to stable new releases

On Thu, Sep 22, 2016 at 2:22 AM, Michael Brohl 
wrote:


Hi everyone,

Apache POI 3.15 is released, we are currently using 3.14.

Should we do an update?

I'd create a Jira and do this work.

What do you think?

Regards,

Michael


Am 22.09.16 um 00:32 schrieb David North:


The Apache POI PMC are pleased to announce the release of Apache POI 3.15.

For details of changes in this release, refer to the release notes:

https://www.apache.org/dyn/closer.lua/poi/release/RELEASE-NOTES.txt

Thank you to all our contributors for making this release possible.

Some of us will be at ApacheCon Europe in Seville later in the year; do
find us there if you have input and suggestions.

On behalf of the Apache POI PMC,

David North

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml


I see no  improvement to use a dedicate title as same the FormFieldTitle.

More a form is light, more is readable and maintainable. Yes I'm lazy, 
and it's good for my healthy :)


If we change or improve the engine for the label, all specific use would 
be manage direclty.


On the other way, if you want surcharge the label, you can do on your 
component, or/and surcharge the form with the specific label.


Nicolas


Le 21/09/2016 à 17:45, Jacques Le Roux a écrit :
I'm not against reverting myself. Doing so it also means that 
everybody agree about continuing to use the FormFieldTitle_ feature


So if you really don't like it and have arguments, it's the moment to 
raise your hand. Before I revert in, say 2 days, and put this 
discussion back in the limbo


Jacques


Le 21/09/2016 à 16:04, Michael Brohl a écrit :

Jacques,

please take care of the revert, this will keep the commit history 
cleaner.


Thanks,

Michael


Am 21.09.16 um 14:04 schrieb Jacques Le Roux:
I'm not against reverting it, it's a moot point to me. Please help 
yourselves (Michael or Taher. Or maybe Christian? :D)


Jacques


Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit :
I suggest also to revert. If we want to apply such a change in the 
future
then we must take a decision to stop using 
convention-over-configuration
for _all_ widget fields. And if we do not want to use that 
convention then

we should remove the related code accordingly.

On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl 


wrote:


I'd suggest to revert this commit.

Thanks,

Michael

Am 21.09.16 um 09:47 schrieb gil portenseigne:


Hi Jacques,

Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kindof improvements. Adding a title 
when and
FormFieldTitle_XXX properties exists is not good in my opinion (i 
did not

check these ones).


Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :


Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687=rev
Log:
Improves: Maximise the utilisation of common labels in various
applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. 
Often these

field
definitions have led to unique label definitions, where a shared
(common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be 
used)
* the various Type fields (where for most label CommonType could 
be used)


This is a placeholder ticket, intended to capture applicable 
issues as

sub tasks
   to address the aspect of maximising the utilisation of labels 
in the

CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: 
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
myportal/widget/PortalAdmForms.xml?rev=1761687
=1761686=1761687=diff

==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
(original)
+++ 
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed

Sep 21 07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
   
   title="${uiLabelMap.CommonName

}">
   position="2">
ld>
-
+
   
   title="${uiLabelMap.CommonFind}"

widget-style="smallSubmit">
   
@@ -88,8 +88,8 @@ under the License.
   
   
   position="2">

-
-size="60"/>
+title="${uiLabelMap.CommonName

}">
+title="${uiLabelMap.CommonDescription}"

position="2">

Re: Use ecomseo on demo rather than ecommerce

By the way, is there any technical or user documentation for it?  I haven't
looked at it and don't have time to review the actual implementation right
now.  The link you provided doesn't offer much more than a sales pitch.

Regards
Scott

On 22 September 2016 at 23:22, Scott Gray 
wrote:

> This mostly to somehow battle test it, even if I know it works well
>
>
> So does it need battle testing or does it work well?  Have you deployed it
> to any production instances?  Has anyone else?
>
> Regards
> Scott
>
> On 19 September 2016 at 01:27, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Hi,
>>
>> Maybe you don't know about or did not try it, but we have ecomseo a clone
>> of the ecommerce component tailored for SEO
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Search+Eng
>> ine+Optimisation,+SEO+in+ecommerce
>>
>> I propose to use it as the default ecommerce demo. This mostly to somehow
>> battle test it, even if I know it works well.
>>
>> As it's based on ecommerce, users should not experience a big changes,
>> apart the changed URLs
>>
>> What do you think?
>>
>> Jacques
>>
>>
>

Re: svn commit: r1761111 - /ofbiz/trunk/specialpurpose/scrum/widget/

2016-09-22 Thread Amardeep Singh Jhajj

Hi Michael,

Scrum main page is not working. Getting error:

org.xml.sax.SAXParseException; systemId: file:/sandbox/ofbiz/specialpur
pose/scrum/widget/scrumScreens.xml; lineNumber: 2342; columnNumber: 107;
Open quote is expected for attribute "name" associated with an element type
"include-form".

One of the quote is missing in included form name - ListSprintMemberNoAction

Regards
--
Amardeep Singh Jhajj


On Sat, Sep 17, 2016 at 4:15 AM,  wrote:

> Author: mbrohl
> Date: Fri Sep 16 22:45:08 2016
> New Revision: 176
>
> URL: http://svn.apache.org/viewvc?rev=176=rev
> Log:
> Improved: Scrum: Consistent form name.
> (OFBIZ-8108)
>
> Change all form names to upper camel case for consistency.
>
> Thanks: Tanmay Muley for reporting and providing the patch.
>
> Modified:
> ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
> ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
> ofbiz/trunk/specialpurpose/scrum/widget/LookupScreens.xml
> ofbiz/trunk/specialpurpose/scrum/widget/MyWorkScreens.xml
> ofbiz/trunk/specialpurpose/scrum/widget/OpenTestForms.xml
> ofbiz/trunk/specialpurpose/scrum/widget/OpenTestScreens.xml
> ofbiz/trunk/specialpurpose/scrum/widget/ProjectForms.xml
> ofbiz/trunk/specialpurpose/scrum/widget/TaskForms.xml
> ofbiz/trunk/specialpurpose/scrum/widget/TaskScreens.xml
> ofbiz/trunk/specialpurpose/scrum/widget/scrumForms.xml
> ofbiz/trunk/specialpurpose/scrum/widget/scrumScreens.xml
>
> Modified: ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventFo
> rms.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/scru
> m/widget/CommunicationEventForms.xml?rev=176=1761110&
> r2=176=diff
> 
> ==
> --- ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
> (original)
> +++ ofbiz/trunk/specialpurpose/scrum/widget/CommunicationEventForms.xml
> Fri Sep 16 22:45:08 2016
> @@ -85,7 +85,7 @@ under the License.
>   type="date"/>
>  
>  
> - target="uploadAttachFiletoEmail?productId=${parameters.produ
> ctId}custRequestId=${parameters.custRequestId}">
> + target="uploadAttachFiletoEmail?productId=${parameters.produ
> ctId}custRequestId=${parameters.custRequestId}">
>  
>  
>  
> @@ -116,7 +116,7 @@ under the License.
>  (document.uploadContent.submit())"/>
>  
>  
> - list-name="contentDataResourceList" paginate-target="/ListCommContent"
> target="removeAttachFile"
> + list-name="contentDataResourceList" paginate-target="/ListCommContent"
> target="removeAttachFile"
>  odd-row-style="alternate-row" default-table-style="basic-table
> hover-bar">
>  
>   list="contentDataResourceList">
> @@ -188,7 +188,7 @@ under the License.
>   disabled="true"/> 
>   read-only="true"/> 
>  
> - extends="listCommContent" list-name="contentDataResourceList"
> paginate-target="/ListCommContent" target="removeAttachFileForProduct"
> + extends="ListCommContent" list-name="contentDataResourceList"
> paginate-target="/ListCommContent" target="removeAttachFileForProduct"
>  odd-row-style="alternate-row" default-table-style="basic-table
> hover-bar">
>   
>   
> @@ -201,7 +201,7 @@ under the License.
>  
>  
>  
> - extends="uploadContent" target="uploadAttachFiletoEmai
> lForProduct?productId=${parameters.productId}">
> + extends="UploadContent" target="uploadAttachFiletoEmai
> lForProduct?productId=${parameters.productId}">
>   
>  
>  
> 
>
> Modified: ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/scru
> m/widget/FieldLookupForms.xml?rev=176=1761110=176=diff
> 
> ==
> --- ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml
> (original)
> +++ ofbiz/trunk/specialpurpose/scrum/widget/FieldLookupForms.xml Fri Sep
> 16 22:45:08 2016
> @@ -21,7 +21,7 @@ under the License.
>  http://www.w3.org/2001/XMLSchema-instance;
>  xmlns="http://ofbiz.apache.org/Widget-Form; xsi:schemaLocation="
> http://ofbiz.apache.org/Widget-Form http://ofbiz.apache.org/dtds/w
> idget-form.xsd">
>
> - title="" type="single"
> + title="" type="single"
>  header-row-style="header-row" default-table-style="basic-table">
>  
>   value="RF_PROD_BACKLOG"/>
> @@ -38,7 +38,7 @@ under the License.
>  
>   widget-style="smallSubmit">
>  
> - type="list"
> + type="list"
>  odd-row-style="alternate-row" default-table-style="basic-table
> hover-bar" paginate-target="LookupProductBacklog">
>  
>   result-map-list="listIt">
>
> Modified:

Re: Use ecomseo on demo rather than ecommerce

>
> This mostly to somehow battle test it, even if I know it works well


So does it need battle testing or does it work well?  Have you deployed it
to any production instances?  Has anyone else?

Regards
Scott

On 19 September 2016 at 01:27, Jacques Le Roux  wrote:

> Hi,
>
> Maybe you don't know about or did not try it, but we have ecomseo a clone
> of the ecommerce component tailored for SEO
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Search+
> Engine+Optimisation,+SEO+in+ecommerce
>
> I propose to use it as the default ecommerce demo. This mostly to somehow
> battle test it, even if I know it works well.
>
> As it's based on ecommerce, users should not experience a big changes,
> apart the changed URLs
>
> What do you think?
>
> Jacques
>
>

Re: Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]

On Thu, Sep 22, 2016 at 9:36 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Jacopo,
>
> I saw you answered on Confluence where I 1st asked
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+
> commit+message+template?focusedCommentId=65871637#comment-65871637
>
> Now, I understand that we need to pick a word, but why not being more
> flexible, similarly at what does GitHub https://help.github.com/articl
> es/closing-issues-via-commit-messages/ ?
>
>
It seems we agree with your first proposal of using "documented", "fixed",
"reverted" so I will update the Wiki now to reflect these changes; if the
other committers will object we will revisit this decision.

As regards the "flexibility" topic, in my opinion it will defeat the effort
of defining a template format: however I don't have further time to spend
on this topic at the moment so I will let others to continue it in this
thread and we will see what the outcome is.

Jacopo

Re: Use ecomseo on demo rather than ecommerce


OK forget it for now. I just realised that ecomseo starts with R15.
So you can still get to it in trunk demo using https://ofbiz-vm.apache.org:8443/ecomseo but it will available to users from official site main page 
only when we will roll out R16


But mmm, I vaguely remember having proposed to rotate our demos. Since we will 
not publish R16 before at least some months, could we not?

1. drop R12.04 (no longer supported anyway)
2. Rename related title in site main page from
   12.04 Release Branch Demo (old)
   to
   R15 Pending Branch Demo (unstable)
3. And replace R12.04 by R15

Opinions?

Jacques

Le 21/09/2016 à 18:40, Jacques Le Roux a écrit :

After 3 day, I consider this a lazy consensus since nobody chimed in and will 
change accordingly tomorrow

Jacques


Le 18/09/2016 à 15:27, Jacques Le Roux a écrit :

Hi,

Maybe you don't know about or did not try it, but we have ecomseo a clone of 
the ecommerce component tailored for SEO

https://cwiki.apache.org/confluence/display/OFBIZ/Search+Engine+Optimisation,+SEO+in+ecommerce

I propose to use it as the default ecommerce demo. This mostly to somehow 
battle test it, even if I know it works well.

As it's based on ecommerce, users should not experience a big changes, apart 
the changed URLs

What do you think?

Jacques

Commit template, more flexibility [was Re: Put "Reverts" in the commit template?]


Jacopo,

I saw you answered on Confluence where I 1st asked 
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+commit+message+template?focusedCommentId=65871637#comment-65871637


Now, I understand that we need to pick a word, but why not being more flexible, similarly at what does GitHub 
https://help.github.com/articles/closing-issues-via-commit-messages/ ?


I already suggested in previous threads that I could help if the process 
Michael uses to create the blog monthly report needs to be adapted.
In relation, I also created in the "Wiki page for the "monthly Jira issues list" 
creation in the blog" thread, without any answers so far :/

Thanks

Jacques


Le 22/09/2016 à 08:45, Jacques Le Roux a écrit :

Hi Jacopo,

What is the logical behind this? It's not the first time I ask and I'd really 
like to have a clarification.

We have "Fix for" and "Documentation". Why not "Fixed" and "Documented"?

Thanks

Jacques

Le 21/09/2016 à 19:09, Jacopo Cappellato a écrit :

I have changed it to "Reverted" for consistency reasons.

Jacopo



On Wed, Sep 21, 2016 at 7:01 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Done

Jacques


Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :


Hi,

In some cases we need to revert a commit done for a Jira after we
discover it causes an issue. We have not yet other means that using the fix
word.
I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it
please you) word in the commit template for this reason.
Because it's a different thing than really fixing the initial issue
reported in the Jira but it's sill related to it

What do you think?

Jacques

Re: Put "Reverts" in the commit template?

I have answered you in the Wiki but quoting here for everyone's convenience:

"Jacques, for me it is a done deal!

As you suggests we could change:

   - Documentation --> Documented
   - Fix for --> Fixed

And the final list of verbs will be:

[Implemented|Improved|Fixed|Completed|Documented|Reverted]

If there are no objections (as I hope) we will finally have a template that
will be adopted by all committers (and also by Jacques)!"

On Thu, Sep 22, 2016 at 8:45 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Jacopo,
>
> What is the logical behind this? It's not the first time I ask and I'd
> really like to have a clarification.
>
> We have "Fix for" and "Documentation". Why not "Fixed" and "Documented"?
>
> Thanks
>
> Jacques
>
>
> Le 21/09/2016 à 19:09, Jacopo Cappellato a écrit :
>
>> I have changed it to "Reverted" for consistency reasons.
>>
>> Jacopo
>>
>>
>>
>> On Wed, Sep 21, 2016 at 7:01 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> Done
>>>
>>> Jacques
>>>
>>>
>>> Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :
>>>
>>> Hi,

 In some cases we need to revert a commit done for a Jira after we
 discover it causes an issue. We have not yet other means that using the
 fix
 word.
 I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it
 please you) word in the commit template for this reason.
 Because it's a different thing than really fixing the initial issue
 reported in the Jira but it's sill related to it

 What do you think?

 Jacques

>

Re: Permission service not on the same transaction


Hi Rishi,

in line

Le 19/09/2016 à 16:20, Rishi Solanki a écrit :

Nicolas,

"If you are dealing with money, or precision is a must, use BigDecimal.
Otherwise Doubles tend to be good enough." That means, for quantity fields
double should be fine. But within OFBiz, I see entities like OrderItem,
OISGIR, and many other uses BigDecimal for quantity field. But I think that
is because in orderred quantity due to Product.orderDecimalQuantity user
may enter the decimal quantity.

With all this said, if we think WorkEffortGoodStandard.estimatedQuantity
may contains precision values in it in some business scenarios then we
should go for the #3. Or simple conversion should work as you suggested in
#1.
Sure the #3 would be the better choice, but the step is hard ! I agree 
with you to move on first stable point, and close this too long task.

My suggestion is to go with #1, as I couldn't think of scenario where
precision required upto many decimal places for the
WorkEffortGoodStandard.estimatedQuantity field.

Hope its not too late for original topic in this thread, +1 for using the
same transaction for the permission services. As whenever we call
permission service in a wrapper service we always use the same transaction.
It's never too late ;) , I continue the work and add new parameter on 
permission service to give the possibility to use or not the same 
transaction. But by default don't use the same.


If you want look forward, I create a branch permission-same-transaction 
on github.com:nmalin/ApacheOFBiz.git to work easily on it.


Nicolas


Thanks!


Best Regards,
--



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Sat, Sep 17, 2016 at 5:30 PM, Nicolas Malin 
wrote:


Hi all, I need some Help !! I put my arm in a gearing :(

After refactor the permission service, I raise a silent problem that is
all call-service used on mini-lang test didn't passed to service validation.

I correct some easier case like bad attribut passed but now rest some
complicate case like this :

testProductionRunCreation : Type check failed for field
[createWorkEffortGoodStandard.estimatedQuantity]; expected type is
[Double]; actual type is [java.math.BigDecimal]

The problem came from that :

  * Field has define as BigDecimal on mini-lang

  * The service definition use auto-attribute to resolve the java type

  * The field on the entity is define as floating-point and is converted by
fieldType as Double

So to reallign this I have some possibility

1. Easy : test are wrong : convert field instantiation to Double instead
of BigDecimal for all tests failed

2. Medium : service need realign : I surcharge attribute definition to
accept BigDecimal for these service

3. Hard : Why Double for floating-point, I had in my mind that BigDecimal
would be preferred to Double if is the case, we can change all fieldType
conversion to BigDecimal instead of Double and realign all ofbiz code
related.

Your suggest will be truly appreciated ;)

Nicolas


Le 15/04/2016 à 08:23, Taher Alkhateeb a écrit :


Hi Nicolas,

I have to note that in ModelPermission the same exact call is also made
with a new transaction. I did not dig deep into it but I advice to at
least
check it over there as well. This makes me suspect that either both call
are wrong or both calls are right.

HTH

Taher Alkhateeb

On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
pranay.pan...@hotwaxsystems.com> wrote:

Hi Nicolas,

Calling it as permission service is tricky. I see the comment in
implementation above the simple method in ShipmentServices.xml-

  

It was implemented with a purpose to be called inline, may be supporting
the traditional way of doing things. Reviewing at a complete patch with
all
the modifications you have done for making shipment CRUD operations can
help here getting the opinion. WDYT?

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin 
wrote:

Hello,

Currently I continue the conversion on shipment  crud service and I
detected that many service use the same mini-lang call to check if the
shipment status is ok for editing "checkCanChangeShipmentStatusPacked"

I convert it on service to call it directly by the permission-service
like that :

  ...
  
  ...
  

The problem with this change that when I run the unit tests, I have some
failed to due database lock on shipment.
After some analyse I founded that the permission service wasn't call on
the same service's transaction.
I a realize this change :

Index: framework/service/src/org/ofbiz/service/ModelService.java
===
--- framework/service/src/org/ofbiz/service/ModelService.java
(révision 1737860)
+++ framework/service/src/org/ofbiz/service/ModelService.java(copie
de travail)
@@ -985,7 +985,7 @@

Re: Put "Reverts" in the commit template?