date:20200227

And/or contains elements that provide criminal parties information to
impersonate valid users.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Fri, Feb 28, 2020 at 2:54 AM Pierre Smits  wrote:

> -1
>
> As this release contains software elements that will enable criminal
> parties to gain access to the implemented OFBiz system of a user (a
> business organisation) and impersonate valid users with the intent to bring
> harm to the aforementioned business organisation through transactions
> registered by the impersonated valid user..
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
>
>
> On Thu, Feb 27, 2020 at 8:56 PM Nicola Mazzoni 
> wrote:
>
>> +1
>>
>> Il gio 27 feb 2020, 18:40 Jacques Le Roux 
>> ha
>> scritto:
>>
>> > +1
>> >
>> > Jacques
>> >
>> > Le 27/02/2020 à 18:09, Michael Brohl a écrit :
>> > > +1
>> > >
>> > > ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.01 
>> > ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.01.zip
>> > > sha check of file: apache-ofbiz-17.12.01.zip
>> > > Using sha file: apache-ofbiz-17.12.01.zip.sha512
>> > > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51
>> 88F98E3B
>> > 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
>> > > 5B8A5358 36208F4A D26DEB40
>> > > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51
>> 88F98E3B
>> > 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
>> > > 5B8A5358 36208F4A D26DEB40
>> > > sha checksum OK
>> > >
>> > > GPG verification output
>> > > gpg: Signature made Thu Feb 27 10:36:12 2020 CET using RSA key ID
>> > 847AF9E0
>> > > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) <
>> > jaco...@apache.org>" [ultimate]
>> > >
>> > >
>> > > ./gradlew loadAll testIntegration
>> > >
>> > > ...
>> > >
>> > > :testIntegration
>> > >
>> > > BUILD SUCCESSFUL
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > Michael Brohl
>> > >
>> > > ecomify GmbH - www.ecomify.de
>> > >
>> > >
>> > > Am 27.02.20 um 10:49 schrieb Jacopo Cappellato:
>> > >> This is the vote thread (3nd attempt) to release "Apache OFBiz
>> > 17.12.01":
>> > >> this is the first release, containing the framework, applications and
>> > all
>> > >> the plugins from the 17.12 release branches.
>> > >>
>> > >> The release files can be downloaded from here:
>> > >> https://dist.apache.org/repos/dist/dev/ofbiz/
>> > >>
>> > >> and are:
>> > >> * apache-ofbiz-17.12.01.zip
>> > >> * KEYS: text file with keys
>> > >> * apache-ofbiz-17.12.01.zip.asc: the detached signature file
>> > >> * apache-ofbiz-17.12.01.zip.sha512: checksum file
>> > >>
>> > >> Please download the zip file, build and test OFBiz and verify the
>> > signature
>> > >> and checksum (for instructions on testing the signatures see
>> > >> http://www.apache.org/info/verification.html).
>> > >>
>> > >> Vote:
>> > >>
>> > >> [ +1] release as Apache OFBiz 17.12.01
>> > >> [ -1] do not release
>> > >>
>> > >> This vote will be open for 5 days.
>> > >> For more details about this process please read
>> > >> http://www.apache.org/foundation/voting.html
>> > >>
>> > >
>> >
>>
>

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3

-1

As this release contains software elements that will enable criminal
parties to gain access to the implemented OFBiz system of a user (a
business organisation) and impersonate valid users with the intent to bring
harm to the aforementioned business organisation through transactions
registered by the impersonated valid user..

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Thu, Feb 27, 2020 at 8:56 PM Nicola Mazzoni 
wrote:

> +1
>
> Il gio 27 feb 2020, 18:40 Jacques Le Roux 
> ha
> scritto:
>
> > +1
> >
> > Jacques
> >
> > Le 27/02/2020 à 18:09, Michael Brohl a écrit :
> > > +1
> > >
> > > ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.01 
> > ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.01.zip
> > > sha check of file: apache-ofbiz-17.12.01.zip
> > > Using sha file: apache-ofbiz-17.12.01.zip.sha512
> > > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B
> > 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
> > > 5B8A5358 36208F4A D26DEB40
> > > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B
> > 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
> > > 5B8A5358 36208F4A D26DEB40
> > > sha checksum OK
> > >
> > > GPG verification output
> > > gpg: Signature made Thu Feb 27 10:36:12 2020 CET using RSA key ID
> > 847AF9E0
> > > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) <
> > jaco...@apache.org>" [ultimate]
> > >
> > >
> > > ./gradlew loadAll testIntegration
> > >
> > > ...
> > >
> > > :testIntegration
> > >
> > > BUILD SUCCESSFUL
> > >
> > >
> > > Thanks,
> > >
> > > Michael Brohl
> > >
> > > ecomify GmbH - www.ecomify.de
> > >
> > >
> > > Am 27.02.20 um 10:49 schrieb Jacopo Cappellato:
> > >> This is the vote thread (3nd attempt) to release "Apache OFBiz
> > 17.12.01":
> > >> this is the first release, containing the framework, applications and
> > all
> > >> the plugins from the 17.12 release branches.
> > >>
> > >> The release files can be downloaded from here:
> > >> https://dist.apache.org/repos/dist/dev/ofbiz/
> > >>
> > >> and are:
> > >> * apache-ofbiz-17.12.01.zip
> > >> * KEYS: text file with keys
> > >> * apache-ofbiz-17.12.01.zip.asc: the detached signature file
> > >> * apache-ofbiz-17.12.01.zip.sha512: checksum file
> > >>
> > >> Please download the zip file, build and test OFBiz and verify the
> > signature
> > >> and checksum (for instructions on testing the signatures see
> > >> http://www.apache.org/info/verification.html).
> > >>
> > >> Vote:
> > >>
> > >> [ +1] release as Apache OFBiz 17.12.01
> > >> [ -1] do not release
> > >>
> > >> This vote will be open for 5 days.
> > >> For more details about this process please read
> > >> http://www.apache.org/foundation/voting.html
> > >>
> > >
> >
>

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3

2020-02-27 Thread Nicola Mazzoni

+1

Il gio 27 feb 2020, 18:40 Jacques Le Roux  ha
scritto:

> +1
>
> Jacques
>
> Le 27/02/2020 à 18:09, Michael Brohl a écrit :
> > +1
> >
> > ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.01 
> ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.01.zip
> > sha check of file: apache-ofbiz-17.12.01.zip
> > Using sha file: apache-ofbiz-17.12.01.zip.sha512
> > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B
> 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
> > 5B8A5358 36208F4A D26DEB40
> > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B
> 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
> > 5B8A5358 36208F4A D26DEB40
> > sha checksum OK
> >
> > GPG verification output
> > gpg: Signature made Thu Feb 27 10:36:12 2020 CET using RSA key ID
> 847AF9E0
> > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) <
> jaco...@apache.org>" [ultimate]
> >
> >
> > ./gradlew loadAll testIntegration
> >
> > ...
> >
> > :testIntegration
> >
> > BUILD SUCCESSFUL
> >
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 27.02.20 um 10:49 schrieb Jacopo Cappellato:
> >> This is the vote thread (3nd attempt) to release "Apache OFBiz
> 17.12.01":
> >> this is the first release, containing the framework, applications and
> all
> >> the plugins from the 17.12 release branches.
> >>
> >> The release files can be downloaded from here:
> >> https://dist.apache.org/repos/dist/dev/ofbiz/
> >>
> >> and are:
> >> * apache-ofbiz-17.12.01.zip
> >> * KEYS: text file with keys
> >> * apache-ofbiz-17.12.01.zip.asc: the detached signature file
> >> * apache-ofbiz-17.12.01.zip.sha512: checksum file
> >>
> >> Please download the zip file, build and test OFBiz and verify the
> signature
> >> and checksum (for instructions on testing the signatures see
> >> http://www.apache.org/info/verification.html).
> >>
> >> Vote:
> >>
> >> [ +1] release as Apache OFBiz 17.12.01
> >> [ -1] do not release
> >>
> >> This vote will be open for 5 days.
> >> For more details about this process please read
> >> http://www.apache.org/foundation/voting.html
> >>
> >
>

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3


+1

Jacques

Le 27/02/2020 à 18:09, Michael Brohl a écrit :

+1

~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.01  
../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.01.zip
sha check of file: apache-ofbiz-17.12.01.zip
Using sha file: apache-ofbiz-17.12.01.zip.sha512
apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72 
5B8A5358 36208F4A D26DEB40
apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72 
5B8A5358 36208F4A D26DEB40

sha checksum OK

GPG verification output
gpg: Signature made Thu Feb 27 10:36:12 2020 CET using RSA key ID 847AF9E0
gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) 
" [ultimate]


./gradlew loadAll testIntegration

...

:testIntegration

BUILD SUCCESSFUL


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.02.20 um 10:49 schrieb Jacopo Cappellato:

This is the vote thread (3nd attempt) to release "Apache OFBiz 17.12.01":
this is the first release, containing the framework, applications and all
the plugins from the 17.12 release branches.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/

and are:
* apache-ofbiz-17.12.01.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.01.zip.asc: the detached signature file
* apache-ofbiz-17.12.01.zip.sha512: checksum file

Please download the zip file, build and test OFBiz and verify the signature
and checksum (for instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 17.12.01
[ -1] do not release

This vote will be open for 5 days.
For more details about this process please read
http://www.apache.org/foundation/voting.html

Re: OFBiz and WooCommerce


Hi Prisca,


Your message has been moderated.

Please subscribe to the user ML for such questions and then use your email 
client.
See why here http://ofbiz.apache.org/mailing-lists.html.

You will get a better support, people can answer you on the ML.
The wider the audience the better the answers you might get.

Also it's more work for moderators who have to accept your messages as long as 
you have not subscribed.
I'll personally no longer accept them (other moderators still could).

Thanks

This said, I don't know about WooCommerce so can't help you. Maybe on user ML, 
you can get more information...

Jacques

Le 27/02/2020 à 16:47, UP Digital Studio a écrit :

Hello,

I’m a web developer and I’m currently building an e-commerce website using 
WooCommerce+WordPress. I’m writing on behalf of my client who is willing to 
have an ERP connected to the website. She’s hesitating with Dolibarr and OFBiz. 
We’d like to know if OFbiz could work with WooCommerce and how because I can’t 
find any info through Google.

Thanks a lot for your response.

Best,

Prisca

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3


+1

~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.01  
../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.01.zip

sha check of file: apache-ofbiz-17.12.01.zip
Using sha file: apache-ofbiz-17.12.01.zip.sha512
apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B 
76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72 
5B8A5358 36208F4A D26DEB40
apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B 
76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72 
5B8A5358 36208F4A D26DEB40

sha checksum OK

GPG verification output
gpg: Signature made Thu Feb 27 10:36:12 2020 CET using RSA key ID 847AF9E0
gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) 
" [ultimate]



./gradlew loadAll testIntegration

...

:testIntegration

BUILD SUCCESSFUL


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.02.20 um 10:49 schrieb Jacopo Cappellato:

This is the vote thread (3nd attempt) to release "Apache OFBiz 17.12.01":
this is the first release, containing the framework, applications and all
the plugins from the 17.12 release branches.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/

and are:
* apache-ofbiz-17.12.01.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.01.zip.asc: the detached signature file
* apache-ofbiz-17.12.01.zip.sha512: checksum file

Please download the zip file, build and test OFBiz and verify the signature
and checksum (for instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 17.12.01
[ -1] do not release

This vote will be open for 5 days.
For more details about this process please read
http://www.apache.org/foundation/voting.html





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ofbiz-framework] branch trunk updated: Improved: Convert ProductServices.xml mini lang to groovy (OFBIZ-10231)


Hi Nicolas,

great, thanks for reviewing and improving the code!

Please go ahead and commit,

thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.02.20 um 16:22 schrieb Nicolas Malin:

Michael, I have lot of improvement to share with your commit (groovy
syntax, code simplification)

Do you prefer keep the hand, or I commit directly ?

You can find some diff on my starting work here  [1]

Cheers,

Nicolas

[1]
https://github.com/nmalin/ApacheOFBiz/compare/ProductService.groovy?expand=1

On 21/02/2020 17:51, mbr...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

mbrohl pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new e0a26fc  Improved: Convert ProductServices.xml mini lang to groovy 
(OFBIZ-10231)
e0a26fc is described below

commit e0a26fce43eec7c84d87c0d5055ff0a87f2af796
Author: Michael Brohl 
AuthorDate: Fri Feb 21 16:59:37 2020 +0100

 Improved: Convert ProductServices.xml mini lang to groovy
 (OFBIZ-10231)
 
 Thanks Dennis Balkir for reporting and Sebastian Berg for the implementation.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [TEST] Test "POC for CSRF Token"


Forgot to say that w/ or w/o test I'll commit in 1 month...

Jacques

Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :

Hi,

After working with James, who initiated the "POC for CSRF Token" effort, on 
https://issues.apache.org/jira/browse/OFBIZ-11306
I have created OFBIZ-11425 to ask for all possible help to review and test.

TIA

Jacques

OFBiz and WooCommerce

2020-02-27 Thread UP Digital Studio

Hello,

I’m a web developer and I’m currently building an e-commerce website using 
WooCommerce+WordPress. I’m writing on behalf of my client who is willing to 
have an ERP connected to the website. She’s hesitating with Dolibarr and OFBiz. 
We’d like to know if OFbiz could work with WooCommerce and how because I can’t 
find any info through Google.

Thanks a lot for your response.

Best,

Prisca

Re: [ofbiz-framework] branch trunk updated: Improved: Convert ProductServices.xml mini lang to groovy (OFBIZ-10231)

2020-02-27 Thread Nicolas Malin

Michael, I have lot of improvement to share with your commit (groovy
syntax, code simplification)

Do you prefer keep the hand, or I commit directly ?

You can find some diff on my starting work here  [1]

Cheers,

Nicolas

[1]
https://github.com/nmalin/ApacheOFBiz/compare/ProductService.groovy?expand=1

On 21/02/2020 17:51, mbr...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> mbrohl pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>  new e0a26fc  Improved: Convert ProductServices.xml mini lang to groovy 
> (OFBIZ-10231)
> e0a26fc is described below
>
> commit e0a26fce43eec7c84d87c0d5055ff0a87f2af796
> Author: Michael Brohl 
> AuthorDate: Fri Feb 21 16:59:37 2020 +0100
>
> Improved: Convert ProductServices.xml mini lang to groovy
> (OFBIZ-10231)
> 
> Thanks Dennis Balkir for reporting and Sebastian Berg for the 
> implementation.
> ---
>  .../product/product/ProductServices.groovy | 1095 
> 
>  .../minilang/product/product/ProductServices.xml   | 1051 ---
>  applications/product/servicedef/services.xml   |  112 +-
>  3 files changed, 1151 insertions(+), 1107 deletions(-)
>
> diff --git 
> a/applications/product/groovyScripts/product/product/ProductServices.groovy 
> b/applications/product/groovyScripts/product/product/ProductServices.groovy
> new file mode 100644
> index 000..b4be894
> --- /dev/null
> +++ 
> b/applications/product/groovyScripts/product/product/ProductServices.groovy
> @@ -0,0 +1,1095 @@
> +/*
> +  * Licensed to the Apache Software Foundation (ASF) under one
> +  * or more contributor license agreements.  See the NOTICE file
> +  * distributed with this work for additional information
> +  * regarding copyright ownership.  The ASF licenses this file
> +  * to you under the Apache License, Version 2.0 (the
> +  * "License"); you may not use this file except in compliance
> +  * with the License.  You may obtain a copy of the License at
> +  *
> +  * http://www.apache.org/licenses/LICENSE-2.0
> +  *
> +  * Unless required by applicable law or agreed to in writing,
> +  * software distributed under the License is distributed on an
> +  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> +  * KIND, either express or implied.  See the License for the
> +  * specific language governing permissions and limitations
> +  * under the License.
> +  */
> +
> +
> +import java.sql.Timestamp
> +
> +import org.apache.ofbiz.base.util.UtilDateTime
> +import org.apache.ofbiz.base.util.UtilProperties
> +import org.apache.ofbiz.base.util.UtilValidate
> +import org.apache.ofbiz.entity.GenericValue
> +import org.apache.ofbiz.entity.serialize.XmlSerializer
> +import org.apache.ofbiz.entity.util.EntityUtil
> +import org.apache.ofbiz.product.product.KeywordIndex
> +import org.apache.ofbiz.product.product.ProductWorker
> +import org.apache.ofbiz.service.ServiceUtil
> +
> +
> +
> + module = "ProductServices.groovy" // this is used for logging
> +
> + /**
> +  * Create a Product
> +  */
> + def createProduct() {
> +Map result = success()
> +if (!(security.hasEntityPermission("CATALOG", "_CREATE", 
> parameters.userLogin)
> +|| security.hasEntityPermission("CATALOG_ROLE", "_CREATE", 
> parameters.userLogin))) {
> +return error(UtilProperties.getMessage("ProductUiLabels", 
> "ProductCatalogCreatePermissionError", parameters.locale))
> +}
> +
> +GenericValue newEntity = makeValue("Product")
> +newEntity.setNonPKFields(parameters)
> +
> +newEntity.productId = parameters.productId
> +
> +if (UtilValidate.isEmpty(newEntity.productId)) {
> +newEntity.productId = delegator.getNextSeqId("Product")
> +} else {
> +String errorMessage = 
> UtilValidate.checkValidDatabaseId(newEntity.productId)
> +if(errorMessage != null) {
> +logError(errorMessage)
> +return error(errorMessage)
> +}
> +GenericValue dummyProduct = findOne("Product", ["productId": 
> parameters.productId], false)
> +if (UtilValidate.isNotEmpty(dummyProduct)) {
> + errorMessage = UtilProperties.getMessage("CommonErrorUiLabels", 
> CommonErrorDuplicateKey, parameters.locale)
> +logError(errorMessage)
> +return error(errorMessage)
> +}
> +}
> +result.productId = newEntity.productId
> +
> +Timestamp nowTimestamp = UtilDateTime.nowTimestamp()
> +
> +newEntity.createdDate = nowTimestamp
> +newEntity.lastModifiedDate = nowTimestamp
> +newEntity.lastModifiedByUserLogin = userLogin.userLoginId
> +newEntity.createdByUserLogin = userLogin.userLoginId
> +
> +if (UtilValidate.isEmpty(newEntity.isVariant)) {
> +newEntity.isVariant = "N"
> +}
> +if (UtilValidate.isEmpty(newEntity.isVirtual)) {
> +

Re: [DISCUSSION] Should we clean labels?

Weird, I don't get it as you can check at

https://issues.apache.org/jira/secure/attachment/12994793/OFBIZ-9352-not-used.png

Jacques

Le 27/02/2020 à 15:03, Michael Brohl a écrit :

Jacques,

I know and used this feature on demo-trunk. If you select the AccountingUiLabels.xml and search for unused labels, you get
AccountingDeleteRateAmount among others.

Using a find for *all* files with the unused labels checkbox did not display
any results for me.

Did not dig further on the logic to find those unused labels, maybe later.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 27.02.20 um 14:53 schrieb Jacques Le Roux:

Michael,

Inline,

Le 27/02/2020 à 13:35, Michael Brohl a écrit :

You simply cannot rely on the LabelManager itself. It shows unused labels which
are used [1].

Example: AccountingErrorUiLabels.xml#AccountingDeleteRateAmount is shown as
unused on demo-trunk but is used in RateServices.groovy.

I did not have AccountingDeleteRateAmount in the list of 250 missing labels on
trunk demo.

I randomly picked a couple of other missing labels and did not find them but in
the AccountingUiLabels.xml file

This said to be sure I'd need to check 250 instances, nobody would do that. As you said, we need another tool. It would be used after automatically
collected unused labels enhancing "Not used labels" Label Manager feature.

Actually it's already what does "Not used labels" Label Manager feature ;) It's LabelManagerFactory:findMatchingLabels and depends on
onlyNotUsedLabels var. If you need more information please let me know.

How would you envision a tool to check its result, which may be indeed incomplete and even possibly wrong (though we made good progress last time,
see OFBIZ-8154)

So steps 1 and 2 are necessary because changes should not introduce regressions
(better unsed labels than missing labels).

IMO this check cannot be burdened upon the committer (if another contributor provided the patch).The responsibility to thoroughly check if a
removed label is in fact unused should be on the contributor. Which means he should prove which steps he took to check each removed label [2].

Yes, that's why, after being bitten once or twice, I'm now reluctant to remove
"unused" labels :/.

Jacques

Step 3 is not something we should make a general rule. I agree with Jacques
that this is unreasonable effort.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

[1] I did not check how the LabelManager detects unused labels, can someone
briefly explain out of mind?

[2] We might need a mechanism or script to check a list of labels reported by
the UILabelManager against the codebase. Doing this by hand is tedious.

Am 27.02.20 um 12:45 schrieb Jacques Le Roux:

Hi,

With OFBIZ-9352 (under OFBIZ-10565) Pierre Smits propose to remove unused
labels from AccountingUiLabels.xml

This morning I looked at the related PR (17) and, using Label Manager (in Webtools) found that there are much more unused labels than those
Pierre proposes to remove.

I checked the 5 1st ones locally in my IDE and they are indeed unused (no
references at all but in the label file).

Now we had already a talk with Pierre, Scott and Michael about removing labels
in OFBIZ-9352.

Scott, Michael, and I in a less measure, are cautious about the reasons to remove
"unused" labels and you can read in OFBIZ-9352.

To define an unused labels I repeat what I said above:

An unused label is a label reported by the Label Manager as unused that can be
checked as unused by hand.

As you can see with my answer to Scoot in OFBIZ-9352, more work may be needed
if we want to trace why a label is unused.

My question, is should we remove unused labels?

And if we do so, which steps should me required:

1. Label Manager
2. Check by hand locally
3. Trace the reason

Obviously if we require the 3 steps nobody will do it (will you?).

Even the 2 steps are much work for a little benefit

So what? Should we close Jira issues related to removing unused labels as won't do.
Should they stay for the "eternity"?

About the Label Manager "unused labels" option, I think it can be still useful
in custom projects, but, as shown above, tricky OOTB.

Jacques

Re: [DISCUSSION] Should we clean labels?


Saying is not proving IMO.

The contributor should at least provide information *how* he did the 
checks along with the patch to help the committer decide. That is very 
reasonable to ask for.


Low hanging fruits can also be foul. It does not help anyone to commit a 
patch to remove labels and get one or more Jira bug reports back, 
reporting missing labels.


Michael

ecomify GmbH - www.ecomify.de

Am 27.02.20 um 14:42 schrieb Pierre Smits:

Re: IMO this check cannot be burdened upon the committer (if another
contributor provided the patch).The responsibility to thoroughly check if a
removed label is in fact unused should be on the contributor. Which means
he should prove which steps he took to check each removed label [2].

We can all guess what the comment with the patch will be: 'I did the manual
check(s) and I found it only in Labels.xml'.
What then?

1. Asking for more details? Or screenshots? Or log excerpts?
2. A statement of distrust towards the fellow contributor?


Don't require more than is reasonable for this kind of low hanging fruit.





smime.p7s
Description: S/MIME Cryptographic Signature

[TEST] Test "POC for CSRF Token"


Hi,

After working with James, who initiated the "POC for CSRF Token" effort, on 
https://issues.apache.org/jira/browse/OFBIZ-11306
I have created OFBIZ-11425 to ask for all possible help to review and test.

TIA

Jacques

Re: [DISCUSSION] Should we clean labels?


Jacques,

I know and used this feature on demo-trunk. If you select the 
AccountingUiLabels.xml and search for unused labels, you get 
AccountingDeleteRateAmount among others.


Using a find for *all* files with the unused labels checkbox did not 
display any results for me.


Did not dig further on the logic to find those unused labels, maybe later.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.02.20 um 14:53 schrieb Jacques Le Roux:

Michael,

Inline,

Le 27/02/2020 à 13:35, Michael Brohl a écrit :
You simply cannot rely on the LabelManager itself. It shows unused 
labels which are used [1].


Example: AccountingErrorUiLabels.xml#AccountingDeleteRateAmount is 
shown as unused on demo-trunk but is used in RateServices.groovy.


I did not have AccountingDeleteRateAmount in the list of 250 missing 
labels on trunk demo.


I randomly picked a couple of other missing labels and did not find 
them but in the AccountingUiLabels.xml file


This said to be sure I'd need to check 250 instances, nobody would do 
that. As you said, we need another tool. It would be used after 
automatically collected unused labels enhancing "Not used labels" 
Label Manager feature.


Actually it's already what does "Not used labels" Label Manager 
feature ;) It's LabelManagerFactory:findMatchingLabels and depends on 
onlyNotUsedLabels var. If you need more information please let me know.


How would you envision a tool to check its result, which may be indeed 
incomplete and even possibly wrong (though we made good progress last 
time, see OFBIZ-8154)





So steps 1 and 2 are necessary because changes should not introduce 
regressions (better unsed labels than missing labels).


IMO this check cannot be burdened upon the committer (if another 
contributor provided the patch).The responsibility to thoroughly 
check if a removed label is in fact unused should be on the 
contributor. Which means he should prove which steps he took to check 
each removed label [2].


Yes, that's why, after being bitten once or twice, I'm now reluctant 
to remove "unused" labels :/.


Jacques




Step 3 is not something we should make a general rule. I agree with 
Jacques that this is unreasonable effort.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


[1] I did not check how the LabelManager detects unused labels, can 
someone briefly explain out of mind?


[2] We might need a mechanism or script to check a list of labels 
reported by the UILabelManager against the codebase. Doing this by 
hand is tedious.



Am 27.02.20 um 12:45 schrieb Jacques Le Roux:

Hi,

With OFBIZ-9352 (under OFBIZ-10565) Pierre Smits propose to remove 
unused labels from AccountingUiLabels.xml


This morning I looked at the related PR (17) and, using Label 
Manager (in Webtools) found that there are much more unused labels 
than those Pierre proposes to remove.


I checked the 5 1st ones locally in my IDE and they are indeed 
unused (no references at all but in the label file).


Now we had already a talk with Pierre, Scott and Michael about 
removing labels in OFBIZ-9352.


Scott, Michael, and I in a less measure, are cautious about the 
reasons to remove "unused" labels and you can read in OFBIZ-9352.


To define an unused labels I repeat what I said above:

An unused label is a label reported by the Label Manager as unused 
that can be checked as unused by hand.


As you can see with my answer to Scoot in OFBIZ-9352, more work may 
be needed if we want to trace why a label is unused.


My question, is should we remove unused labels?

And if we do so, which steps should me required:

1. Label Manager
2. Check by hand locally
3. Trace the reason

Obviously if we require the 3 steps nobody will do it (will you?).

Even the 2 steps are much work for a little benefit

So what? Should we close Jira issues related to removing unused 
labels as won't do. Should they stay for the "eternity"?


About the Label Manager "unused labels" option, I think it can be 
still useful in custom projects, but, as shown above, tricky OOTB.


Jacques








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [DISCUSSION] Should we clean labels?

Michael,

Inline,

Le 27/02/2020 à 13:35, Michael Brohl a écrit :

You simply cannot rely on the LabelManager itself. It shows unused labels which
are used [1].

Example: AccountingErrorUiLabels.xml#AccountingDeleteRateAmount is shown as
unused on demo-trunk but is used in RateServices.groovy.

I did not have AccountingDeleteRateAmount in the list of 250 missing labels on
trunk demo.

I randomly picked a couple of other missing labels and did not find them but in
the AccountingUiLabels.xml file

How would you envision a tool to check its result, which may be indeed incomplete and even possibly wrong (though we made good progress last time, see
OFBIZ-8154)

So steps 1 and 2 are necessary because changes should not introduce regressions
(better unsed labels than missing labels).

IMO this check cannot be burdened upon the committer (if another contributor provided the patch).The responsibility to thoroughly check if a removed
label is in fact unused should be on the contributor. Which means he should prove which steps he took to check each removed label [2].

Yes, that's why, after being bitten once or twice, I'm now reluctant to remove
"unused" labels :/.

Jacques

Step 3 is not something we should make a general rule. I agree with Jacques
that this is unreasonable effort.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

[1] I did not check how the LabelManager detects unused labels, can someone
briefly explain out of mind?

[2] We might need a mechanism or script to check a list of labels reported by
the UILabelManager against the codebase. Doing this by hand is tedious.

Am 27.02.20 um 12:45 schrieb Jacques Le Roux:

Hi,

With OFBIZ-9352 (under OFBIZ-10565) Pierre Smits propose to remove unused
labels from AccountingUiLabels.xml

This morning I looked at the related PR (17) and, using Label Manager (in Webtools) found that there are much more unused labels than those Pierre
proposes to remove.

I checked the 5 1st ones locally in my IDE and they are indeed unused (no
references at all but in the label file).

Now we had already a talk with Pierre, Scott and Michael about removing labels
in OFBIZ-9352.

Scott, Michael, and I in a less measure, are cautious about the reasons to remove
"unused" labels and you can read in OFBIZ-9352.

To define an unused labels I repeat what I said above:

An unused label is a label reported by the Label Manager as unused that can be
checked as unused by hand.

As you can see with my answer to Scoot in OFBIZ-9352, more work may be needed
if we want to trace why a label is unused.

My question, is should we remove unused labels?

And if we do so, which steps should me required:

1. Label Manager
2. Check by hand locally
3. Trace the reason

Obviously if we require the 3 steps nobody will do it (will you?).

Even the 2 steps are much work for a little benefit

So what? Should we close Jira issues related to removing unused labels as won't do.
Should they stay for the "eternity"?

About the Label Manager "unused labels" option, I think it can be still useful
in custom projects, but, as shown above, tricky OOTB.

Jacques

Re: [DISCUSSION] Should we clean labels?

Re: IMO this check cannot be burdened upon the committer (if another
contributor provided the patch).The responsibility to thoroughly check if a
removed label is in fact unused should be on the contributor. Which means
he should prove which steps he took to check each removed label [2].

We can all guess what the comment with the patch will be: 'I did the manual
check(s) and I found it only in Labels.xml'.
What then?

   1. Asking for more details? Or screenshots? Or log excerpts?
   2. A statement of distrust towards the fellow contributor?


Don't require more than is reasonable for this kind of low hanging fruit.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Thu, Feb 27, 2020 at 2:23 PM Pierre Smits  wrote:

> Whatever the participation and the outcome of this discussion will be...
>
> In the past complaints (relating to the subject of labels) have been
> raised about:
>
>- patches too big (because of too much work to investigate, merges
>leading to conflicts in local repos), and
>- patches too small (asking for more work done before willingness to
>collaborate)
>
> Re: tracing the reason why something happened in the past
> This should not be a requirement (at least for aspects like unused labels
> typos and whitespace), as it places an burden on the contributor leading to
> a cost (effort) disproportionate to the benefit. Above that, it will feed
> the blame-game.
>
> Such complaints (and unreasonable requirements) are detrimental to the
> health of the project, and should not happen.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
>
>
> On Thu, Feb 27, 2020 at 1:58 PM Pierre Smits 
> wrote:
>
>> Given that the OFBiz community consists of more than just a handful of
>> active PMC Members, Committers and other contributors, the question should
>> *not* just be: Should we clean labels'.
>>
>> But rather: Should we welcome contributions that only address the
>> cleaning of unused labels, and if so get them into the code base?
>>
>> The same question can be asked for contributions regarding:
>>
>>- typos
>>- unused code
>>- whitespace
>>- etc.
>>
>> My answer, for the benefit of the project and the appreciation felt by
>> the (potential) contributor and adopter, will always be: an unequivocal YES.
>> Not only for reasons stated above, but also for all other obvious
>> positive arguments. This should not be about catering to people NOT willing
>> to do stuff, even if it is not important enough for them or regarded as
>> menial by them. This is about catering to people willing to do even this
>> kind of stuff.
>>
>> And if there is no-one (among the pool of privileged contributors)
>> willing to do this kind of work, then the PMC should grant privileges to
>> those contributors willing to do that,
>>
>> Met vriendelijke groet,
>>
>> Pierre Smits
>> *Proud* *contributor** of* Apache OFBiz  since
>> 2008 (without privileges)
>>
>> *Apache Trafodion , Vice President*
>> *Apache Directory , PMC Member*
>> Apache Incubator , committer
>> Apache Steve , committer
>>
>>
>> On Thu, Feb 27, 2020 at 12:46 PM Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>>> Hi,
>>>
>>> With OFBIZ-9352 (under OFBIZ-10565) Pierre Smits propose to remove
>>> unused labels from AccountingUiLabels.xml
>>>
>>> This morning I looked at the related PR (17) and, using Label Manager
>>> (in Webtools) found that there are much more unused labels than those
>>> Pierre
>>> proposes to remove.
>>>
>>> I checked the 5 1st ones locally in my IDE and they are indeed unused
>>> (no references at all but in the label file).
>>>
>>> Now we had already a talk with Pierre, Scott and Michael about removing
>>> labels in OFBIZ-9352.
>>>
>>> Scott, Michael, and I in a less measure, are cautious about the reasons
>>> to remove "unused" labels and you can read in OFBIZ-9352.
>>>
>>> To define an unused labels I repeat what I said above:
>>>
>>> An unused label is a label reported by the Label Manager as unused that
>>> can be checked as unused by hand.
>>>
>>> As you can see with my answer to Scoot in OFBIZ-9352, more work may be
>>> needed if we want to trace why a label is unused.
>>>
>>> My

Re: [DISCUSSION] Should we clean labels?

Whatever the participation and the outcome of this discussion will be...

In the past complaints (relating to the subject of labels) have been raised
about:

   - patches too big (because of too much work to investigate, merges
   leading to conflicts in local repos), and
   - patches too small (asking for more work done before willingness to
   collaborate)

Re: tracing the reason why something happened in the past
This should not be a requirement (at least for aspects like unused labels
typos and whitespace), as it places an burden on the contributor leading to
a cost (effort) disproportionate to the benefit. Above that, it will feed
the blame-game.

Such complaints (and unreasonable requirements) are detrimental to the
health of the project, and should not happen.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Thu, Feb 27, 2020 at 1:58 PM Pierre Smits  wrote:

> Given that the OFBiz community consists of more than just a handful of
> active PMC Members, Committers and other contributors, the question should
> *not* just be: Should we clean labels'.
>
> But rather: Should we welcome contributions that only address the cleaning
> of unused labels, and if so get them into the code base?
>
> The same question can be asked for contributions regarding:
>
>- typos
>- unused code
>- whitespace
>- etc.
>
> My answer, for the benefit of the project and the appreciation felt by the
> (potential) contributor and adopter, will always be: an unequivocal YES.
> Not only for reasons stated above, but also for all other obvious positive
> arguments. This should not be about catering to people NOT willing to do
> stuff, even if it is not important enough for them or regarded as menial by
> them. This is about catering to people willing to do even this kind of
> stuff.
>
> And if there is no-one (among the pool of privileged contributors) willing
> to do this kind of work, then the PMC should grant privileges to those
> contributors willing to do that,
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
>
>
> On Thu, Feb 27, 2020 at 12:46 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Hi,
>>
>> With OFBIZ-9352 (under OFBIZ-10565) Pierre Smits propose to remove unused
>> labels from AccountingUiLabels.xml
>>
>> This morning I looked at the related PR (17) and, using Label Manager (in
>> Webtools) found that there are much more unused labels than those Pierre
>> proposes to remove.
>>
>> I checked the 5 1st ones locally in my IDE and they are indeed unused (no
>> references at all but in the label file).
>>
>> Now we had already a talk with Pierre, Scott and Michael about removing
>> labels in OFBIZ-9352.
>>
>> Scott, Michael, and I in a less measure, are cautious about the reasons
>> to remove "unused" labels and you can read in OFBIZ-9352.
>>
>> To define an unused labels I repeat what I said above:
>>
>> An unused label is a label reported by the Label Manager as unused that
>> can be checked as unused by hand.
>>
>> As you can see with my answer to Scoot in OFBIZ-9352, more work may be
>> needed if we want to trace why a label is unused.
>>
>> My question, is should we remove unused labels?
>>
>> And if we do so, which steps should me required:
>>
>>  1. Label Manager
>>  2. Check by hand locally
>>  3. Trace the reason
>>
>> Obviously if we require the 3 steps nobody will do it (will you?).
>>
>> Even the 2 steps are much work for a little benefit
>>
>> So what? Should we close Jira issues related to removing unused labels as
>> won't do. Should they stay for the "eternity"?
>>
>> About the Label Manager "unused labels" option, I think it can be still
>> useful in custom projects, but, as shown above, tricky OOTB.
>>
>> Jacques
>>
>>

Re: [DISCUSSION] Should we clean labels?

Given that the OFBiz community consists of more than just a handful of
active PMC Members, Committers and other contributors, the question should
*not* just be: Should we clean labels'.

But rather: Should we welcome contributions that only address the cleaning
of unused labels, and if so get them into the code base?

The same question can be asked for contributions regarding:

   - typos
   - unused code
   - whitespace
   - etc.

My answer, for the benefit of the project and the appreciation felt by the
(potential) contributor and adopter, will always be: an unequivocal YES.
Not only for reasons stated above, but also for all other obvious positive
arguments. This should not be about catering to people NOT willing to do
stuff, even if it is not important enough for them or regarded as menial by
them. This is about catering to people willing to do even this kind of
stuff.

And if there is no-one (among the pool of privileged contributors) willing
to do this kind of work, then the PMC should grant privileges to those
contributors willing to do that,

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer

On Thu, Feb 27, 2020 at 12:46 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> With OFBIZ-9352 (under OFBIZ-10565) Pierre Smits propose to remove unused
> labels from AccountingUiLabels.xml
>
> This morning I looked at the related PR (17) and, using Label Manager (in
> Webtools) found that there are much more unused labels than those Pierre
> proposes to remove.
>
> I checked the 5 1st ones locally in my IDE and they are indeed unused (no
> references at all but in the label file).
>
> Now we had already a talk with Pierre, Scott and Michael about removing
> labels in OFBIZ-9352.
>
> Scott, Michael, and I in a less measure, are cautious about the reasons to
> remove "unused" labels and you can read in OFBIZ-9352.
>
> To define an unused labels I repeat what I said above:
>
> An unused label is a label reported by the Label Manager as unused that
> can be checked as unused by hand.
>
> As you can see with my answer to Scoot in OFBIZ-9352, more work may be
> needed if we want to trace why a label is unused.
>
> My question, is should we remove unused labels?
>
> And if we do so, which steps should me required:
>
>  1. Label Manager
>  2. Check by hand locally
>  3. Trace the reason
>
> Obviously if we require the 3 steps nobody will do it (will you?).
>
> Even the 2 steps are much work for a little benefit
>
> So what? Should we close Jira issues related to removing unused labels as
> won't do. Should they stay for the "eternity"?
>
> About the Label Manager "unused labels" option, I think it can be still
> useful in custom projects, but, as shown above, tricky OOTB.
>
> Jacques
>
>

Re: [DISCUSSION] Should we clean labels?

You simply cannot rely on the LabelManager itself. It shows unused 
labels which are used [1].


Example: AccountingErrorUiLabels.xml#AccountingDeleteRateAmount is shown 
as unused on demo-trunk but is used in RateServices.groovy.


So steps 1 and 2 are necessary because changes should not introduce 
regressions (better unsed labels than missing labels).


IMO this check cannot be burdened upon the committer (if another 
contributor provided the patch).The responsibility to thoroughly check 
if a removed label is in fact unused should be on the contributor. Which 
means he should prove which steps he took to check each removed label [2].


Step 3 is not something we should make a general rule. I agree with 
Jacques that this is unreasonable effort.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


[1] I did not check how the LabelManager detects unused labels, can 
someone briefly explain out of mind?


[2] We might need a mechanism or script to check a list of labels 
reported by the UILabelManager against the codebase. Doing this by hand 
is tedious.



Am 27.02.20 um 12:45 schrieb Jacques Le Roux:

Hi,

With OFBIZ-9352 (under OFBIZ-10565) Pierre Smits propose to remove 
unused labels from AccountingUiLabels.xml


This morning I looked at the related PR (17) and, using Label Manager 
(in Webtools) found that there are much more unused labels than those 
Pierre proposes to remove.


I checked the 5 1st ones locally in my IDE and they are indeed unused 
(no references at all but in the label file).


Now we had already a talk with Pierre, Scott and Michael about 
removing labels in OFBIZ-9352.


Scott, Michael, and I in a less measure, are cautious about the 
reasons to remove "unused" labels and you can read in OFBIZ-9352.


To define an unused labels I repeat what I said above:

An unused label is a label reported by the Label Manager as unused 
that can be checked as unused by hand.


As you can see with my answer to Scoot in OFBIZ-9352, more work may be 
needed if we want to trace why a label is unused.


My question, is should we remove unused labels?

And if we do so, which steps should me required:

1. Label Manager
2. Check by hand locally
3. Trace the reason

Obviously if we require the 3 steps nobody will do it (will you?).

Even the 2 steps are much work for a little benefit

So what? Should we close Jira issues related to removing unused labels 
as won't do. Should they stay for the "eternity"?


About the Label Manager "unused labels" option, I think it can be 
still useful in custom projects, but, as shown above, tricky OOTB.


Jacques






smime.p7s
Description: S/MIME Cryptographic Signature

[DISCUSSION] Should we clean labels?


Hi,

With OFBIZ-9352 (under OFBIZ-10565) Pierre Smits propose to remove unused 
labels from AccountingUiLabels.xml

This morning I looked at the related PR (17) and, using Label Manager (in Webtools) found that there are much more unused labels than those Pierre 
proposes to remove.


I checked the 5 1st ones locally in my IDE and they are indeed unused (no 
references at all but in the label file).

Now we had already a talk with Pierre, Scott and Michael about removing labels 
in OFBIZ-9352.

Scott, Michael, and I in a less measure, are cautious about the reasons to remove 
"unused" labels and you can read in OFBIZ-9352.

To define an unused labels I repeat what I said above:

An unused label is a label reported by the Label Manager as unused that can be 
checked as unused by hand.

As you can see with my answer to Scoot in OFBIZ-9352, more work may be needed 
if we want to trace why a label is unused.

My question, is should we remove unused labels?

And if we do so, which steps should me required:

1. Label Manager
2. Check by hand locally
3. Trace the reason

Obviously if we require the 3 steps nobody will do it (will you?).

Even the 2 steps are much work for a little benefit

So what? Should we close Jira issues related to removing unused labels as won't do. 
Should they stay for the "eternity"?

About the Label Manager "unused labels" option, I think it can be still useful 
in custom projects, but, as shown above, tricky OOTB.

Jacques

Re: [apache/ofbiz-framework] OFBIZ-10565 Removing unused UI labels (#17)

Jacques, all,

I am confident there are way more labels unused across the total of
components in both the base and the plugins repository than the number you
mentioned. And typos, and pieces of code not used.

That should not lead to *not* merging cleanups as they are presented. Some
of your peers have expressed in the past that this is a kind of menial
work. Others have expressed that these kind of issues are of trivial
importance. Maybe they (still) feel themselves to good to collaborate on
these kind of issues.

The project sends a wrong signal, when privileged contributors don't react
positively and timely to this kind of low hanging fruit. Not only to
developers considering their first steps in contributing. But also to
potential adopters (and their advisors) regarding cleanliness of the
product, and the liveliness of and how welcoming the project is, when
reading through the mailing lists and going through tickets.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer



Op do 27 feb. 2020 10:42 schreef Pierre Smits :

> Jacques,
>
> Be happy with what you got! I would not want to burden you (or others)
> with patches too large to check.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
>
>
> -- Forwarded message -
> From: Jacques Le Roux 
> Date: Thu, Feb 27, 2020 at 10:14 AM
> Subject: Re: [apache/ofbiz-framework] OFBIZ-10565 Removing unused UI
> labels (#17)
> To: apache/ofbiz-framework 
> Cc: Pierre Smits , Author <
> aut...@noreply.github.com>
>
>
> Hi Pierre,
>
> I checked on trunk demo with the label manager for AccountingUiLabels.xml
> and then by hand locally. At least the 5 1st ones reported by the label
> manager are unused. Could you please check on your side and complete the
> patch?
> TIA
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
>

[VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3

2020-02-27 Thread Jacopo Cappellato

This is the vote thread (3nd attempt) to release "Apache OFBiz 17.12.01":
this is the first release, containing the framework, applications and all
the plugins from the 17.12 release branches.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/

and are:
* apache-ofbiz-17.12.01.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.01.zip.asc: the detached signature file
* apache-ofbiz-17.12.01.zip.sha512: checksum file

Please download the zip file, build and test OFBiz and verify the signature
and checksum (for instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 17.12.01
[ -1] do not release

This vote will be open for 5 days.
For more details about this process please read
http://www.apache.org/foundation/voting.html

Re: [GitHub] [ofbiz-site] PierreSmits commented on issue #1: Improved: widget-theme.xsd typos (OFBIZ-11421)

Good advice, Michael. But that don't always happen.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Thu, Feb 27, 2020 at 10:35 AM Michael Brohl 
wrote:

> Every Git PR also needs a Jira, for which the notifications go to the
> notifications mailing list.
>
> If people want to contribute and follow, they should subscribe to
> notifications.
>
> Maybe we should send a reminder and encourage them to do so instead of
> mixing notifications and dev again.
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 27.02.20 um 09:54 schrieb Pierre Smits:
> > With the great difference between the numbers of subscribers of dev@ and
> > notifications@  (last time I checked notifications@ had around 50), I
> > advise against it.
> >
> > If we want more people to contribute we need more than just the handful
> of
> > active committers/contributors and employees of system integrators, we
> need
> > to ensure that such notifications get sent to largest subset of our
> > community (dev@).
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz 
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > Apache Steve , committer
> >
> >
> > On Thu, Feb 27, 2020 at 9:33 AM Michael Brohl 
> > wrote:
> >
> >> +1, Thanks Swapnil!
> >>
> >> Michael
> >>
> >> Am 27.02.20 um 09:17 schrieb Swapnil M Mane:
> >>> Hi team,
> >>> Should we move these Git notification to
> notificati...@ofbiz.apache.org
> >>> list [1] that we created in the past to avoid notification traffic on
> dev
> >>> list, thoughts?
> >>>
> >>> [1] https://s.apache.org/0jdhc
> >>>
> >>>
> >>> Best regards,
> >>> Swapnil M Mane,
> >>> ofbiz.apache.org
> >>>
> >>>
> >>>
> >>> On Wed, Feb 26, 2020 at 3:24 PM GitBox  wrote:
> >>>
>  PierreSmits commented on issue #1: Improved: widget-theme.xsd typos
>  (OFBIZ-11421)
>  URL:
> https://github.com/apache/ofbiz-site/pull/1#issuecomment-591338641
> 
> 
>   Done.
> 
>  
>  This is an automated message from the Apache Git Service.
>  To respond to the message, please log on to GitHub and use the
>  URL above to go to the specific comment.
> 
>  For queries about this service, please contact Infrastructure at:
>  us...@infra.apache.org
> 
> 
>  With regards,
>  Apache Git Services
> 
> >>
>
>

Fwd: [apache/ofbiz-framework] OFBIZ-10565 Removing unused UI labels (#17)

Jacques,

Be happy with what you got! I would not want to burden you (or others) with
patches too large to check.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


-- Forwarded message -
From: Jacques Le Roux 
Date: Thu, Feb 27, 2020 at 10:14 AM
Subject: Re: [apache/ofbiz-framework] OFBIZ-10565 Removing unused UI labels
(#17)
To: apache/ofbiz-framework 
Cc: Pierre Smits , Author 


Hi Pierre,

I checked on trunk demo with the label manager for AccountingUiLabels.xml
and then by hand locally. At least the 5 1st ones reported by the label
manager are unused. Could you please check on your side and complete the
patch?
TIA

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
,
or unsubscribe

.

Re: [GitHub] [ofbiz-site] PierreSmits commented on issue #1: Improved: widget-theme.xsd typos (OFBIZ-11421)

Every Git PR also needs a Jira, for which the notifications go to the 
notifications mailing list.


If people want to contribute and follow, they should subscribe to 
notifications.


Maybe we should send a reminder and encourage them to do so instead of 
mixing notifications and dev again.


Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.02.20 um 09:54 schrieb Pierre Smits:

With the great difference between the numbers of subscribers of dev@ and
notifications@  (last time I checked notifications@ had around 50), I
advise against it.

If we want more people to contribute we need more than just the handful of
active committers/contributors and employees of system integrators, we need
to ensure that such notifications get sent to largest subset of our
community (dev@).

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Thu, Feb 27, 2020 at 9:33 AM Michael Brohl 
wrote:


+1, Thanks Swapnil!

Michael

Am 27.02.20 um 09:17 schrieb Swapnil M Mane:

Hi team,
Should we move these Git notification to notificati...@ofbiz.apache.org
list [1] that we created in the past to avoid notification traffic on dev
list, thoughts?

[1] https://s.apache.org/0jdhc


Best regards,
Swapnil M Mane,
ofbiz.apache.org



On Wed, Feb 26, 2020 at 3:24 PM GitBox  wrote:


PierreSmits commented on issue #1: Improved: widget-theme.xsd typos
(OFBIZ-11421)
URL: https://github.com/apache/ofbiz-site/pull/1#issuecomment-591338641


 Done.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services







smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GitHub] [ofbiz-site] PierreSmits commented on issue #1: Improved: widget-theme.xsd typos (OFBIZ-11421)

2020-02-27 Thread Suraj Khurana

+1 to move these git notifications.

We can use notificati...@ofbiz.apache.org for sure, at the same time, we
can have a separate list, if required.

--
Best Regards,
Suraj Khurana
www.hotwax.co

On Thu, Feb 27, 2020 at 1:48 PM Swapnil M Mane 
wrote:

> Hi team,
> Should we move these Git notification to notificati...@ofbiz.apache.org
> list [1] that we created in the past to avoid notification traffic on dev
> list, thoughts?
>
> [1] https://s.apache.org/0jdhc
>
>
> Best regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Wed, Feb 26, 2020 at 3:24 PM GitBox  wrote:
>
> > PierreSmits commented on issue #1: Improved: widget-theme.xsd typos
> > (OFBIZ-11421)
> > URL: https://github.com/apache/ofbiz-site/pull/1#issuecomment-591338641
> >
> >
> >Done.
> >
> > 
> > This is an automated message from the Apache Git Service.
> > To respond to the message, please log on to GitHub and use the
> > URL above to go to the specific comment.
> >
> > For queries about this service, please contact Infrastructure at:
> > us...@infra.apache.org
> >
> >
> > With regards,
> > Apache Git Services
> >
>

Re: [GitHub] [ofbiz-site] PierreSmits commented on issue #1: Improved: widget-theme.xsd typos (OFBIZ-11421)

2020-02-27 Thread Deepak Dixit

+1 Swapnil

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Thu, Feb 27, 2020 at 1:48 PM Swapnil M Mane 
wrote:

> Hi team,
> Should we move these Git notification to notificati...@ofbiz.apache.org
> list [1] that we created in the past to avoid notification traffic on dev
> list, thoughts?
>
> [1] https://s.apache.org/0jdhc
>
>
> Best regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Wed, Feb 26, 2020 at 3:24 PM GitBox  wrote:
>
> > PierreSmits commented on issue #1: Improved: widget-theme.xsd typos
> > (OFBIZ-11421)
> > URL: https://github.com/apache/ofbiz-site/pull/1#issuecomment-591338641
> >
> >
> >Done.
> >
> > 
> > This is an automated message from the Apache Git Service.
> > To respond to the message, please log on to GitHub and use the
> > URL above to go to the specific comment.
> >
> > For queries about this service, please contact Infrastructure at:
> > us...@infra.apache.org
> >
> >
> > With regards,
> > Apache Git Services
> >
>

Re: [GitHub] [ofbiz-site] PierreSmits commented on issue #1: Improved: widget-theme.xsd typos (OFBIZ-11421)

With modern day mail clients people can filter what and however they like.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Thu, Feb 27, 2020 at 9:54 AM Pierre Smits  wrote:

> With the great difference between the numbers of subscribers of dev@ and
> notifications@  (last time I checked notifications@ had around 50), I
> advise against it.
>
> If we want more people to contribute we need more than just the handful of
> active committers/contributors and employees of system integrators, we need
> to ensure that such notifications get sent to largest subset of our
> community (dev@).
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
>
>
> On Thu, Feb 27, 2020 at 9:33 AM Michael Brohl 
> wrote:
>
>> +1, Thanks Swapnil!
>>
>> Michael
>>
>> Am 27.02.20 um 09:17 schrieb Swapnil M Mane:
>> > Hi team,
>> > Should we move these Git notification to notificati...@ofbiz.apache.org
>> > list [1] that we created in the past to avoid notification traffic on
>> dev
>> > list, thoughts?
>> >
>> > [1] https://s.apache.org/0jdhc
>> >
>> >
>> > Best regards,
>> > Swapnil M Mane,
>> > ofbiz.apache.org
>> >
>> >
>> >
>> > On Wed, Feb 26, 2020 at 3:24 PM GitBox  wrote:
>> >
>> >> PierreSmits commented on issue #1: Improved: widget-theme.xsd typos
>> >> (OFBIZ-11421)
>> >> URL:
>> https://github.com/apache/ofbiz-site/pull/1#issuecomment-591338641
>> >>
>> >>
>> >> Done.
>> >>
>> >> 
>> >> This is an automated message from the Apache Git Service.
>> >> To respond to the message, please log on to GitHub and use the
>> >> URL above to go to the specific comment.
>> >>
>> >> For queries about this service, please contact Infrastructure at:
>> >> us...@infra.apache.org
>> >>
>> >>
>> >> With regards,
>> >> Apache Git Services
>> >>
>>
>>

Re: [GitHub] [ofbiz-site] PierreSmits commented on issue #1: Improved: widget-theme.xsd typos (OFBIZ-11421)

With the great difference between the numbers of subscribers of dev@ and
notifications@  (last time I checked notifications@ had around 50), I
advise against it.

If we want more people to contribute we need more than just the handful of
active committers/contributors and employees of system integrators, we need
to ensure that such notifications get sent to largest subset of our
community (dev@).

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Thu, Feb 27, 2020 at 9:33 AM Michael Brohl 
wrote:

> +1, Thanks Swapnil!
>
> Michael
>
> Am 27.02.20 um 09:17 schrieb Swapnil M Mane:
> > Hi team,
> > Should we move these Git notification to notificati...@ofbiz.apache.org
> > list [1] that we created in the past to avoid notification traffic on dev
> > list, thoughts?
> >
> > [1] https://s.apache.org/0jdhc
> >
> >
> > Best regards,
> > Swapnil M Mane,
> > ofbiz.apache.org
> >
> >
> >
> > On Wed, Feb 26, 2020 at 3:24 PM GitBox  wrote:
> >
> >> PierreSmits commented on issue #1: Improved: widget-theme.xsd typos
> >> (OFBIZ-11421)
> >> URL: https://github.com/apache/ofbiz-site/pull/1#issuecomment-591338641
> >>
> >>
> >> Done.
> >>
> >> 
> >> This is an automated message from the Apache Git Service.
> >> To respond to the message, please log on to GitHub and use the
> >> URL above to go to the specific comment.
> >>
> >> For queries about this service, please contact Infrastructure at:
> >> us...@infra.apache.org
> >>
> >>
> >> With regards,
> >> Apache Git Services
> >>
>
>

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #2


Hi Jacopo,

ok to proceed from my side.

We should move the open 17.12.01 issues to 17.12.02 then.

Thanks,

Michael


Am 27.02.20 um 09:21 schrieb Jacopo Cappellato:

Hi Michael, all,

please ping me when you want me to prepare the dist files for the new vote.

Thanks,

Jacopo


On Tue, Feb 25, 2020 at 1:24 PM Michael Brohl 
wrote:


We should wait with the preparation of a new dist at least until
tomorrow, the Community Days will end today and I am planning to do some
commits this evening.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.02.20 um 13:22 schrieb Michael Brohl:

+1

I already have changed the fix versions to 17.12.02 for fixes after
the dist preparation and would take care of changing them back to
17.12.01 then.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 25.02.20 um 11:48 schrieb Jacopo Cappellato:

Hi all!

Considering that during the last weekend (because of the Community
Day) a
series of bugs have been fixed in the 17.12 branch [*], I think it
would be
a good idea to cancel this vote, prepare new release files and start
a new
vote thread. Any objections?

Jacopo


[*] https://issues.apache.org/jira/projects/OFBIZ/versions/12347034


On Fri, Feb 21, 2020 at 9:24 AM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:


This is the vote thread (2nd attempt) to release "Apache OFBiz
17.12.01":
this is the first release, containing the framework, applications
and all
the plugins from the 17.12 release branches.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/

and are:
* apache-ofbiz-17.12.01.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.01.zip.asc: the detached signature file
* apache-ofbiz-17.12.01.zip.sha512: checksum file

Please download the zip file, build and test OFBiz and verify the
signature and checksum (for instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 17.12.01
[ -1] do not release

This vote will be open for 4 days.
For more details about this process please read
http://www.apache.org/foundation/voting.html








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GitHub] [ofbiz-site] PierreSmits commented on issue #1: Improved: widget-theme.xsd typos (OFBIZ-11421)


+1, Thanks Swapnil!

Michael

Am 27.02.20 um 09:17 schrieb Swapnil M Mane:

Hi team,
Should we move these Git notification to notificati...@ofbiz.apache.org
list [1] that we created in the past to avoid notification traffic on dev
list, thoughts?

[1] https://s.apache.org/0jdhc


Best regards,
Swapnil M Mane,
ofbiz.apache.org



On Wed, Feb 26, 2020 at 3:24 PM GitBox  wrote:


PierreSmits commented on issue #1: Improved: widget-theme.xsd typos
(OFBIZ-11421)
URL: https://github.com/apache/ofbiz-site/pull/1#issuecomment-591338641


Done.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GitHub] [ofbiz-site] PierreSmits commented on issue #1: Improved: widget-theme.xsd typos (OFBIZ-11421)