Re: Relation type in SecurityGroupPermission entity

[Julien NICOLAS]

+1


Le 22/09/2018 à 14:15, Deepak Nigam a écrit :

IMO, here the relation type should be 'one' here to maintain
the referential integrity. WDYT?

Re: [QUESTION] Should we not check fields consistency?

[Julien NICOLAS]

Hello

I've already implemented this kind of things and if you want to be 
exhaustive, you have to do it at least in service AND in UI.


However, it really depend on use cases that it depend on the customer 
tastes. When it depend on customer tastes, I prefer to keep it open in 
the framework / OOTB webapp than limit the OFBiz possibilities.


The only reason that we can do it is for legal locking features... 
but... it could depend on the country, so...


My 2 cents,

Julien.


Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
By root I mean the point where things begin. And for entering data for 
end users it all start in UI. If you can stop things at this level, 
you don't have to worry for sequel. That's what I mean by "root in 
UI". Maybe "seed in UI" would have been a better image :)


It would be more to prevent users's typo errors, fat fingers and such, 
without ambition to rule all cases, notably for later actions.


Rest inline...

Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :

I don't know what it means by the root in UI, but we are arriving at a
complex topic: Validation.

Yep, I know. Let's try to keep it as simple as possible


Validation is something that can happen on many levels like:
- entity definition level
- entity-auto level
- service level
- UI level
- route level

Each one of those has advantages and disadvantages. So I don't think
this is something we can make a rule for. What if a user wants to
enter a back-dated order?
Good question. They are cases, as in my examples, where common sense 
applies and there are no doubts (eg shipping before creating comes to 
mind). A case like you suggest should not stop us to think about all 
the others.



What if a user wants to be able to search
for a date range in the past,
That should not be a problem. It's all about keeping things 
consistent. For instance not reserving after shipping. I'm sure there 
are plenty other cases where common sense applies. I only speak about 
dates here, but I don't suggest to restrict only to date fields.
There also case where it's not as simple and then we need to think 
about it. In this case do you think at something particularly? An URL 
would help.



what if the site owner wants validation
on the service level for security because users can break out of
browser validation and enter a back-dated dates?
That's another topic I'd say. I'm not sure, but maybe we can enforce 
this rule, even on the client side.
To begin with baby steps, we should try to deliver common sense rules 
OOTB and let users adapt them to their needs.
Maybe we can even have a vision to help them. But my intention here is 
to keep things as simple as possible to begin.




I think this proposal needs more information and details. Otherwise
it's hard to determine what is the right decision as circumstances
vary widely
It was not a proposal so far, only a [QUESTION] to see if we are 
interested in researching this. I know it's not that simple, thank you 
for your questions. Let's see if others believe we should make it a 
[PROPOSAL]


Jacques


On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
 wrote:
It's only about checking at the root in UI when entering data and 
not let things go as long as the value is not correct


Jacques


Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :

Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam 
 wrote:

+1.

Thanks for the putting this forward. Please count me in for this 
effort.



Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 


wrote:


Hi,

I have always found that not having dates cross-checks in OFBiz 
is a minus.


For instance while creating/editing an order we can enter

    * an anti-dated shipping date (eg 2018-08-1 entered today)
    * The recently added reserved date can be after the shipping 
date

    * etc. (not only dates but mostly)

Should we not make an effort to check the consistency of fields 
values

when they are entered?

Because this is a simple question to see if we agree about making an
effort on that, I don't get into more details yet

Thanks for your opinions

Jacques

Re: Move accounting ap and ar to plugin ?

[Julien NICOLAS]

+1


Le 02/09/2018 à 10:36, Jacques Le Roux a écrit :
But do you really need to show all your medals in each email :) ? 

Re: [Proposal] Enhance the controller logic to accommodate HTTP methods and prepare for REST

[Julien NICOLAS]

+1 to move forward.

Julien.


Le 09/08/2018 à 17:31, Taher Alkhateeb a écrit :

Hello Everyone,

We want to make this formal with proper community consensus and I will
try to keep this short.

In [1] Mathieu Lirzin is providing some (in my opinion) good work on
converting the Control Servlet logic to be able to handle the
different HTTP methods (GET, POST, etc ...) The purpose of the work in
this JIRA is simple. You should be able to call a request with a
different HTTP methods by using a format like . You can find a more detailed discussion in [2]. This
is the first step of a multi-step process to be able to integrate REST
API with OFBiz.

So, this is a proposal to apply the following:
1- Enhance the controller to be able to accommodate one-or-more HTTP
methods (method="GET,POST")
2- Enhance the controller to further be able to get "patterns" that
can be mapped to REST APIs. So a request like
https://host/control/request/customer/orders/1/orderName can be
processed as a resource

Please correct me if I was wrong on anything written here Mathieu, and
please everyone provide your feedback if you approve of moving forward
with this initiative.

[1] https://issues.apache.org/jira/browse/OFBIZ-10438
[2] https://s.apache.org/ec2r

Re: Gradle, Less, Css : Transpile and minify

[Julien NICOLAS]

Yes, I can elaborate a better explanation. I would like to be sure that 
there is no historical mistake with the minified files before digging 
further.


I'll open a Jira and make an example to explain my proposal.

Regards,

Julien.


Le 27/08/2018 à 15:00, Taher Alkhateeb a écrit :

Can you elaborate on how you want to design this feature? Are you
going to minify the existing file or generate a new one. If you
generate a new one how will you update the screens to refer to the
minified version? Some elaboration on the design might help to make a
better decision here perhaps?
On Mon, Aug 27, 2018 at 3:20 PM Julien NICOLAS
 wrote:

Yes ! This is exactly what I have in mind ;)

Using this feature in production using Gulp, It's a pain when you have
to debbug in minified version.

Julien.


Le 27/08/2018 à 12:02, Mathieu Lirzin a écrit :

Hello Julien,

Julien NICOLAS  writes:


I would like to optimize css and less management using gradle.
I saw that some gradle plugins exists for transpilation (or
compilation...) less to css and minify and gzip css files.

What do you think if I try to set it in trunk ? I saw that a minifier
was already implemented in the past but was also removed. Is there any
technical reasons to remove minifier ?

I think it is a good idea.  However if we do that, it will be very
important to have a convenient way to run OFBiz either in development
mode (without minification) and in production mode (with minification)
to ease the Javascript debugging.  Since this is a very common
requirement, I guess those Gradle plugins already provide such facility
or describe how to customize the impacted tasks.

Thanks.

Re: Gradle, Less, Css : Transpile and minify

[Julien NICOLAS]

Yes ! This is exactly what I have in mind ;)

Using this feature in production using Gulp, It's a pain when you have 
to debbug in minified version.


Julien.


Le 27/08/2018 à 12:02, Mathieu Lirzin a écrit :

Hello Julien,

Julien NICOLAS  writes:


I would like to optimize css and less management using gradle.
I saw that some gradle plugins exists for transpilation (or
compilation...) less to css and minify and gzip css files.

What do you think if I try to set it in trunk ? I saw that a minifier
was already implemented in the past but was also removed. Is there any
technical reasons to remove minifier ?

I think it is a good idea.  However if we do that, it will be very
important to have a convenient way to run OFBiz either in development
mode (without minification) and in production mode (with minification)
to ease the Javascript debugging.  Since this is a very common
requirement, I guess those Gradle plugins already provide such facility
or describe how to customize the impacted tasks.

Thanks.

Gradle, Less, Css : Transpile and minify

[Julien NICOLAS]

Hi,

I would like to optimize css and less management using gradle.
I saw that some gradle plugins exists for transpilation (or 
compilation...) less to css and minify and gzip css files.


What do you think if I try to set it in trunk ? I saw that a minifier 
was already implemented in the past but was also removed. Is there any 
technical reasons to remove minifier ?


Let me know your opinions,

Regards,

Julien.

Re: [PROPOSITION] Demos: replace old by trunk framework only

[Julien NICOLAS]

Hi Nicolas,

With your proposal, I'm afraid that we can't simply add a new menu in an 
application from a plugin. Maybe it's another subject but it could be 
interesting to manage it in the same times.


Technically I understand your proposal but it's difficult for me to 
understand the impact ^^


Julien.


Le 23/08/2018 à 11:19, Nicolas Malin a écrit :

Hello

This thread about a "simple" problem highlights the difficulty for a 
plugin to extend the framework on different elements. Since many years 
I search different solution to how surcharge correctly the framework 
and it was not easy :)


in line

On 22/08/2018 18:52, Taher Alkhateeb wrote:

Hi Julien,

Good ideas, and this is a good start to try and tackle the problem.
Whatever we do, we must not keep "ghosts" or things that are waiting
for specific outside plugins. The framework should _never_ know
anything about the outside. This is a fundamental architectural
concept in any layered software system.
Absolutely right, I knew a ghost history with addons that changed 
source code base to load plugin's specificsinstead of understandingwhy 
we can't surcharge the framework :)

I'm ready to help if needed, and I think there are many ways to fix
this problem. As you said one way is to extend webapps, another is
perhaps to optionally include freemarker templates that match a
certain pattern if they exist. In other words, you provide a generic
plugin-like mechanism for enhancing the system, but the direction is
_always_ from the outside to the inside, and not the other way around.
And that is what I mean with a root-cause analysis and solutions.


Maybe I have two different solutions, based on theidea to usethemodel 
pattern toload all plugin surcharge at the ofbiz start like services 
and entities
* The first, load all screen engine modelsin memory at start, but I 
fearthatit would be too expensive on memory (load unnecessary screens)
* The second, create an'extend model' who permit to surcharge all 
screen engine model elements,andload it on ofbiz start and when we 
load a model, we check on extend model if the element have surcharge 
to apply just before settingit as immutable and put it in cache.


example :
name='ViewPartyGroup'>


target="/myplugin/control/viewprofile" target-type="inter-app" 
target-window="blank_">






With this, we would have a plugin that can surcharge a screen, a form, 
a menu without changingnothing in the framework, identify clearly what 
change has been made and a failure support when the extend can't be 
applied.


Currently I didn't found a solution to surcharge ftl.

If you feel that it's a good way to explore, I will start a new thread.

Nicolas

So I'm all for a generic solution, but not for hard-wiring any
component or any link that is specific to a certain component. That is
definitely a code smell and beats the entire purpose of splitting the
repositories in the first place. [...]

Re: [PROPOSITION] Demos: replace old by trunk framework only

[Julien NICOLAS]

Hi all,

My opinion is to hide the link instead of delete it. I don't know if we 
have other link in this case but it could be important to keep it in 
source code. It could be convenient to have it for replacement by the 
good solution


But in the same time, we need to think about inter-webapp connection. 
How a menu from webapp A could be extended by webapp B without putting 
code in webapp A.


It could be interesting to have a new tool bar in product to manage 
ecommerce when ecommerce is installed. If we have this kind of feature, 
it could work as well for OOTB webapp like product and stock, party and 
order, etc.


Julien.


Le 21/08/2018 à 10:10, Jacques Le Roux a écrit :
OK, that your and Michael's opinions. So you prefer NPEs in code than 
hiding them when necessary?


What others think?

Jacques


Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit :

Again, hiding is not a solution and is correcting an error with another
error.

-1

On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux 


wrote:

See my answer in the Jira, we can't tolerate NPEs, they are already 
there

for too long

Being smart is cool, being smart and clean is better ;)

Jacques


Le 21/08/2018 à 08:57, Michael Brohl a écrit :
We should neither simply remove those links nor should we have 
anything

hard coded.

Let's look for a smarter solution. No need to hurry, better take some

time to implement something sustainable.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 21.08.18 um 07:00 schrieb Jacques Le Roux:

Of course, but I like to be able to get from the backend to the

frontend when it's possible.

I don't see any troubles keeping them once it's handled that way, but

theoretical ones .

Of course if the community prefers to remove them it's far easier and
was what I wanted to do initially before having this idea of hiding 
links

Jacques


Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :

Simple, don't put any logic that points outwards from the framework.

That

is sort of why we split repositories in the first place.

On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
Makes sense. However, i note reading in the JIRA that "we can 
simply

hide
the button when the ecommerce component is not present". That 
sounds

like

logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.


Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques


On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the 
framework

only

and

the
framework+plugins

I must add:

 * since the old is often no longer supported and a 
release of

it is

always available (today R13) for users. I think removing the old

demo is

maybe
   not a big deal.
 * I found several cases where people, new to OFBiz, 
considered

OFBiz

as

what we call the framework, and were considering the plugins as

optional.

What do you think?

Jacques

Re: Rainbow themes: where are shown the "Last system notes"?

[Julien NICOLAS]

Yes, ML dev is my preferred ML ! And <3 OFBiz <3 my preferred community ;)


Le 16/08/2018 à 11:15, Jacques Le Roux a écrit :

Thanks Julien, great news :)

I'll create the Jira for the "Last system notes"

BTW I answered to the dev ML and put you in copy ;) Next time I'll 
only send to dev :) I guess you read it, right?


Jacques


Le 16/08/2018 à 09:42, Julien NICOLAS a écrit :

Ho! I just remove this "Last system notes"...

I totally forget this Jira ^^

I'll try to manage Last system notes and the other point asap.

Julien.


Le 16/08/2018 à 09:00, Jacques Le Roux a écrit :

Hi Julien,

When I created https://issues.apache.org/jira/browse/OFBIZ-6881 
"Rainbow Stone theme improvements" I put this point in the 
description: "Where are shown the "Last system notes"?"


I did not create a subtask for that. Maybe I forgot or maybe someone 
explained to me where to find them. Should I create a subtask? Are 
they visible somewhere?


Thanks

Jacques

Re: Website Translation in French need contributors

[Julien NICOLAS]

Hi Sharan, Olivier,

Sorry for the late answer, but actually I haven't lot of time for the 
project and I can't say that I'm ready to put energy in this french 
translation.


I'm still thinking that a local translation is a good idea but no time 
to spend in. I don't want to say count on me if you can't.


Regards,

Julien.

On 11/05/2018 10:36, Sharan Foga wrote:

Hi Olivier

I’ve just noticed this message and am surprised that there has been no 
responses on this thread, not even from Julien who originally suggested 
translating our website into French to take the place of the old OFBiz France 
website.

Anyway I personally would like to say thank you very much for spending your 
time and energy on this, and keeping this in synch for the last 6 months by 
yourself shows great commitment and perseverance  :-)

I know that this was done with the intention of helping support our project so 
without the support of at least some of our French committers or the 
Francophone community, I’m not sure that this can be progressed any further.

Does anyone else have any comments or feedback here?

Thanks
Sharan


On 2018/04/26 16:47:05, Olivier Heintz  wrote:

Hi all French contributors and committers and all others ;-)

I have create a JIRA to propose a French version of the Apache OFBiz website. 
(https://issues.apache.org/jira/browse/OFBIZ-9800)

The idea is to propose a French version which is just a perfect translation of 
the original content and doesn't introduce French specific content, to
avoid difficulties for reviewing it for most of the committers and PMC members.

A website translation is acceptable if and only if it is synchronized very 
rapidly, each time there is a commit on standard website.
For the last 6 month I have done the sync and it's not a big job, BUT, only one 
people is not enough for warrantee the it will be maintain in the futur

This mail is a call for contributors : who is ready to be record as a 
contributor on French translation of the Website ?
If there are enough people and the French website is publish,
a wiki page will be created with all the names and emails address to contact 
you directly if a commit on the website is not manage for the French
translation after 1 week.

Hoping a lot of of answer ;-)
Olivier

Re: [DISCUSSION] Inviting Paul Foxworthy as a PMC Member

[Julien NICOLAS]

After big foot, fat fingers...

I don't know what's next => Burn ! Malin ! Burn ! Burn !

:)

Julien.


On 02/03/2018 11:48, Nicolas Malin wrote:

:'( shit

My bad sorry for this crossposting a pb with my mailer cllient

Nicolas
On 02/03/2018 11:46, Nicolas Malin wrote:

+1

thanks Sharan for you proposition

Nicolas


On 02/03/2018 09:53, Sharan Foga wrote:

Hi All

I'd like to start a discussion about the possibility of inviting 
Paul Foxworthy to be a member of the PMC.


Paul has been around the project for over 7 years and a committer 
for over 5. He is active on the mailing list and Jira consistently 
providing great feedback and advice. He also participates in 
community votes etc. I like that he is open and happy to listen to 
and discuss potential solutions. I also like that he is willing to 
participate, critique and even change his mind to allow an 
initiative to move forward. He has some good financial knowledge 
which he shares, and also I think he was quite involved with the 
documentation framework discussions.


I think he would be a good person to have on the PMC. What do others 
think?


Thanks
Sharan

Re: Online help access in Rainbow themes

[Julien NICOLAS]

Hi,

My mistakes, I'll correct it asap ! (this afternoon probably)

Julien.

Le 13/02/2018 à 09:56, Sharan Foga a écrit :

Very good question. I'd like to know too!

Thanks
Sharan

On 2018/02/10 10:07:39, Jacques Le Roux  wrote:

Hi,

How, is it possible, to access the online help in Rainbow themes?

Thanks

Jacques

Re: Order : Communication between customer and product store

[Julien NICOLAS]

Hi Shi,

It's already the case you can find from/to fields :

    
    
    
    
    
    

Regards,

Julien.


On 03/01/2018 07:15, Shi Jinghai wrote:

Hi Julien,

In CommunicationEvent, it would be great if you can add a field to indicate the 
initial direction of a communication, i.e. Vendor to Customer, or Customer to 
Vendor.

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Julien NICOLAS [mailto:julien.nico...@nereide.fr]
发送时间: 2018年1月2日 21:15
收件人: OFBiz Dev
主题: Order : Communication between customer and product store

Hello,

First of all I wish you all, all the best for 2018 :)

We are working for a customer to add a communication management linked to 
orders between the customer and the product store.
It will use communication events and add a new communication screenlet at the 
bottom of the order screen of the back office.
We plan to commit modifications to the trunk.

If anybody have some suggestions about this point, don't hesitate to share, we 
will be pleased to fit to the community recommendations.

Kind regards,

Julien.

Re: Order : Communication between customer and product store

[Julien NICOLAS]

Yes!

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

;)


On 02/01/2018 19:03, Deepak Dixit wrote:

Nice idea Julien NICOLAS,
It would be good  if you open jira ticket for this improvement.

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

On Tue, Jan 2, 2018 at 6:45 PM, Julien NICOLAS <julien.nico...@nereide.fr>
wrote:


Hello,

First of all I wish you all, all the best for 2018 :)

We are working for a customer to add a communication management linked to
orders between the customer and the product store.
It will use communication events and add a new communication screenlet at
the bottom of the order screen of the back office.
We plan to commit modifications to the trunk.

If anybody have some suggestions about this point, don't hesitate to
share, we will be pleased to fit to the community recommendations.

Kind regards,

Julien.

Order : Communication between customer and product store

[Julien NICOLAS]

Hello,

First of all I wish you all, all the best for 2018 :)

We are working for a customer to add a communication management linked 
to orders between the customer and the product store.
It will use communication events and add a new communication screenlet 
at the bottom of the order screen of the back office.

We plan to commit modifications to the trunk.

If anybody have some suggestions about this point, don't hesitate to 
share, we will be pleased to fit to the community recommendations.


Kind regards,

Julien.

Re: Alternative UI using Vaadin as ofbiz user interface

[Julien NICOLAS]

Hi Marek,

Not sure that your message fit to this topics and to this mailing list.

I suggest you to create a new topics in the u...@ofbiz.apache.org

Regards,

Julien.


On 09/10/2017 09:27, Marek Mosiewicz wrote:

I'm sorry I accidentally send not finished message.


Concerning REALLY successful ERP there are currently some bad 
architectural descision taken in my opinion


In each existing ERP :


- Server side client rendering. I think there are existing 
technologies which enable client side logic. Java, Groovy, Scala each 
can be compiled to JS. That enables Logic shared on server and client. 
Simple thing recalculation of total and taxes on invoice could be done 
on focus lost or even on typing in would be done on Client. Client 
would have cache of data on server. It couled be done by Recalculation 
service which could be identical on server and client (Security), or 
client change log and reactive/rule logic


- Document oriented. No known open source ERP is document oriented. 
OfBiz has Order creation service in java which could be considered 
document orineted. But that should be for everyting. That simplifies 
client, makes it faster to fetch data, makes it easier for EDI. There 
could be also services for lines, but it should be possible to have it 
only for alterations


- Application dictionary. AFAIK application dictionary used in 
Compiere/Adempiere has IBM patent from 80's and should be now 
obsolate. Application dictionary makes it feel ERP better than 
creating access application. Compiere has one screen per table GUI AD, 
but it could be done to tree and had full power of GUI toolkit


- Web technology I consider Polymer or DOJO 2. They feel almost like 
desktop application


- DSL for appilcation dictionat. With Groovy or Scala you can create 
nice DSL for describing AD. It could be e.g adding new field to


other module module as plugin

- Dynamic with optional static typing. Dynamic is great fo small 
implementation vide plugins in Odoo. Same class could be gnereated 
(MDA) for enterprise implementation (much more fatster) and for 
developers (intelli sense). Groovy and scala has this feature.


- Command driven. It is rare for Java application to be command 
driven. If services are implemented in static language commands aka 
ofbiz services could be just annotated without any xml or dsl


- Standard commands for creating updateding deleteing should pass VO 
of document. Currently it is nightmare to add field to entity at it 
requires to change service paramters.



Is somebody interested to help me with creating prototype ?


Sincerly,

  Marek Mosiewicz



W dniu 2017-10-09 o 08:52, marekmosiew...@gmail.com pisze:


Hello everybody,

Concerning REALLY successful ERP there are currently some bad 
architectural descision taken


In each existing ERP :

 1. Server side client rendering. I think there are existing
    technologies which enable client side logic. Java, Groovy, Scala
    each can be compiled to JS. That enables

Logic shared on server and client. Simple thing recalculation of 
total and taxes on invoice could be done on focus lost or even on 
typing in would be done on


Client. Client would have cache of data on server. It couled be done 
by Recalculation service which could be identical on server and 
client (Security), or client


change log and reactive/rule logic

*From: *Hans Bakker 
*Sent: *poniedziałek, 9 października 2017 05:09
*To: *dev@ofbiz.apache.org ; Nicolas 
Malin 
*Cc: *wittawa...@gmail.com ; 
lathong...@gmail.com 

*Subject: *Re: Alternative UI using Vaadin as ofbiz user interface

Hi Nicolas,

i created https://issues.apache.org/jira/browse/OFBIZ-9831 for you

we are still working to improve the implementation.

if you have questions, let me know

we can also provide write access to our git repository

Thanks in advance for your help.

Regards,

Hans

On 30/09/17 01:05, Nicolas Malin wrote:

> Hi Hans,

>

> If it's too complicate for you to migrate your current works on the

> common-theme structure, please open an issue with your current patch I

> will check if it's possible to support it by common-theme or if the

> framework need some improvement to realize that.

>

> Cheers,

>

> Nicolas

>

>

> Le 19/09/2017 à 08:49, Jacques Le Roux a écrit :

>> Hi Hans,

>>

>> I'd then suggest to have a look at the common-theme Nicolas recently

>> introduced and how to use it with your Vaadin effort in order to not

>> have to change things in framework if possible

>>

>> Please check https://issues.apache.org/jira/browse/OFBIZ-9138

>>

>> Thanks

>>

>> Jacques

>>

>>

>> Le 19/09/2017 à 03:56, Hans Bakker a écrit :

>>> Hi Jacques,

>>>

>>> we currently create it as a plugin with some patches, but it 
would be


>>> nice to integrate it in the framework, so it can be used by all

Re: New ASF Members from OFBiz Community

[Julien NICOLAS]

Very good news !

Congrats Taher and Michael !

Julien.


On 03/04/2017 11:06, Sharan Foga wrote:

Hi Everyone

Please join me in congratulating Michael Brohl and Taher Alkhateeb as being 
invited to become members of the Apache Software Foundation.

Congratulations Michael and Taher!

Thanks
Sharan

Re: New Website Branch Created

[Julien NICOLAS]

Bonjour Sharan and the community,


I don't know if you prefer to open Jira about new website issue but I 
listed below what I found on a fast review. I think it could be a good 
thing to be able to assign task and to avoid double work on the same one.



1 - Multi-browser compatibility

I try it locally but it seems that the hover on the menu is not working 
on Firefox... Is anybody have the same trouble ?


I try on Chromium (Linux) and there is no problem to navigate between pages.


2 - External link

About the user experience and to be sure to not lost the user. I prefer 
to create a new tab when the user follow an external link (Twitter, 
blog, technical information, etc.)



3 - Typo

I found a typo on the "Go ahead and take OFBiz for a spin!" in this 
sentence :


All you _*is*_ need is to install the Java...

4 - wrong link

Link press is wrong (News)

Link User documentation is wrong (Documentation)

Link Source Repository is wrong (Community)

All link in Users is pointing to the same page.

Maybe I can help to correct issue (maybe browser compatibility ?).

Have a nice day,

Julien.



On 20/03/2017 13:54, Sharan Foga wrote:

Hi Everyone

A quick update. I've created a new branch called under the branches directory 
called ofbiz-new-website and have uploaded all the work done so far on the new 
website structure and pages.

The plan is to complete the work in this branch and then copy it over to the 
new site when we are ready. I think the content itself is the most important so 
will continue to to tidy up and complete any missing pages or information. It's 
in our repository now so hopefully more accessible to people who want to help 
out.

I'd encourage you all to take a look at what has been done to so that I can get 
some feedback of what people think of the general look and feel.

Once again – I'd like to thank Kenneth Paskett for helping out with the 
graphics.

Thanks
Sharan

Re: [PROPOSAL] Allow Blog Posts from Community Members on Official OFBiz Blog

[Julien NICOLAS]

+1


On 28/02/2017 04:23, Taher Alkhateeb wrote:

Hi Sharan,

You folks are doing a great job with the blog, so thank you. I would like
to make a distinction like you hinted between two categories of information:

1- News / success stories / community and project promotion
2- Advertisement / forks promotion / vendor promotion

Naturally I think we should be careful not to slip over time into the
second category.

With that being said I think it's a good idea

+1

On Feb 27, 2017 2:21 PM, "Sharan Foga"  wrote:


Hi All

Generally Michael, Jacques and I put together our monthly project blog
news updates. Our official blog also tends to include information about our
releases.

I've recently been sent a general blog post from Pranay, promoting OFBiz
that I think would be nice to post on our blog so this is the reason behind
the proposal.

I think that it could be a good thing to let the community know that if
they want to publish an article about the way they use OFBiz or anything
that could promote using it then it could be posted on the blog.

We could also perhaps include announcements from companies going live with
an OFBiz implementation. One thing we might want to be careful about though
is keeping things neutral and project focussed.

What do people think?

Thanks
Sharan

Re: [PROPOSAL] deprecate mini lang

[Julien NICOLAS]

+1


On 27/02/2017 13:44, Nicolas Malin wrote:

+1

I also agree to replace the minilang by groovy dsl for service.

For screen a prefer wait a good equivalent solution for simple case.

Nicolas


Le 18/02/2017 à 10:17, Michael Brohl a écrit :

Hi everyone,

we are currently working hard to make OFBiz a modern, quality, robust 
and easy to use framework.
There are several ongoing initiatives like refactoring the core, UX, 
changing the build and plugin system and cleaning up the javadocs, 
only to mention a few.


In mini lang I see another part of our project which needs a 
refactoring/change. Here are some reasons:


- Programming in XML is hard to deal with when it comes to refactoring.

- The "code" cannot be debugged and is hard to review and maintain.

- It is slower because of the overhead of parsing and processing XML 
documents


- It is highly verbose, even so more than Java!

- It is difficult to reason about because everything appears as a 
string (variables, maps, objects, etc ...) which makes it very 
difficult to know where something was declared or modified


- It is highly error prone and brittle (again due to string 
declarations)


- It is not a full programming language (unlike groovy, or any other 
language that supports a DSL). Thus it has many limitations that 
forces the developer to write many more lines of code to achieve the 
same result.


- The code is not reusable (limitation of the DSL)

- The code is not composable (limitation of the DSL)

- Minilang depends on a lot of Java constructs (implementations, not 
interfaces) that require refactoring, making any improvements to the 
core API more challenging


- Minilang is used inconsistently (different DSL in widgets, services 
and entities). Hence, we need to keep only a minimal DSL to declare 
things only.



We already have Java based implementations for services and events 
and there are ideas to implement a Groovy DSL which can be used as 
easy (or easier) as mini lang and does not have the above mentioned 
flaws.


I therefore like to propose to deprecate the mini lang implementation 
which means:


1. there will be no new implementations based on mini lang accepted 
to go into the code base.


2. mini lang and mini lang code will be maintained with bug and 
security fixes for backwards compatibility and to support existing 
adopters relying on mini lang.

   There will be no new features though.

3. we will continously replace the mini lang implementations with 
Java and/or Groovy code. This will be another good opportunity for 
contributors to engage in the project.



This will certainly be a longer process and we will not stop support 
for mini lang but I think we should avoid to add more mini lang 
implementations to the project.


What do you think?

Regards,

Michael

Re: Welcome Deepak Dixit as a new PMC member

[Julien NICOLAS]

Good news, congrats Deepak !

Julien.


On 24/02/2017 14:08, Jacques Le Roux wrote:
The OFBiz PMC has invited Deepak Dixit to become a new member of the 
committee; and the committee members are happy to announce that he has 
accepted.


Deepak has been involved in OFBiz for a long time now, and is a 
respected committer for 2 years.


We are sure Deepak will help us to take good decisions in favour of a 
bright future for OFBiz!


Please join me in welcoming and congratulating Deepak.

Thanks

Jacques
PS: Deepak, I let you change your status on the wiki PMC page :)

Re: About https://github.com/apache/ofbiz

[Julien NICOLAS]

+1


On 17/02/2017 14:21, Jacques Le Roux wrote:
I think we should remove a lot of useless and old confusing branches 
in svn 

Re: Welcome Swapnil Shah as a New Committer!

[Julien NICOLAS]

Congratulations Swapnil !


On 14/02/2017 12:00, Sharan Foga wrote:

The OFBiz PMC has invited Swapnil Shah to become a new committer and are happy 
to announce that he has accepted.

Swapnil has been involved in OFBiz for a few years and has been active on both 
the development and user mailing lists responding to some quite technical 
functional questions.

Some of the key factors considered for inviting him were as follows:

- He has very good functional knowledge about OFBiz and this is a valuable 
skill that is useful to developers and users
- He is polite, positive, friendly and collaborative when dealing the community 
discussions on the mailings lists or Jira
- He has raised Jiras, performed testing on patches and new other functionality
- The PMC would like to see a wide range of people from the community 
(developers and non-developers) recognised for their contributions to the 
project.

Please join me in welcoming and congratulating Swapnil.

Thanks
Sharan

Re: What is the "Apache OFBiz" product?

[Julien NICOLAS]

Hi Jacopo,

I'm not sure that ofbiz is an ERP. I mean I'm not sure that ofbiz is a 
turnkey solution. You can't just install the software and say "Let use 
it, it's ready!". We get our hands dirty before the final customer can 
use it serenely.


This is why I prefer the actual sentence "Apache OFBiz® is an open 
source product for the automation of enterprise processes that includes 
framework components and business applications"


I understand that is too long, this is why I suggest :

The "Apache OFBiz" framework

The "Apache OFBiz" web based application framework

Julien.

On 11/01/2017 14:51, Jacopo Cappellato wrote:

Any ideas? Please try to fill the  placeholder below with the string
that you find more suited:

  The "Apache OFBiz" 

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Hi Divesh,

As a first step, because we have a lot of work before starting UX part, 
I want to use POC to show how the screen structure (for find, entity 
details sheet, etc.) is important.


Nicolas start to create the common-theme and I start to make it blank. 
The theme without theme (with minimal UI) ;)


In that way, we will able to show how will work this structure screens. 
I'll to provide example to explain better my tough (I'll work on it this 
week-end).


Because the order process contain a lot of specific process that will be 
only used by the order process, I think that first components to be 
migrate will probably simple components. It will be faster and easier 
than the order process to show a new modern and UX user interface :)


What do you think ?

Julien.



On 08/12/2016 08:19, Divesh Dutta wrote:

Very good initiative. I see lots of discussions of technology part. So I
will not add on that part. I would like to give some inputs on our approach
to make UI/UX of OFBiz better.

As Jacopo also suggested to take small step at a time, I would say we start
with one use story at a time and then improve UI and UX of that story. For
example: "CSR creates a sales order". We overhaul UI and UX of sales order
creation work flow and Order over view page. Once this is done, it will be
good POC for others to learn how to do UI overhaul. And then others can
participate by picking up other user stories . We can also prioritise user
stories and components.

Besides this , before writing code, we can finalise UI and UX of one
workflow by drawing some thing or preparing wireframes. Once we have
wireframes finalised, we can start writing code.

This will be lot of work to change UI and UX of whole OFBiz and starting
one user story at at time is good idea according to me. Having technologies
defined is important thing, however defining UX for particular workflow (on
paper or via wireframes) is also important.

Thanks
--
Divesh Dutta.

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Thanks Taher,

Your explanations are sharper than mine, I was on the consistency 
benefit, you explain about technical benefits.


Anyway, I'll provide also the explanation drawing and screenshot of the 
UI consistency benefits. That is as important as the technical part :)


Have a nice day,

Julien.


On 07/12/2016 17:08, Taher Alkhateeb wrote:

I'm sure Julien has good ideas on how to move things about and I'll let gim
express those, I just want to add a conceptual frame for why probably both
Julien and myself sort of agree on the seperation of FTL templates from
screen widgets, so here goes ...

Aside from the great data model and service engine, OFBiz has something
which people like, which is the DSL. The DSL abstracts the database and
entities details. The DSL abstracts the services and their details. The DSL
also abstracts configuration. The same is exactly true for the user
interface.

Why do we have a DSL for entities?  because we want a simple unified
language that talks to all the different databases. Why do we have DSL for
services? Because we want a unified way of accessing them regardless of the
implementation programming language.

By the same logic, you want a unified simple DSL for creating the user
interface without worrying about the details of the output format whether
be it HTML, PDF, Swing, Text or something else.

When you define an entity do you go and mix The Entity definition in XML
with SQL statements? When you create a service definition do you put the
implementation inside that definition? I think the answer to both questions
is no correct?

So by the same philosophy and spirit of using the DSL everywhere in a pure
form and putting the implementation details "somewhere else", the same
should hold with the user interface.

So what are the benefits of this separation?

- Naturally you provide a simple DSL for people to quickly create a nice
user interface without having to know about all the intricacies of web
programming.
- you separate the definition from the implementation which allows you to
output to multiple formats without touching the widgets.
- you achieve modularity and avoid code repetition. You write every macro
once and only once. Then you use it everywhere indirectly through the
widgets.
- you achieve separation of concerns. You keep all the Technologies related
to web like CSS HTML and JavaScript in a separate location, while keeping
other logic like processing the DSL and parsing it and building the model
from it in another place.
- Changes to web frameworks become much easier (HTML 5? Angular, etc ...).
You can change that stuff without touching any of your widgets.

So the issue remaining is whether you folks believe it is worth the effort
and hard work to get this done. We leave that for the community to decide.

I certainly agree with Michael though that we should do this work in a
careful manner to minimize the transition pain for adopters of earlier
versions.

Cheers,

Taher Alkhateeb

On Dec 7, 2016 6:30 PM, "Michael Brohl" <michael.br...@ecomify.de> wrote:


Hi Julien,

thanks for your explanations.

It is indeed difficult to explain and understand, I suggest to provide
some kind of diagram or maybe some very simple examples, if you can.

Please also have in mind that we need to have a migration plan from old to
new and we should be able to run old and new in parallel for a while, at
least during one full release. We have some responsibility towards existing
users.

Thanks for your appreciated efforts,

Michael


Am 07.12.16 um 16:16 schrieb Julien NICOLAS:


It's a proposal for best practices, because of my own experience on
making new theme and the impact for a consistency UI.

For example, party details screen is a patchwork of xml screens and ftl
screens. If you manage to change the HTML structure of a form, it'll affect
only xml screen thanks to macro ftl. The pure ftl screen keep the old html
structure and you have to adapt your theme rendering to the html structure
of the ftl. It's a pity that we have to manage UI screen by screen.

There is no guidelines on how to make a good screen, and you can find for
the same usage ftl screen and xml screen with different UI... So, we lost
consistency. If we engage a new start for UI using guidelines, allow to
make ftl screen with new UI by new developer could be dangerous for
maintenance.

What I mean is not to forbid ftl screen, but to forbid it for common
screens that can be managed by xml structured screen in OOTB. In that way,
we keep the UI consistency in the OOTB.

It's difficult to explain well my tough, I hope to not made a
misunderstanding :)

Julien.


On 07/12/2016 14:45, Pierre Smits wrote:


I am wondering how to understand this:

better to not use ftl elsewhere than in macro

Is not every ftl template providing macro functionalities? Do you desire
that this project moves away from using ftl templates in any other place
than in a theme?

Best regards,


Pier

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Hi Michael,

I'll provide drawings and some examples to be clearer.

Anyway, we start a proof of concept to show pros and cons of our tough. 
It'll mustn't affect the good old fashion themes. The explanation about 
the guidelines will also not affect the old version, it's to be sure 
that our efforts will be not perverted by bad habits. Good practices or 
UI Guidelines could help to follow the good way to create screens ;)


Julien.


On 07/12/2016 16:29, Michael Brohl wrote:

Hi Julien,

thanks for your explanations.

It is indeed difficult to explain and understand, I suggest to provide 
some kind of diagram or maybe some very simple examples, if you can.


Please also have in mind that we need to have a migration plan from 
old to new and we should be able to run old and new in parallel for a 
while, at least during one full release. We have some responsibility 
towards existing users.


Thanks for your appreciated efforts,

Michael


Am 07.12.16 um 16:16 schrieb Julien NICOLAS:
It's a proposal for best practices, because of my own experience on 
making new theme and the impact for a consistency UI.


For example, party details screen is a patchwork of xml screens and 
ftl screens. If you manage to change the HTML structure of a form, 
it'll affect only xml screen thanks to macro ftl. The pure ftl screen 
keep the old html structure and you have to adapt your theme 
rendering to the html structure of the ftl. It's a pity that we have 
to manage UI screen by screen.


There is no guidelines on how to make a good screen, and you can find 
for the same usage ftl screen and xml screen with different UI... So, 
we lost consistency. If we engage a new start for UI using 
guidelines, allow to make ftl screen with new UI by new developer 
could be dangerous for maintenance.


What I mean is not to forbid ftl screen, but to forbid it for common 
screens that can be managed by xml structured screen in OOTB. In that 
way, we keep the UI consistency in the OOTB.


It's difficult to explain well my tough, I hope to not made a 
misunderstanding :)


Julien.


On 07/12/2016 14:45, Pierre Smits wrote:

I am wondering how to understand this:

better to not use ftl elsewhere than in macro

Is not every ftl template providing macro functionalities? Do you 
desire
that this project moves away from using ftl templates in any other 
place

than in a theme?

Best regards,


Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

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

On Wed, Dec 7, 2016 at 2:28 PM, Julien NICOLAS 
<julien.nico...@nereide.fr>

wrote:


If I understand well, yes.

All html structure must be managed by the theme. In OOTB, it could be
really better to not use ftl elsewhere than in macro. This is a way 
that

could be good to follow to have consistency for all screens in OFBiz.

Julien.


On 06/12/2016 11:59, Pierre Smits wrote:


So you are considering the following:

   ‘A more flexible and extensible approach is to use the FTL XML
processing
features directly instead of going through Java classes. With this
approach
adding an attribute or support for a whole new element in the 
widget XML
files is just a matter of adding it to the FTL macros that process 
XML

elements’


?

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>

OFBiz based solutions & services

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

On Fri, Dec 2, 2016 at 2:05 PM, Julien NICOLAS 
<julien.nico...@nereide.fr

wrote:

Pierre,
I don't know if we'll need it or not for now. There is so many 
thing to
define but it seems interesting. We will have to start this 
discussion on

the new theme topic.

Julien.



On 02/12/2016 11:55, pierre wrote:

Hi Julien
Is there any interest into the integration  of a java UI 
framework such

as vaadin?

regards,

Pierre


On 01/12/2016 23:26, Julien NICOLAS wrote:

Hi all,

I start a page about the POC for the UI improvement.

I'm not sure if the content is enough but I was wanted to 
create it.
We can now start some... Jira ? I was wondering one main Jira 
linked

to 4 other sub-jira.

thanks to those Jira, we can have 4 teams or workgroup to go 
ahead in

both ways.

https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement

Let me know if I'm doing well,

Kind regards,

Julien.

PS : I'm currently checkout the common-theme provided by Nicolas's
github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme)


On 28/11/2016 11:28, Sharan Foga wrote:

Hi Everyone
Another one of the topics that came up during the 
brainstorming in
Seville was around the UI. In fact we had at least 2 
presentations

from the OFBiz track at Apachecon that were about how we could
improve our UI.

If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and
simple, the other more advanced. (Our current UI could be the
advanced one?
- Separate the w

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

It's a proposal for best practices, because of my own experience on 
making new theme and the impact for a consistency UI.


For example, party details screen is a patchwork of xml screens and ftl 
screens. If you manage to change the HTML structure of a form, it'll 
affect only xml screen thanks to macro ftl. The pure ftl screen keep the 
old html structure and you have to adapt your theme rendering to the 
html structure of the ftl. It's a pity that we have to manage UI screen 
by screen.


There is no guidelines on how to make a good screen, and you can find 
for the same usage ftl screen and xml screen with different UI... So, we 
lost consistency. If we engage a new start for UI using guidelines, 
allow to make ftl screen with new UI by new developer could be dangerous 
for maintenance.


What I mean is not to forbid ftl screen, but to forbid it for common 
screens that can be managed by xml structured screen in OOTB. In that 
way, we keep the UI consistency in the OOTB.


It's difficult to explain well my tough, I hope to not made a 
misunderstanding :)


Julien.


On 07/12/2016 14:45, Pierre Smits wrote:

I am wondering how to understand this:

better to not use ftl elsewhere than in macro

Is not every ftl template providing macro functionalities? Do you desire
that this project moves away from using ftl templates in any other place
than in a theme?

Best regards,


Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

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

On Wed, Dec 7, 2016 at 2:28 PM, Julien NICOLAS <julien.nico...@nereide.fr>
wrote:


If I understand well, yes.

All html structure must be managed by the theme. In OOTB, it could be
really better to not use ftl elsewhere than in macro. This is a way that
could be good to follow to have consistency for all screens in OFBiz.

Julien.


On 06/12/2016 11:59, Pierre Smits wrote:


So you are considering the following:

   ‘A more flexible and extensible approach is to use the FTL XML
processing
features directly instead of going through Java classes. With this
approach
adding an attribute or support for a whole new element in the widget XML
files is just a matter of adding it to the FTL macros that process XML
elements’


?

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>

OFBiz based solutions & services

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

On Fri, Dec 2, 2016 at 2:05 PM, Julien NICOLAS <julien.nico...@nereide.fr
wrote:

Pierre,

I don't know if we'll need it or not for now. There is so many thing to
define but it seems interesting. We will have to start this discussion on
the new theme topic.

Julien.



On 02/12/2016 11:55, pierre wrote:

Hi Julien

Is there any interest into the integration  of a java UI framework such
as vaadin?

regards,

Pierre


On 01/12/2016 23:26, Julien NICOLAS wrote:

Hi all,

I start a page about the POC for the UI improvement.

I'm not sure if the content is enough but I was wanted to create it.
We can now start some... Jira ? I was wondering one main Jira linked
to 4 other sub-jira.

thanks to those Jira, we can have 4 teams or workgroup to go ahead in
both ways.

https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement

Let me know if I'm doing well,

Kind regards,

Julien.

PS : I'm currently checkout the common-theme provided by Nicolas's
github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme)


On 28/11/2016 11:28, Sharan Foga wrote:

Hi Everyone

Another one of the topics that came up during the brainstorming in
Seville was around the UI. In fact we had at least 2 presentations
from the OFBiz track at Apachecon that were about how we could
improve our UI.

If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and
simple, the other more advanced. (Our current UI could be the
advanced one?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not
mandatory and are just included as optional). What if we slimmed down
all the screens to have a sensible default UI for users. The UI could
also be modifiable by service providers. Simplify the screens with
defaults
- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there

What do people think?

-Do people think it would be a good idea to have 2 versions of the
UI? (a simple one and a more advanced one?)

- Are these the things we would need to focus on or have in place if
we wanted to focus on the UI?

(Also I know Nicolas has mentioned that he has already started work
on a Proof of Concept for a common theme  - so do we need to make
sure we agree conventions etc before much more work is done?)

Thanks
Sharan

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

If I understand well, yes.

All html structure must be managed by the theme. In OOTB, it could be 
really better to not use ftl elsewhere than in macro. This is a way that 
could be good to follow to have consistency for all screens in OFBiz.


Julien.


On 06/12/2016 11:59, Pierre Smits wrote:

So you are considering the following:

  ‘A more flexible and extensible approach is to use the FTL XML processing
features directly instead of going through Java classes. With this approach
adding an attribute or support for a whole new element in the widget XML
files is just a matter of adding it to the FTL macros that process XML
elements’


?

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

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

On Fri, Dec 2, 2016 at 2:05 PM, Julien NICOLAS <julien.nico...@nereide.fr>
wrote:


Pierre,

I don't know if we'll need it or not for now. There is so many thing to
define but it seems interesting. We will have to start this discussion on
the new theme topic.

Julien.



On 02/12/2016 11:55, pierre wrote:


Hi Julien

Is there any interest into the integration  of a java UI framework such
as vaadin?

regards,

Pierre


On 01/12/2016 23:26, Julien NICOLAS wrote:


Hi all,

I start a page about the POC for the UI improvement.

I'm not sure if the content is enough but I was wanted to create it.
We can now start some... Jira ? I was wondering one main Jira linked
to 4 other sub-jira.

thanks to those Jira, we can have 4 teams or workgroup to go ahead in
both ways.

https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement

Let me know if I'm doing well,

Kind regards,

Julien.

PS : I'm currently checkout the common-theme provided by Nicolas's
github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme)


On 28/11/2016 11:28, Sharan Foga wrote:


Hi Everyone

Another one of the topics that came up during the brainstorming in
Seville was around the UI. In fact we had at least 2 presentations
from the OFBiz track at Apachecon that were about how we could
improve our UI.

If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and
simple, the other more advanced. (Our current UI could be the
advanced one?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not
mandatory and are just included as optional). What if we slimmed down
all the screens to have a sensible default UI for users. The UI could
also be modifiable by service providers. Simplify the screens with
defaults
- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there

What do people think?

-Do people think it would be a good idea to have 2 versions of the
UI? (a simple one and a more advanced one?)

- Are these the things we would need to focus on or have in place if
we wanted to focus on the UI?

(Also I know Nicolas has mentioned that he has already started work
on a Proof of Concept for a common theme  - so do we need to make
sure we agree conventions etc before much more work is done?)

Thanks
Sharan

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Pierre,

I don't know if we'll need it or not for now. There is so many thing to 
define but it seems interesting. We will have to start this discussion 
on the new theme topic.


Julien.


On 02/12/2016 11:55, pierre wrote:

Hi Julien

Is there any interest into the integration  of a java UI framework 
such as vaadin?


regards,

Pierre


On 01/12/2016 23:26, Julien NICOLAS wrote:

Hi all,

I start a page about the POC for the UI improvement.

I'm not sure if the content is enough but I was wanted to create it.
We can now start some... Jira ? I was wondering one main Jira linked
to 4 other sub-jira.

thanks to those Jira, we can have 4 teams or workgroup to go ahead in
both ways.

https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement

Let me know if I'm doing well,

Kind regards,

Julien.

PS : I'm currently checkout the common-theme provided by Nicolas's
github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme)


On 28/11/2016 11:28, Sharan Foga wrote:

Hi Everyone

Another one of the topics that came up during the brainstorming in
Seville was around the UI. In fact we had at least 2 presentations
from the OFBiz track at Apachecon that were about how we could
improve our UI.

If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and
simple, the other more advanced. (Our current UI could be the
advanced one?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not
mandatory and are just included as optional). What if we slimmed down
all the screens to have a sensible default UI for users. The UI could
also be modifiable by service providers. Simplify the screens with
defaults
- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there

What do people think?

-Do people think it would be a good idea to have 2 versions of the
UI? (a simple one and a more advanced one?)

- Are these the things we would need to focus on or have in place if
we wanted to focus on the UI?

(Also I know Nicolas has mentioned that he has already started work
on a Proof of Concept for a common theme  - so do we need to make
sure we agree conventions etc before much more work is done?)

Thanks
Sharan

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Hi all,

I start a page about the POC for the UI improvement.

I'm not sure if the content is enough but I was wanted to create it. We 
can now start some... Jira ? I was wondering one main Jira linked to 4 
other sub-jira.


thanks to those Jira, we can have 4 teams or workgroup to go ahead in 
both ways.


https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement

Let me know if I'm doing well,

Kind regards,

Julien.

PS : I'm currently checkout the common-theme provided by Nicolas's 
github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme)



On 28/11/2016 11:28, Sharan Foga wrote:

Hi Everyone

Another one of the topics that came up during the brainstorming in Seville was 
around the UI. In fact we had at least 2 presentations from the OFBiz track at 
Apachecon that were about how we could improve our UI.

If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and simple, the 
other more advanced. (Our current UI could be the advanced one?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not mandatory and are 
just included as optional). What if we slimmed down all the screens to have a 
sensible default UI for users. The UI could also be modifiable by service 
providers. Simplify the screens with defaults
- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there

What do people think?

-Do people think it would be a good idea to have 2 versions of the UI? (a 
simple one and a more advanced one?)

- Are these the things we would need to focus on or have in place if we wanted 
to focus on the UI?

(Also I know Nicolas has mentioned that he has already started work on a Proof 
of Concept for a common theme  - so do we need to make sure we agree 
conventions etc before much more work is done?)

Thanks
Sharan

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

This proposal is a package, this work is link to another big (huge) task 
to rebuild the entire UI \o/


It always start with a first step, this is it ;)

Julien.


On 01/12/2016 09:36, Jacques Le Roux wrote:
At least by review in new committed code. It would not be impossible 
technically but very difficult to enforce else, I mean in not OOTB 
code (just a thought)


Also we have still to discuss if we will apply to all existing code or 
if it will be only applied alongside in the "other" way (which still 
need to be clarified/defined)


I think the best is to review the POC Nicolas provided in his GitHub 
account. I did not get a chance yet, so I was mostly asking to better 
understand the proposition


Jacques


Le 30/11/2016 à 21:16, Pierre Smits a écrit :

So when you speak of

a super-structure that will be used in place of currently conventions 
which

are not always respected

how do you envision that with that new 'super-structure' conventions 
will

be respected?

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

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

On Wed, Nov 30, 2016 at 9:00 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Julien

Inline ...

Le 30/11/2016 à 10:02, Julien NICOLAS a écrit :


Hi Jacques,


On 30/11/2016 08:51, Jacques Le Roux wrote:


  - Each screen must be linked to a screen structure.

What would be this screen structure? You don't need to develop 
much at

this stage, just that I can't vision what it would be.

This structure is to follow the a UI standard that can be managed 
by the

theme. For example, the find screen can be define as :
  - A research field area
  - A result area


Ah, I see, we have already this concept in screen widget.



If all the find screen could be linked to this structure, it will be
easier for theme to manage it's own template of search screen.

You mean that it would be a super-structure that will be used in 
place of

currently conventions which are not always respected, I see.

It will be included in the main decorator that will also linked to a
structure, so theme can manage to change the template. And when you 
change

the theme, it could be a completely different look and feel :)
I hope I explain well my thought.


Got it, thanks :)



Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI 
is too
heavy. Then I was thinking that I have to improve the UI to 
provide a best
one. After several try I understand that the actual UI is not a 
final user
interface. It is a developer one. It's a developer UI because it 
contain
all the features developed. But definitively, we can't provide 
this kind of
UI to final users, we have to simplify it. In the same times, we 
can't

delete the current UI because developers need to improve it with new
features that will help us to deploy new features to our final 
users.


For this new component, we can implement an existing component but
simplified and ready for the new theme(s).

You mean we could take and existing component, say example for 
instance,
and would simply it at the UI level. I picked example because it's 
already

rather simple and contains demonstration of features.

No, I mean to define a component (party, product, facility, etc.) 
that we
start to re-implement (using the existing services) but in a more 
simple

way (without all the features, selecting only the main ones).


I see



In conclusion, if the new component dedicated for test a new theme
match to the community needs, Taher think to a super simplified 
developer
user interface that facilitate developers to improve the 
software. A new
interface without any constraint that allow developers to develop 
easily

new features.


Another thing I can't vision at this stage, no hurry, I guess I'll 
later

:)

Yes, too many thing to explain, I have to add details about this 
point,

I'll do it soon ^^


I did not get a chance to look yet at the POC Nicolas, Gil and you are
working on. I guess I'd get the ideas from there then?

Thanks

Jacques

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Hi Pierre,

I hope that, like code source convention, people will respect the work 
done and respect people behind them.


I think that I'll do my best to explain the reason of the work I'll 
begin, hope that it will be accepted by the community, hope that it will 
be implemented in all OFBiz screens. I know that the OFBiz community are 
good people and respect that.


But you true, it could happens that somebody fail to follow rules, I 
hope I see it in code review and ask for an update ;)


I'm quite sure that when you'll be charmed by this UI standard, you'll 
be also a rules keeper <3


Have a nice day,

Julien.


On 30/11/2016 21:16, Pierre Smits wrote:

So when you speak of

a super-structure that will be used in place of currently conventions which
are not always respected

how do you envision that with that new 'super-structure' conventions will
be respected?

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

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

On Wed, Nov 30, 2016 at 9:00 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Julien

Inline ...

Le 30/11/2016 à 10:02, Julien NICOLAS a écrit :


Hi Jacques,


On 30/11/2016 08:51, Jacques Le Roux wrote:


  - Each screen must be linked to a screen structure.

What would be this screen structure? You don't need to develop much at
this stage, just that I can't vision what it would be.


This structure is to follow the a UI standard that can be managed by the
theme. For example, the find screen can be define as :
  - A research field area
  - A result area


Ah, I see, we have already this concept in screen widget.



If all the find screen could be linked to this structure, it will be
easier for theme to manage it's own template of search screen.


You mean that it would be a super-structure that will be used in place of
currently conventions which are not always respected, I see.

It will be included in the main decorator that will also linked to a

structure, so theme can manage to change the template. And when you change
the theme, it could be a completely different look and feel :)
I hope I explain well my thought.


Got it, thanks :)



Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI is too
heavy. Then I was thinking that I have to improve the UI to provide a best
one. After several try I understand that the actual UI is not a final user
interface. It is a developer one. It's a developer UI because it contain
all the features developed. But definitively, we can't provide this kind of
UI to final users, we have to simplify it. In the same times, we can't
delete the current UI because developers need to improve it with new
features that will help us to deploy new features to our final users.

For this new component, we can implement an existing component but
simplified and ready for the new theme(s).


You mean we could take and existing component, say example for instance,
and would simply it at the UI level. I picked example because it's already
rather simple and contains demonstration of features.


No, I mean to define a component (party, product, facility, etc.) that we
start to re-implement (using the existing services) but in a more simple
way (without all the features, selecting only the main ones).


I see



In conclusion, if the new component dedicated for test a new theme
match to the community needs, Taher think to a super simplified developer
user interface that facilitate developers to improve the software. A new
interface without any constraint that allow developers to develop easily
new features.



Another thing I can't vision at this stage, no hurry, I guess I'll later
:)


Yes, too many thing to explain, I have to add details about this point,
I'll do it soon ^^


I did not get a chance to look yet at the POC Nicolas, Gil and you are
working on. I guess I'd get the ideas from there then?

Thanks

Jacques

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Yes, I agree, let's make it simple for the POC.


On 30/11/2016 11:07, Jacopo Cappellato wrote:

Amazing discussion and initiative.
​My only recommendation at the moment is to try to plan very short (in
scope and in time) development cycles (requirements gathering and
discussion, design, implementation, review) so that each cycle could focus
on a specific experiment/proposal (e.g. a given ui technology) and could
deliver a proof of concept to the community (e.g. as a new component) for
further discussion and work.

In this way we will be able to quickly implement and compare different
solutions/technologies and will have a chance to take a more informed
decision.

Jacopo

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Hi Jacques,


On 30/11/2016 08:51, Jacques Le Roux wrote:

Hi Julien,

Just few questions inline


Le 29/11/2016 à 23:35, Julien NICOLAS a écrit :

Hi Sharan, everyone,

It was idea like seed that start to grow up in my mind since I start 
with OFBiz. Today, after several try on the project I think the 
community is very closed to find the best way to improve the UI.


The first sharing was with Gil and Nicolas, then we decide to submit 
a talk about that. The big surprise was that Taher have the quite 
same ideas than us !!!


There are many things that must be done to have a good UI.

 - All the UI could be managed by the theme without modifying the 
framework.


 - Each screen must be linked to a screen structure.


What would be this screen structure? You don't need to develop much at 
this stage, just that I can't vision what it would be.
This structure is to follow the a UI standard that can be managed by the 
theme. For example, the find screen can be define as :

 - A research field area
 - A result area

If all the find screen could be linked to this structure, it will be 
easier for theme to manage it's own template of search screen.
It will be included in the main decorator that will also linked to a 
structure, so theme can manage to change the template. And when you 
change the theme, it could be a completely different look and feel :)

I hope I explain well my thought.




 - We need a UI standard that the developer need to follow for screen 
creation.


 - We must have a common theme (remove all theming stuff from the 
framework)


 - It could be interesting to have a new component to improve / test 
a new theme


 - We have to create at least a new theme without limits ! Be crazy !

It's a long term project, but it must be our concern, all the people 
that want a beautiful and UX UI must be involved \o/ I remember when 
I start bootstrap topics, that we were many ;)


This project is more ambitious, a long term one that will improve the 
theming automatism to provide to the webdesigner an unlimited tool 
and, in the same time, an easy to maintain framework for us ;)



Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI is 
too heavy. Then I was thinking that I have to improve the UI to 
provide a best one. After several try I understand that the actual UI 
is not a final user interface. It is a developer one. It's a 
developer UI because it contain all the features developed. But 
definitively, we can't provide this kind of UI to final users, we 
have to simplify it. In the same times, we can't delete the current 
UI because developers need to improve it with new features that will 
help us to deploy new features to our final users.


For this new component, we can implement an existing component but 
simplified and ready for the new theme(s).


You mean we could take and existing component, say example for 
instance, and would simply it at the UI level. I picked example 
because it's already rather simple and contains demonstration of 
features.
No, I mean to define a component (party, product, facility, etc.) that 
we start to re-implement (using the existing services) but in a more 
simple way (without all the features, selecting only the main ones).




In conclusion, if the new component dedicated for test a new theme 
match to the community needs, Taher think to a super simplified 
developer user interface that facilitate developers to improve the 
software. A new interface without any constraint that allow 
developers to develop easily new features.




Another thing I can't vision at this stage, no hurry, I guess I'll 
later :)
Yes, too many thing to explain, I have to add details about this point, 
I'll do it soon ^^


All the rest is OK with me, or at least I think I did grab the ideas

Thanks!

Jacques



What about the new theme ?

A new theme, maybe more than one theme. It could be crazy but if we 
need to be sure that we can do anything we want and that the screen 
structure allow webdesigner to do whatever we want, we can imagine 2 
new themes exactly different in structure :)


I have at least an idea, just for the look and feel. I can share it 
and we can improve it all together (or just scrap it and start with a 
new idea ^^). In the same times, at the Apache Con we meet Victoria 
Bondarchuk 
<http://events.linuxfoundation.org/events/apachecon-europe/program/schedule> 
(work in UX project management) that want to help us in this task, 
and Darshan Kumar (work also in UX) who want to join the OFBiz 
project starting on that task.



How to start ?

I propose to start by creating a main Jira about Improve the UI 
(maybe this one already exist since a long long time ago ^^) and then 
link all the subtasks to this main one. Maybe we can start a topic by 
subtask to share with the community.



Before creating anything it could be interesting to have opinion of 
all people who want UI changes. All the commu

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Hi Sharan, everyone,

It was idea like seed that start to grow up in my mind since I start 
with OFBiz. Today, after several try on the project I think the 
community is very closed to find the best way to improve the UI.


The first sharing was with Gil and Nicolas, then we decide to submit a 
talk about that. The big surprise was that Taher have the quite same 
ideas than us !!!


There are many things that must be done to have a good UI.

 - All the UI could be managed by the theme without modifying the 
framework.


 - Each screen must be linked to a screen structure.

 - We need a UI standard that the developer need to follow for screen 
creation.


 - We must have a common theme (remove all theming stuff from the 
framework)


 - It could be interesting to have a new component to improve / test a 
new theme


 - We have to create at least a new theme without limits ! Be crazy !

It's a long term project, but it must be our concern, all the people 
that want a beautiful and UX UI must be involved \o/ I remember when I 
start bootstrap topics, that we were many ;)


This project is more ambitious, a long term one that will improve the 
theming automatism to provide to the webdesigner an unlimited tool and, 
in the same time, an easy to maintain framework for us ;)



Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI is too 
heavy. Then I was thinking that I have to improve the UI to provide a 
best one. After several try I understand that the actual UI is not a 
final user interface. It is a developer one. It's a developer UI because 
it contain all the features developed. But definitively, we can't 
provide this kind of UI to final users, we have to simplify it. In the 
same times, we can't delete the current UI because developers need to 
improve it with new features that will help us to deploy new features to 
our final users.


For this new component, we can implement an existing component but 
simplified and ready for the new theme(s).


In conclusion, if the new component dedicated for test a new theme match 
to the community needs, Taher think to a super simplified developer user 
interface that facilitate developers to improve the software. A new 
interface without any constraint that allow developers to develop easily 
new features.



What about the new theme ?

A new theme, maybe more than one theme. It could be crazy but if we need 
to be sure that we can do anything we want and that the screen structure 
allow webdesigner to do whatever we want, we can imagine 2 new themes 
exactly different in structure :)


I have at least an idea, just for the look and feel. I can share it and 
we can improve it all together (or just scrap it and start with a new 
idea ^^). In the same times, at the Apache Con we meet Victoria 
Bondarchuk 
 
(work in UX project management) that want to help us in this task, and 
Darshan Kumar (work also in UX) who want to join the OFBiz project 
starting on that task.



How to start ?

I propose to start by creating a main Jira about Improve the UI (maybe 
this one already exist since a long long time ago ^^) and then link all 
the subtasks to this main one. Maybe we can start a topic by subtask to 
share with the community.



Before creating anything it could be interesting to have opinion of all 
people who want UI changes. All the community I think, so I hope server 
will not be down because of the OFBiz community involving ^^


I hope Paul, Gaurav and all the people that try or already improve the 
UI will help on this task \o/


I want to be an actor of this changes and I hope you want it too !

Thanks for all your help in advance.

Julien.


On 28/11/2016 11:28, Sharan Foga wrote:

Hi Everyone

Another one of the topics that came up during the brainstorming in Seville was 
around the UI. In fact we had at least 2 presentations from the OFBiz track at 
Apachecon that were about how we could improve our UI.

If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and simple, the 
other more advanced. (Our current UI could be the advanced one?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not mandatory and are 
just included as optional). What if we slimmed down all the screens to have a 
sensible default UI for users. The UI could also be modifiable by service 
providers. Simplify the screens with defaults
- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there

What do people think?

-Do people think it would be a good idea to have 2 versions of the UI? (a 
simple one and a more advanced one?)

- Are these the things we would need to focus on or have in place if we 

Re: Creating a new release branch in preparation for the new release

[Julien NICOLAS]

hello,

I want to improve less file for Rainbowstone and add a new feature in 
the main menu (both already approved by our customers), I'll schedule to 
do it for this week-end, if you can wait until monday, I'll really happy ^^


Thanks!

Julien.


On 27/10/2016 14:20, Jacopo Cappellato wrote:

Thank you Jacques, I agree that delaying of 1-2 weeks would not be a big
deal.
If anyone is planning to contribute improvements in the next 1-2 weeks then
please speak up and we could definitely wait for them.

Jacopo

On Thu, Oct 27, 2016 at 1:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Jacopo, All.

Are there no major improvements that we would wish to have before cutting
the branch?

I personally don't remember any. But with the 6 last months turmoil we
increased from around 0 issues created vs resolved to 1840 created and 1447
resolved.
So we have now a differential of around 400 issues pending for resolution.
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12310800
I know that most of them are minor subtasks, and it's hard to follow the
flow.

Anyway if you wait for an improvement it's the moment to raise a hand

Thanks

Jacques



Le 24/10/2016 à 10:40, Jacopo Cappellato a écrit :


Ok, it is probably time to proceed with this plan:
1) create a new release branch named "release16.10"
2) the target goal could be that of issuing a release out of it sometime
in
the next month ("Apache OFBiz 16.10.01")

Jacopo

On Wed, Sep 7, 2016 at 1:26 PM, Taher Alkhateeb <
slidingfilame...@gmail.com>
wrote:

+1

On Wed, Sep 7, 2016 at 2:07 PM, Sharan Foga 
wrote:

That's great news !  +1

Thanks
Sharan


On 07/09/16 12:06, Jacopo Cappellato wrote:

Hi all,

I think it is the right time to create a new release branch out of the
trunk.

According to our naming conventions the release will be named
"release16.09".

Any objections or concerns? If not, I will create the branch later
today/tomorrow.

After that we will start, in a separate thread, the discussion about
the
preparation of our first release out of this branch.

Thanks,

Jacopo

Re: [VOTE] Put the Rainbow Stone - Ruby theme in Attic

[Julien NICOLAS]

Hello Taher,

It's easy to merge color thanks to less files.

Structurally, it's the same theme, only seed data is different to 
include less file that contain color definition. There is not 4 themes 
but 1 theme and 4 colours.


Actually, the colours less file need to be improved (already done on 
customer site) but it's not really difficult.


Julien.

On 24/09/2016 08:03, Taher Alkhateeb wrote:

-1

I cannot agree without first understanding the architectural design and
implications of how all rainbow themes are designed and connected. This
vote does not seem to be thoroughly thought out in terms of the
architectural implications and whether alternatives to deletion (merging,
sub-theming) are possible.

On Sep 24, 2016 8:18 AM, "Nicolas Malin"  wrote:


0

because we can merge all rainbow Stone on one theme


Le 23/09/2016 à 13:11, Jacques Le Roux a écrit :


Do you want to put the Rainbow Stone - Ruby theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for
more information

+1 (means put the theme in Attic)
  0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016
13:00 UTC+1.

Jacques

Re: [VOTE] Put the Rainbow Stone - Amber theme in Attic

[Julien NICOLAS]

-1


On 23/09/2016 13:11, Jacques Le Roux wrote:

Do you want to put the Rainbow Stone - Amber theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: [VOTE] Put the Rainbow Stone - Saphir theme in Attic

[Julien NICOLAS]

-1


On 23/09/2016 13:11, Jacques Le Roux wrote:

Do you want to put the Rainbow Stone - Saphir theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: [VOTE] Put the Rainbow Stone - Ruby theme in Attic

[Julien NICOLAS]

-1


On 23/09/2016 13:11, Jacques Le Roux wrote:

Do you want to put the Rainbow Stone - Ruby theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: [VOTE] Put the Rainbow Stone - Emeral theme in Attic

[Julien NICOLAS]

-1


On 23/09/2016 13:12, Jacques Le Roux wrote:

Do you want to put the  Rainbow Stone - Emeral  theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: [VOTE] Put the bizzness time theme in Attic

[Julien NICOLAS]

+1


On 23/09/2016 13:11, Jacques Le Roux wrote:

Do you want to put the  bizzness time theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: [VOTE] Put the BlueLight theme in Attic

[Julien NICOLAS]

+1


On 23/09/2016 13:11, Jacques Le Roux wrote:

Do you want to put the BlueLight theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: [VOTE] Put the Dropping Crumbs theme in Attic

[Julien NICOLAS]

+1


On 23/09/2016 13:11, Jacques Le Roux wrote:

Do you want to put the Dropping Crumbs theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: [VOTE] Put the Tomahawk theme in Attic

[Julien NICOLAS]

+1


On 23/09/2016 13:11, Jacques Le Roux wrote:

Do you want to put the Tomahawk theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: [VOTE] Put the Flatgrey theme in Attic

[Julien NICOLAS]

+1


On 23/09/2016 14:04, Jacques Le Roux wrote:

Do you want to put the Flatgrey theme in Attic?

Please refer to https://issues.apache.org/jira/browse/OFBIZ-8293 for 
more information


+1 (means put the theme in Attic)
 0 (means vote abstention)
-1 (means don't put the theme in Attic)

Voting time frame is finished 72 hours from now until Mon Sep 26 2016 
13:00 UTC+1.


Jacques

Re: Preliminary question about themes before possible votes

[Julien NICOLAS]

Hi Jacques,

I agree that it's important to remove themes from the framework (keep at 
least one is important ^^ ).


But you don't mention what's happening with theme that is not in the 
OOTB. I think it could be available from public repository instead of 
simply deleted.


For me pors is to stop to maintain outdated theme that is never used. We 
can focus on one theme and go further to upgrade the theme management 
(and rendering management).


Julien.

On 21/09/2016 18:35, Jacques Le Roux wrote:
Ah something I missed to precise: it's not about giving arguments, pro 
or cons. It's only about taking decisions, so again: please stay focused.


Thanks

Jacques


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

Hi All,

At OFBIZ-8293 we began to informally discuss about reducing the 
number of OOTB themes. But we could clearly agree and believe a vote 
is better/


1. Now the 1st question which has been already discussed several time 
without a clear decision in this ML:

   do we, as a community, want to reduce the number  of themes?
   Should we vote on that before starting votes on or a lazy 
consensus could apply.
   I suggest that we try a lazy consensus and if nobody is against 
with strong argument we move on.

2. Should we vote on the number of themes to keep?
   Again I suggest a lazy consensus ratehr than a vote
3. The theme/s to remove, I think we should make several votes, one 
by theme, to clearly decide which theme/s to remove


Thanks for your help deciding on this, please try to keep focused :)

Jacques

Re: svn commit: r1757462 [1/4] - in /ofbiz/trunk/themes: flatgrey/webapp/flatgrey/ rainbowstone/webapp/rainbowstone/

[Julien NICOLAS]

On 24/08/2016 09:41, Jacques Le Roux wrote:

Le 24/08/2016 à 09:23, Julien NICOLAS a écrit :

Hi Jacques,

I don't understand what to do if we had a new file type. I understand 
that something is wrong with the svn config but I don't know what.


Simple, just add it, like I did for *.less at 
http://svn.apache.org/viewvc?rev=1757468=rev


Then update your local one and ask other committers to do so



For the 4 colors, it is only because my customer order included 4 
theme colors and when I push the theme in trunk, I keep them.


I like the 4 colors (and want to have more :) ) but it seems to be a 
problem (what is exactly this problem ?).


Simple, maintaining 4 similar things instead of 1
I have to upgrade the less files because I improve my customer theme 
with a central less file and 4 others less only for colors. It could be 
better and solve the maintaining issue.




In the same idea, why do we keep more than one theme ? Just decide 
witch one is official and then, the other will be push out of the 
theme folder.


This is a moot point (which one? :)) But indeed with plugins I agree 
we should have only 1 OOTB and others external

I dream about this <3 pluggin system <3 in OFBiz :D
which one => I think it could be a vote by the community (only issueless 
themes).


Jacques



Julien.


On 24/08/2016 07:52, Jacques Le Roux wrote:
OK, the *.less type is not in the svn config. I'll revert, add it, 
and commit again.


So again, please committers remember to do so when you commit a new 
file type.


While at it I really wonder if we need to have 4 colored versions of 
the same theme in trunk?


I suggest to have only one and propose the others as external 
components, later plugins. We could use a third party location to 
propose the 3 others theme component (GitHub, 
https://oem.ofbizci.net/oci-2, etc.)


Opinions?

Jacques

Le 24/08/2016 à 07:44, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Aug 24 05:44:00 2016
New Revision: 1757462

URL: http://svn.apache.org/viewvc?rev=1757462=rev
Log:
Removes now useless IE7 "star html hack". I was used to prevent IE7 
from applying some CCS rules: 
http://css-discuss.incutio.com/wiki/Star_Html_Hack
And the hack is claimed deprecated here : 
https://blogs.msdn.microsoft.com/ie/2005/10/12/call-to-action-the-demise-of-css-hacks-and-broken-pages/


Thanks to Florian Montalbano research at "css property name 
correction in flatgrey and rainbowstone themes" - 
https://issues.apache.org/jira/browse/OFBIZ-7960#


I checked, the IE7 market share is residual, no needs to keep this 
dragging down feature


Modified:
 ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less 

ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-emerald.less 

ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-ruby.less 

ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-saphir.less 


ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/style.css

Modified: ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css?rev=1757462=1757461=1757462=diff
== 


--- ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css (original)
+++ ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css Wed Aug 
24 05:44:00 2016

@@ -922,10 +922,6 @@ form .basic-table,
  text-shadow: #fff 0 1px 1px; /* Setting must be in px */
  /*text-transform:uppercase;*/
  width: auto;
-
-/* IE7 */
-*padding-top: 0.2em;
-*padding-bottom: 0;
  }
.basic-table .collapsed {
@@ -1512,16 +1508,6 @@ input[type="button"] {
  text-shadow: #fff 0 1px 1px; /* Setting must be in px */
  /*text-transform:uppercase;*/
  width: auto;
-
-/* IE7 */
-*padding-top: 0.2em;
-*padding-bottom: 0;
-}
-
-button {
-/* IE7 */
-*padding-top: 0.1em;
-*padding-bottom: 0.1em;
  }
a.disabled,
@@ -1563,11 +1549,6 @@ input[type="week"] {
  padding: 0.2em 0.3em;
height: 1.8em;
-
-/* IE7 */
-*padding-top: 0.2em;
-*padding-bottom: 0.1em;
-*height: auto;
  }
/*

Modified: 
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less?rev=1757462=1757461=1757462=diff
== 

--- 
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less 
(original)
+++ 
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less 
Wed Aug 24 05:44:00 2016

@@ -1,1997 +1,1990 @@
-/* common colors */
-@black: #000;
-@white: #fff;
-@grey: #e6e6e6;
-@greydark: #929292;
-
-@color-success: #8cff8c;
-@font-color-for-success: @blac

Re: svn commit: r1757462 [1/4] - in /ofbiz/trunk/themes: flatgrey/webapp/flatgrey/ rainbowstone/webapp/rainbowstone/

[Julien NICOLAS]

Hi Jacques,

I don't understand what to do if we had a new file type. I understand 
that something is wrong with the svn config but I don't know what.


For the 4 colors, it is only because my customer order included 4 theme 
colors and when I push the theme in trunk, I keep them.


I like the 4 colors (and want to have more :) ) but it seems to be a 
problem (what is exactly this problem ?).


In the same idea, why do we keep more than one theme ? Just decide witch 
one is official and then, the other will be push out of the theme folder.


Julien.


On 24/08/2016 07:52, Jacques Le Roux wrote:
OK, the *.less type is not in the svn config. I'll revert, add it, and 
commit again.


So again, please committers remember to do so when you commit a new 
file type.


While at it I really wonder if we need to have 4 colored versions of 
the same theme in trunk?


I suggest to have only one and propose the others as external 
components, later plugins. We could use a third party location to 
propose the 3 others theme component (GitHub, 
https://oem.ofbizci.net/oci-2, etc.)


Opinions?

Jacques

Le 24/08/2016 à 07:44, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Aug 24 05:44:00 2016
New Revision: 1757462

URL: http://svn.apache.org/viewvc?rev=1757462=rev
Log:
Removes now useless IE7 "star html hack". I was used to prevent IE7 
from applying some CCS rules: 
http://css-discuss.incutio.com/wiki/Star_Html_Hack
And the hack is claimed deprecated here : 
https://blogs.msdn.microsoft.com/ie/2005/10/12/call-to-action-the-demise-of-css-hacks-and-broken-pages/


Thanks to Florian Montalbano research at "css property name 
correction in flatgrey and rainbowstone themes" - 
https://issues.apache.org/jira/browse/OFBIZ-7960#


I checked, the IE7 market share is residual, no needs to keep this 
dragging down feature


Modified:
 ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-emerald.less
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-ruby.less
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-saphir.less
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/style.css

Modified: ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css?rev=1757462=1757461=1757462=diff
== 


--- ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css (original)
+++ ofbiz/trunk/themes/flatgrey/webapp/flatgrey/style.css Wed Aug 24 
05:44:00 2016

@@ -922,10 +922,6 @@ form .basic-table,
  text-shadow: #fff 0 1px 1px; /* Setting must be in px */
  /*text-transform:uppercase;*/
  width: auto;
-
-/* IE7 */
-*padding-top: 0.2em;
-*padding-bottom: 0;
  }
.basic-table .collapsed {
@@ -1512,16 +1508,6 @@ input[type="button"] {
  text-shadow: #fff 0 1px 1px; /* Setting must be in px */
  /*text-transform:uppercase;*/
  width: auto;
-
-/* IE7 */
-*padding-top: 0.2em;
-*padding-bottom: 0;
-}
-
-button {
-/* IE7 */
-*padding-top: 0.1em;
-*padding-bottom: 0.1em;
  }
a.disabled,
@@ -1563,11 +1549,6 @@ input[type="week"] {
  padding: 0.2em 0.3em;
height: 1.8em;
-
-/* IE7 */
-*padding-top: 0.2em;
-*padding-bottom: 0.1em;
-*height: auto;
  }
/*

Modified: 
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less?rev=1757462=1757461=1757462=diff
== 

--- 
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less 
(original)
+++ 
ofbiz/trunk/themes/rainbowstone/webapp/rainbowstone/rainbowstone-amber.less 
Wed Aug 24 05:44:00 2016

@@ -1,1997 +1,1990 @@
-/* common colors */
-@black: #000;
-@white: #fff;
-@grey: #e6e6e6;
-@greydark: #929292;
-
-@color-success: #8cff8c;
-@font-color-for-success: @black;
-@color-alert: #ff8c8c;
-@font-color-for-alert: @black;
-
-@color-success-dark: #356e35;
-@font-color-for-success: @black;
-@color-alert-dark: #932f33;
-@font-color-for-alert: @black;
-
-@color-background-alert: #f2dede;
-@color-font-alert: #a94442;
-@color-border-alert: #ebccd1;
-
-@color-background-success: #dff0d8;
-@color-font-success: #3c763d;
-@color-border-success: #d6e9c6;
-
-/* Saphir colors */
-@blue-dark: #002333;
-@blue-main: #005982;
-@blue-medium: #c7dfff;
-@blue-light: #f1f7ff;
-@blue-light2: #e4f0f5;
-
-/* Ruby colors */
-@red-dark: #42;
-@red-main: #bf1616;
-@red-medium: #f7baba;
-@red-light: #fce7e7;
-@red-light2: #fed7c9;
-
-/* Emerald colors */
-@green-dark: #197948;
-@green-main: #23af9b;
-@green-medium: #7ae3ad;
-@green-light: #e5f9ef;
-@green-light2: #d7f9ef;
-
-/* Amber colors 

Re: Feedback on Committer Mentoring and HipChat

[Julien NICOLAS]

Hi Sharan,

When you start Hipchat, you opened an OFBiz room and I was loving it. 
Push Hipchat in the startup app even it's not a Libre Software and 
always aware on what's happen on this OFBiz community window. I was the 
feeling to be closer to the OFBiz community.


Then, people decided that that window is not good and go back on email 
"boring" system. In this community context, it's more difficult to use 
email for informal discussion.


So for me, HipChat is one more app for instant messaging. I'm not sure 
that is better than Skype or other proprietary software. Why not to 
decide to use jabber server that is more in free software way ?


Since the OFBiz room was closed, Hipchat is no more in my startup app. 
You have to send me an email to ask me to open Hipchat.


In summary, Hipchat or Skype as you wish, I don't mind.

Julien.

On 22/08/2016 10:42, Sharan Foga wrote:

Hi All

A few weeks ago, in response to the results of the Committer Survey, I setup a 
trial Hipchat environment to help with Committer Mentoring.  (See links to the 
previous discussion threads below:)

https://lists.apache.org/thread.html/8b8738c3adcb1b7aafd7c90f9b1cbb54500578d8cd392c3b18d635b9@%3Cdev.ofbiz.apache.org%3E

https://lists.apache.org/thread.html/5b64aad3bbaca967cf432adfd62ce68901c95218a8aa59d706aed6bc@%3Cdev.ofbiz.apache.org%3E

I really liked the HipChat environment and think that it's a great 
collaborative tool that also helps build community spirit. So now I'd like to 
get some feedback :-)

First of all I'd like to hear from the committers and mentors who participated 
to find out what they thought of the HipChat environment, what their general 
comments are and whether they would like it to be made available on a permanent 
basis.

Secondly I'd like to get some general feedback from everyone to find out if the 
whole community would also be interested in participating in HipChat 
environment (e.g. for collaborating on Jiras, or during our Community Days). 
Other ASF projects have HipChat spaces setup and publish a link that anyone can 
use to join and we could do the same.

The mailing list would still be used for discussions and decisions but if 
people are working together on a particular task then this could be a good way 
to speed up the process.  I'm thinking particularly about things like the 
re-factoring and our Jira backlog where bringing together the reporter and the 
developer could make things move a lot more quickly!)

We have another Community Day coming up in a few weeks on 17th September so it 
could be a good chance to see how it could work in action. What do people think?

Thanks
Sharan

Re: [VOTE] Create the "security" mailing list for the OFBiz project

[Julien NICOLAS]

+1


On 24/07/2016 14:32, Jacopo Cappellato wrote:

Rationale: every ASF project needs a private list to discuss product
vulnerabilities; for OFBiz the "private" list has been used for this
purpose until now; however an ad-hoc list may be useful because it could
provide a more focused space to discuss the security issues and could
provide more flexibility to invite in the private list persons willing to
help that are trusted by the PMC.

Please vote,

+1

to create a "security" list (i.e. secur...@ofbiz.apache.org) and move all
the security related discussions and notifications currently happening on
the private list to this new list: according to the ASF policies [*] the
list will be a private list used by the persons willing to help to resolve
security issues; the list of subscribers will be approved by the OFBiz PMC.

Otherwise vote -1 to continue to use the "private" mailing list for
vulnerability handling.

[*] http://www.apache.org/security/

Re: [VOTE] Create a "notifications" mailing list

[Julien NICOLAS]

+1 Good idea :)


On 24/07/2016 14:59, Jacopo Cappellato wrote:

Rationale: Jira notifications are currently sent to the "dev" list, causing
a lot of traffic and sometimes distracting from actual conversations; the
creation of a "notification" email (similar to the "commits" mailing list)
will solve this problem; in the future we may vote to use the
"notification" list to host traffic coming from buildbot etc... thus the
proposal for naming it "notifications" rather than just "issues"; however
this vote is only about traffic from Jira (we will discuss if we want to
extend the usage of this list in the future).

Please vote,

+1

to create a "notifications" mailing list (i.e.
notificati...@ofbiz.apache.org) and redirect to it all the traffic coming
from Jira notifications.

Otherwise vote -1 to continue to use the "dev" list for Jira notifications.

Re: [COMMUNITY VOTE] New OFBiz Logo - Please Vote for Your Preferred Choice

[Julien NICOLAS]

Thanks Sharan and Kenneth for your good work !

Whatever the community select, It will be the good one ! I'm looking 
forward to have a new sticker on my laptop ! \o/


On 22/07/2016 15:13, Sharan Foga wrote:

Hi Everyone

As mentioned I'd like to have a community vote for our new logo as the 
discussion threads were becoming a little difficult to follow. 
Essentially this vote is about selecting which design style you like 
the best that we want to move ahead with. This means that if for 
example the majority choose the existing logo then that's what we will 
try to refine and make into our official logo.


_IMPORTANT NOTE_: The link to the vote is at the bottom of my email 
and clearly labelled: “*Link to Logo Vote*:”


Kenneth has spent some time preparing some examples of each of the 
logos printed in different situations to give us a better idea of what 
it could look like. This means that whatever design we choose we still 
have options to change the colour of the logo for printing.


I've selected the following 3 options for the vote (as there were some 
ideas in the last round that no-one liked:-).


_*Option 1 : Our Existing Logo with Updated 'Registered' Symbol*_
I've included this option in the vote as we have a couple of people 
that strongly support this one. One thing to be aware of is that the 
quality of our existing logo is not very good, it is blurry and 
doesn't resize well so Kenneth has mentioned that some cleanup work 
will need to done to try and correct this.


It looks like this: 
https://cwiki.apache.org/confluence/download/attachments/61317052/Original-Ofbiz.png?api=v2


_*Option 2: Corrected OFBiz Name with New Feather *_
I've included this option in the vote as many people requested that we 
correct the spelling of OFBiz in our logo to match our project name. 
Also as Apache has rebranded their feather, this new feather was added 
to the logo.


It looks like this: 
https://cwiki.apache.org/confluence/download/attachments/61317052/NewFeather-OFBiz.png?api=v2


_*Option 3: Power OFBiz*_
I've included this option with its original colour gradient as some 
people liked the style, and others liked the style but not the colour. 
BTW I found out that the circle was meant to represent a power button 
(ie for switching on something on or off).  One concern that was noted 
was that the gradient would be difficult to print. Kenneth mentioned 
that he didn't think this would be an issue for a professional printer.


Some people liked this option with a blue power button instead so if 
you were one of those then please add in the comments box that you 
prefer the power button to be blue.


It looks like this: 
https://cwiki.apache.org/confluence/download/attachments/61317052/Power-OFBiz.png?api=v2 



*_Making Your Choice_*
The survey vote contains images of each of these logos so you will be 
able to see them when you vote. Please vote for only one of the 
options. For each option in the survey I've also added a comment box 
for any additional feedback.


Please use the following link to vote:

*Link to Logo Vote: https://www.surveymonkey.com/r/3J2H3RX
*

I'll keep the survey open until the next Wednesday so hopefully that 
will give everyone time to respond. Once complete I will summarise and 
post the results to both user and dev lists.


As an additional note – whichever we choose, the ASF will pay for us 
to get some stickers etc professionally printed so hopefully we will 
have some available for Apachecon later in the year.


Anyway Happy Voting Everyone!

Thanks
Sharan

Re: Removing multiple commands and related files for OFBiz server

[Julien NICOLAS]

If I'm not mistaken, some government prefer black box instead of open 
source software for POS (Belgium and France for example) because of the 
VAT control. So OFBiz can't be eligible... It could be the same in 
another country...


Julien.

On 21/07/2016 17:18, Jacques Le Roux wrote:

I believe there are better competitors

Jacques

Le 21/07/2016 à 17:12, Pierre Smits a écrit :

It is indeed a pity that the POS solution didn't attract more adoption
since inception in trunk. The last time I came across a lead related 
to the

component was approx. 2 years ago.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Thu, Jul 21, 2016 at 3:20 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Sincerely it's against my heart but not without reason that I also 
propose

to remove the --both and --pos options.

I put much time in the POS, but did not seriously work on it since 
end of

2009, and nobody contributed anything new since.
XUI http://xui.sourceforge.net/index.html is dead for 8 years and 
has no

replacement, see OFBIZ-2158 and for fun
http://markmail.org/message/ik7wjy2cziok3blt

So I'd not be against putting the POS in Attic. Of course if someone
volunteers to maintain the POS (contributors included, plugins to 
come in

mind), instead of putting it in the Attic, I'd gladly (but reasonably)
help...

BTW, though I don't see anything at
https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies, 

I wonder if  the WebPos does not partially rely on the POS, 
something to

check?

For the --testlist option it seems useless to me and would anyway be in
the history if ever someone get out of cryonics

Jacques



Le 21/07/2016 à 14:11, Jacopo Cappellato a écrit :


+1 to the proposal and I am interested to see what (if) others have to
say.

Jacopo

On Thu, Jul 21, 2016 at 11:38 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

Hello Everyone,

This is a proposal to _remove_ the following commands from the OFBiz
server
(invoked with ./gradlew "ofbiz --commandHere"

1- --both
2- --pos
3- --testlist

Reasons:
- The POS component is a specialpurpose component and should not have
code
existing in the start component. Instead logic for starting the POS
component should reside inside the POS component and away from 
framework
- After lots of investigation I realized the testlist OFBiz 
command is a
weird command that used to create an ant file that just iterates 
over the
existing integration test suites and run them one by one, which is 
slower
vs just running them all. It is deprecated and to my knowledge no 
one is

using it. I think it used to serve some deprecated cobertura tasks.

This would imply deleting the following files:
-


framework/start/src/main/java/org/apache/ofbiz/base/start/testlist.properties 


-


framework/testtools/src/main/java/org/apache/ofbiz/testtools/TestListContainer.java 


-

framework/base/src/main/java/org/apache/ofbiz/base/splash/SplashLoader.java 



and modifying the following files:
- 
framework/start/src/main/java/org/apache/ofbiz/base/start/Config.java

-


framework/start/src/main/java/org/apache/ofbiz/base/start/StartupCommandUtil.java 


- (move it to POS)

framework/base/src/main/java/org/apache/ofbiz/base/splash/SplashScreen.java 



Agreed?

Regards,

[jira] [Commented] (OFBIZ-5840) Create bootstrap theme

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381857#comment-15381857
 ] 

Julien NICOLAS commented on OFBIZ-5840:
---

I agree, the theming system is not flexible as it must be. This is what I 
discover on the way to implement bootstrap and Rainbowstone theme.
We'll working on another theme soon and it seem urgent to wait for a new 
concept before doing twice the work. Let me know as soon as you can share your 
ideas.

Thanks!

Julien.

> Create bootstrap theme
> --
>
> Key: OFBIZ-5840
> URL: https://issues.apache.org/jira/browse/OFBIZ-5840
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework, themes
>Affects Versions: Bootstrap theme
>    Reporter: Julien NICOLAS
>  Labels: bootstrap, theme
> Attachments: Facility.PNG, FindAgreement..png, Footer.jpg, 
> GlobalDecorator.patch, ImprovedFooter.patch, MacroMenuRenderer.patch, 
> OFBIZ-5840-Menufactory.patch, OFBIZ-5840-Menufactory.patch, 
> appbar_menu_ftl.patch, bootified.js, bootified_js_screentrans.patch, 
> bootstrap-theme.zip, bootstrap.zip, bootstrapThemeToTrunk.patch, 
> calendar.PNG, catalog.png, glyphicons-halflings-regular.zip, 
> htmlMenuMacroLibrary.patch, lookupField_patch.patch, 
> pagination_htmlFormMacroLibrary.patch, 
> panelCollapse_htmlSreenMacroLibrary.patch, party menu tab bar.PNG, 
> preferences.png, styling_issue_1.png, styling_issue_2.png, 
> styling_issue_3.png, styling_issue_4.png, styling_issue_5.png, 
> styling_issue_6.png, styling_issue_7.png, styling_issue_8.png, 
> styling_issue_9.png, tab-bar.png, workeffort.PNG
>
>
> 1- create a sub-directory called bootstrap under the image webapp to put
> the resources over there (js, css and fonts) as indicated earlier by Gavin.
> (Julien : not sure about location)
> 2- check to make sure that the current version of jQuery is compatible with
> the installed version or upgrade it accordingly
> 3- Create a new theme based on one of the existing themes as suggested by
> Julien and Gavin
> 4- Test the theme by switching to it and handle major bugs / issues.
> 5- Start to make a few test screens utilizing Bootstrap



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372775#comment-15372775
 ] 

Julien NICOLAS commented on OFBIZ-7622:
---

So we can just manage entity status listed by the parent Jira and add the 
property in general.properties.
If you want to continue to discuss on this topic, I think it could be 
interesting to use the parent topic comments.

Regards,

Julien.

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372561#comment-15372561
 ] 

Julien NICOLAS commented on OFBIZ-7622:
---

Hi Michael & Pierre,

Tracking was already available for the order status.
But maybe it could be interesting to define in general.properties a 
track.user.on.status.change=Y/N that can be manage in the auto-entity process.

What do you think ?

Julien.

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372392#comment-15372392
 ] 

Julien NICOLAS commented on OFBIZ-7622:
---

For more details, I don't need to use date, and user login because auto-entity 
manage it automatically.

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372388#comment-15372388
 ] 

Julien NICOLAS commented on OFBIZ-7622:
---

available on trunk r1752219

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS closed OFBIZ-7622.
-
Resolution: Fixed

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371705#comment-15371705
 ] 

Julien NICOLAS commented on OFBIZ-7622:
---

I use the entity-auto and don't use the minilang anymore.

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS updated OFBIZ-7622:
--
Attachment: OFBIZ-7622.patch

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS reassigned OFBIZ-7622:
-

Assignee: Julien NICOLAS

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371498#comment-15371498
 ] 

Julien NICOLAS commented on OFBIZ-7622:
---

I start working on this one

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Important Changes to Trunk and Use of Ant & Gradle

[Julien NICOLAS]

For me, no problem to drop it.

Julien.

On 22/06/2016 16:23, Taher Alkhateeb wrote:

Hi Michael Jacques and everyone,

So I also want to confirm that you really need the following tasks:

- build-dev
- build-production
- build-qa
- build-test
- revert-dev

Are you using them yourselves? Here are the reasons why I suggest to remove
them:
- First, you must have the patch command existing in your environment, thus
making the build script brittle
- Second, it has this weird naming convention for patches and how they
should be applied. I would imagine that every team and every company has
its own style and methodology for patching and keeping track of files and
changes. They use their own version control system and even different kinds
of patches
- It is dependent on a specific format of diff which you must generate
either with svn diff or diff -Naur.

It seems like it does not make a lot of sense to keep something like that
when companies might completely ignore it and choose their own
implementation strategies. Do you agree? Feedback?

Taher Alkhateeb

On Wed, Jun 22, 2016 at 4:01 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I wonder though why this was introduced. If we have no feedback from any
member of the community I think we can drop it. I don't see how to use it.

Jacques



Le 22/06/2016 à 14:43, Michael Brohl a écrit :


Hi Taher,

no, I don't use it myself. This was just a guess by looking what the task
does and it seemed to me this should be preserved.
No problem to drop it from my side.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:


Hi Michael,

Are you sure you are using "run-test-list"? This is an old task using a
target on the server called --testlist which essentially creates an ant
file of all the suites in OFBiz and runs them one-by-one stopping OFBiz
in
between each run.

To me it seems like run-tests is doing the same thing but faster. Is
this a
typo by you or are you actually using this target? The reason I ask is
because I actually wanted to delete the entire TestListContainer.java and
related files in the future. But now of course I hesitate.

Thanks in advance for your feedback.

Regards,

Taher Alkhateeb

On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <
michael.br...@ecomify.de>
wrote:

Hi Taher,

First question:

Don't drop:

- build-dev
- build-production
- build-qa
- build-test
- refresh
- revert-dev
- run-test-list

Drop:

- clean-ivy (assuming this is not needed if we use Gradle)
- copy-dtds
- download-PG-JDBC
- download-activemq
- download-mySQL-JDBC (download tasks: assuming they are not needed if
we
use Gradle/automatic dependency mechanism)


Not sure (I don't use them):

- create-tenant
- load-all-tenants
- load-demo-multitenant
- load-tenant
- load-tenant-data-readers
- gen-kek
- gitinfo
- run-test-list
- start-batch-secure
- start-both-secure
- start-pos-secure
- start-secure (...secure: not sure if these are needed anymore, I think
Jacques can give some hints about them)
- svninfo

Second question: +1

but I'm not sure about the load-tenant... tasks (I don't use them).


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:

Hi Everyone,

I have create the JIRA
https://issues.apache.org/jira/browse/OFBIZ-7534
for
this project

I have two questions in this thread

First Question
--
Can I drop the below tasks from the build system? They currently exist
in
Ant but I am not sure whether they are actively used or not. So if you
want
me to add any of these tasks please reply to this thread, otherwise I
will
not include them in gradle. Please note I added all multi tenant tasks
because many of them are broken or have no functionality, so I am
assuming
people are doing multi-tenancy manually but not sure, so please help!

- build-dev
- build-production
- build-qa
- build-test
- clean-ivy
- copy-dtds
- create-tenant
- download-PG-JDBC
- download-activemq
- download-mySQL-JDBC
- gen-kek
- gitinfo
- load-all-tenants
- load-demo-multitenant
- load-tenant
- load-tenant-data-readers
- refresh
- revert-dev
- run-test-list
- start-batch
- start-batch-secure
- start-both-secure
- start-pos-secure
- start-secure
- svninfo

Second Question
---

it seems many of the load tasks are too specific. So I suggest to only
implement loadDemo and the rest are executed manually by users, for
example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
instead of load-extseed.

If you would like to add the other load data tasks, please specify
which
ones.

Appreciate your early responses.

Taher Alkhateeb

Re: Important Changes to Trunk and Use of Ant & Gradle

[Julien NICOLAS]

On 22/06/2016 09:53, Julien NICOLAS wrote:



On 21/06/2016 22:09, Taher Alkhateeb wrote:

- download-PG-JDBC

If it's possible, keep this one :)
Ok, I don't see the information of Michael that with Graddle, we don't 
need a task for that because of the Graddle dependency functionality. So 
my mistake, forgot it :)


Second Question
---

it seems many of the load tasks are too specific. So I suggest to only
implement loadDemo and the rest are executed manually by users, for
example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
instead of load-extseed.
I think load-seed is important as well, so if you can keep the 
load-seed task, it could be fine.


Thanks!

Julien.


If you would like to add the other load data tasks, please specify which
ones.

Appreciate your early responses.

Taher Alkhateeb

On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb 
<slidingfilame...@gmail.com

wrote:
Hi Everyone,

Thank you all for your support and kinds words. This is truly a 
wonderful
atmosphere and I am lucky, honoured, and privileged to work with you 
all on

this project.

My patch is almost done, but definitely there is a lot of work to be 
done

which includes the following:
- I have one failing test out of 889 that I need to dig through, 
maybe you

guy can help
- I want to change / delete / add some tasks
- Documentation needs to be updated in multiple areas
- Testing, testing, testing, testing, testing, testing, testing, 
testing,

testing

So the plan of action is as follows:
- I will continue the discussion on this thread for a few questions 
that I

need an answer for.
- I will issue a JIRA to hold the patch and everything else

Please consider helping, this is something that definitely needs a 
team,

more than one brain! If you are working on something not urgent, please
consider dropping it for a while and jump along for help.

I will post another email soon with the JIRA details and list of 
questions

I need answer for.

Again, thank you, you guys rock, I love OFBiz and this community!

Regards,

Taher Alkhateeb



On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin 
<nicolas.ma...@nereide.fr>

wrote:

I'm in over for these technical aspects but the motivation and 
enthusiasm

for many PMC and commiter tells me that seems a good way.

So now I will learn gradle ;) and I'm in favor to realize this change
directly on trunk

Thks Taher to your engine energy on this subject !

Nicolas



Le 21/06/2016 10:43, Jacques Le Roux a écrit :

As Gavin mentioned, Gradle can run Ant so no worries using only 
Gradle


https://docs.gradle.org/current/userguide/ant.html

Jacques


Le 21/06/2016 à 09:59, Michael Brohl a écrit :


I have no strong opinion for/against Gradle (I simply have no
experience with it) but I agree that it should be either Ant or 
Gradle.
Running two build tools in parallel would make it too complex an 
gain

nothing.

I'm in favor for learning new things so Gradle sounds fine for me 
:-)


Regards,

Michael


Am 21.06.16 um 08:11 schrieb Taher Alkhateeb:


Hi Deepak,

Ant would be removed completely for the following reasons:

- First to resolve the ASF issue about the libraries mentioned by
Sharan
below without expending effort on both build systems.
- Ant is an obstacle to refactoring the framework. If we keep both
systems
side by side we gain nothing, actually we lose value because the 
builds
become more complex. For example, we will not be able to 
intrduce the

unit
tests, and we will have two build outputs, and we will have two 
ways of
running the framework (java -jar ofbiz.jar and gradlew ofbiz) 
and we

will
have other incompatibility issues.

With that being said, we will not make the switch before a 
thorough and

full testing. That is why we ask everyone who is willing to please
help us
out to make this transition smooth by testing and providing 
feedback

and
comments.

Taher Alkhateeb

On Tuesday, 21 June 2016, Deepak Dixit 
<deepak.di...@hotwaxsystems.com

wrote:

+1 for Gradle.
Are we going to remove ant from framework completely or 
planning to

keep
both ant and gradle?



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

On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga 
<sharan.f...@gmail.com

<javascript:;>> wrote:

Hi Everyone
This is the second of two emails to inform the community about 
what

has
been happening around how we are planning to handle external
dependencies
in the trunk. Two weeks ago the community discussed and agreed to
the use
of Gradle to help us put together a unit test framework. While
trying to
get this set up while Ant remained as our build tool became very


difficult.


This was because our Ant scripts:

 - are massive and contain a lot of code
 - are complex
 - are very brittle and make it very hard to change things
 - have no dependency management
 - need everything to be declared

We realised very quickly that the re-factoring issues and
limitations we
are facing a

Re: Important Changes to Trunk and Use of Ant & Gradle

[Julien NICOLAS]

On 21/06/2016 22:09, Taher Alkhateeb wrote:

- download-PG-JDBC

If it's possible, keep this one :)


Second Question
---

it seems many of the load tasks are too specific. So I suggest to only
implement loadDemo and the rest are executed manually by users, for
example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
instead of load-extseed.
I think load-seed is important as well, so if you can keep the load-seed 
task, it could be fine.


Thanks!

Julien.


If you would like to add the other load data tasks, please specify which
ones.

Appreciate your early responses.

Taher Alkhateeb

On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb 
wrote:


I'm in over for these technical aspects but the motivation and enthusiasm
for many PMC and commiter tells me that seems a good way.

So now I will learn gradle ;) and I'm in favor to realize this change
directly on trunk

Thks Taher to your engine energy on this subject !

Nicolas



Le 21/06/2016 10:43, Jacques Le Roux a écrit :


As Gavin mentioned, Gradle can run Ant so no worries using only Gradle

https://docs.gradle.org/current/userguide/ant.html

Jacques


Le 21/06/2016 à 09:59, Michael Brohl a écrit :


I have no strong opinion for/against Gradle (I simply have no
experience with it) but I agree that it should be either Ant or Gradle.
Running two build tools in parallel would make it too complex an gain
nothing.

I'm in favor for learning new things so Gradle sounds fine for me :-)

Regards,

Michael


Am 21.06.16 um 08:11 schrieb Taher Alkhateeb:


Hi Deepak,

Ant would be removed completely for the following reasons:

- First to resolve the ASF issue about the libraries mentioned by
Sharan
below without expending effort on both build systems.
- Ant is an obstacle to refactoring the framework. If we keep both
systems
side by side we gain nothing, actually we lose value because the builds
become more complex. For example, we will not be able to intrduce the
unit
tests, and we will have two build outputs, and we will have two ways of
running the framework (java -jar ofbiz.jar and gradlew ofbiz) and we
will
have other incompatibility issues.

With that being said, we will not make the switch before a thorough and
full testing. That is why we ask everyone who is willing to please
help us
out to make this transition smooth by testing and providing feedback
and
comments.

Taher Alkhateeb

On Tuesday, 21 June 2016, Deepak Dixit > wrote:

Hi Everyone

This is the second of two emails to inform the community about what
has
been happening around how we are planning to handle external
dependencies
in the trunk. Two weeks ago the community discussed and agreed to
the use
of Gradle to help us put together a unit test framework. While
trying to
get this set up while Ant remained as our build tool became very


difficult.


This was because our Ant scripts:

 - are massive and contain a lot of code
 - are complex
 - are very brittle and make it very hard to change things
 - have no dependency management
 - need everything to be declared

We realised very quickly that the re-factoring issues and
limitations we
are facing are because of our build tool – Ant.

Ant is verbose so it needs everything to be declared. We did a brief
assessment of Maven and found it better than Ant but not a good fit
for
OFBiz because it has strict requirements for the
convention-over-configuration rules to work. Instead we 

Re: Important Changes to Trunk and Use of Ant & Gradle

[Julien NICOLAS]

+1 to go forward with Gradle

Julien.

On 21/06/2016 08:11, Taher Alkhateeb wrote:

Hi Deepak,

Ant would be removed completely for the following reasons:

- First to resolve the ASF issue about the libraries mentioned by Sharan
below without expending effort on both build systems.
- Ant is an obstacle to refactoring the framework. If we keep both systems
side by side we gain nothing, actually we lose value because the builds
become more complex. For example, we will not be able to intrduce the unit
tests, and we will have two build outputs, and we will have two ways of
running the framework (java -jar ofbiz.jar and gradlew ofbiz) and we will
have other incompatibility issues.

With that being said, we will not make the switch before a thorough and
full testing. That is why we ask everyone who is willing to please help us
out to make this transition smooth by testing and providing feedback and
comments.

Taher Alkhateeb

On Tuesday, 21 June 2016, Deepak Dixit 
wrote:


+1 for Gradle.

Are we going to remove ant from framework completely or planning to keep
both ant and gradle?



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

On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga > wrote:


Hi Everyone

This is the second of two emails to inform the community about what has
been happening around how we are planning to handle external dependencies
in the trunk. Two weeks ago the community discussed and agreed to the use
of Gradle to help us put together a unit test framework. While trying to
get this set up while Ant remained as our build tool became very

difficult.

This was because our Ant scripts:

- are massive and contain a lot of code
- are complex
- are very brittle and make it very hard to change things
- have no dependency management
- need everything to be declared

We realised very quickly that the re-factoring issues and limitations we
are facing are because of our build tool – Ant.

Ant is verbose so it needs everything to be declared. We did a brief
assessment of Maven and found it better than Ant but not a good fit for
OFBiz because it has strict requirements for the
convention-over-configuration rules to work. Instead we decided to take a
closer look at Gradle.

So why Gradle?
As Taher was already looking at Gradle for unit testing, we decided to
look at what we would need to do to totally replace Ant with Gradle. We
received some great support and feedback from David, who is already using
Gradle with Moqui.

After some preliminary tests we found that Gradle has some very good
features such as:

- a much shorter code base (e.g. one single file of around 250 lines

of

code replaces all the build.xml files and thousands of lines of code)
-  Programming is DSL based and links in well with Groovy (e.g. the
script is short because despite heavy custom requirements for OFBiz, two
small functions took care of the complex directory structure)
- It handles all the external jar files by downloading any

dependencies

directly via internet
- Jars can be upgraded by simply changing a string
- It has matured a lot and has a high level of support in tools,IDEs,
books, documentation
- It also has a lot of plugins which means that it works with pretty
much all build systems, supports multiple programming languages, and many
other features (e.g. OSGi)

We understand that it can help us make OFBiz more modular and also

setting

up a framework for managing addons would be a lot easier.

So what's been done?
Taher has been working very hard on a patch for the trunk that completely
replaces Ant with Gradle.  (Huge thanks to David for providing some

example

scripts to help us get started!) The patch is now ready to be applied to
the trunk and includes the following:

 - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
--whatever-options-here'
 - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
--whatever'. What does that mean? It means we can run debug on ALL ofbiz
commands, not just start
 - If we decide to change the source directory structure in components
say from /src to /src/main, it would literally be a change of 5

characters

in the build script
 - We can immediately move all jar files if we want to a unified
location in /lib for example
 - We can delete most of the jars and declare them as dependencies
saving space and resources
 - We can automate the creation of the .classpath file so when we
update libraries no need to do this manually (under development)
 - We can ignore components that are not define in the xml files for
loading (under development)
 - We can introduce unit tests with about 10 minutes of work

We are finding that the flexibility and control we are getting with

Gradle

is truly amazing. We know that Gradle will be a major change to the

project

but we think that it will significantly improve the project by 

[jira] [Comment Edited] (OFBIZ-7139) Product Name

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314036#comment-15314036
 ] 

Julien NICOLAS edited comment on OFBIZ-7139 at 6/3/16 12:26 PM:


  Ideally it should look for content first if found then return and if not 
found then go for Product.productName.

I agree, it seems good like that. It's a easier way if you don't need 
translation on your product.

Julien.


was (Author: julien.nicolas):
 Ideally it should look for content first if found then return and if not found 
then go for Product.productName.

I agree, it seems good like that. It's a easier way if you don't need 
translation on your product.

Julien.

> Product Name
> 
>
> Key: OFBIZ-7139
> URL: https://issues.apache.org/jira/browse/OFBIZ-7139
> Project: OFBiz
>  Issue Type: Improvement
>  Components: product
>Affects Versions: Trunk
>Reporter: Rishi Solanki
>Assignee: Rishi Solanki
>Priority: Minor
>
> As per the discussion over user list (subject: "Product Name"), user should 
> be able to add product name in product creation process.
> On Catalog >> Products >> New Product section, user won't see any input field 
> to add product name. Same applies to Edit product screen.
> - Add field on the create and edit form.
> - Check for the support in the services used, if not then add support for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7139) Product Name

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314036#comment-15314036
 ] 

Julien NICOLAS commented on OFBIZ-7139:
---

 Ideally it should look for content first if found then return and if not found 
then go for Product.productName.

I agree, it seems good like that. It's a easier way if you don't need 
translation on your product.

Julien.

> Product Name
> 
>
> Key: OFBIZ-7139
> URL: https://issues.apache.org/jira/browse/OFBIZ-7139
> Project: OFBiz
>  Issue Type: Improvement
>  Components: product
>Affects Versions: Trunk
>Reporter: Rishi Solanki
>Assignee: Rishi Solanki
>Priority: Minor
>
> As per the discussion over user list (subject: "Product Name"), user should 
> be able to add product name in product creation process.
> On Catalog >> Products >> New Product section, user won't see any input field 
> to add product name. Same applies to Edit product screen.
> - Add field on the create and edit form.
> - Check for the support in the services used, if not then add support for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (OFBIZ-7160) Correction of typo "javascrip"

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS closed OFBIZ-7160.
-

> Correction of typo "javascrip"
> --
>
> Key: OFBIZ-7160
> URL: https://issues.apache.org/jira/browse/OFBIZ-7160
> Project: OFBiz
>  Issue Type: Improvement
>  Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Assignee: Julien NICOLAS
>Priority: Minor
>  Labels: javascript, misspelled
> Attachments: OFBIZ-7160.patch
>
>
> Hi all,
> There are some javascript code inserted in html with "javascrip:" instead of 
> "javascript:" . I found one of this mistake so I did a search on the whole 
> project and found two more.
> I corrected them in the associated patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OFBIZ-7160) Correction of typo "javascrip"

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS resolved OFBIZ-7160.
---
Resolution: Fixed

r1746536

> Correction of typo "javascrip"
> --
>
> Key: OFBIZ-7160
> URL: https://issues.apache.org/jira/browse/OFBIZ-7160
> Project: OFBiz
>  Issue Type: Improvement
>  Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Assignee: Julien NICOLAS
>Priority: Minor
>  Labels: javascript, misspelled
> Attachments: OFBIZ-7160.patch
>
>
> Hi all,
> There are some javascript code inserted in html with "javascrip:" instead of 
> "javascript:" . I found one of this mistake so I did a search on the whole 
> project and found two more.
> I corrected them in the associated patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7160) Correction of typo "javascrip"

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15311958#comment-15311958
 ] 

Julien NICOLAS commented on OFBIZ-7160:
---

Commited in version trunk revision 1746536

> Correction of typo "javascrip"
> --
>
> Key: OFBIZ-7160
> URL: https://issues.apache.org/jira/browse/OFBIZ-7160
> Project: OFBiz
>  Issue Type: Improvement
>  Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Assignee: Julien NICOLAS
>Priority: Minor
>  Labels: javascript, misspelled
> Attachments: OFBIZ-7160.patch
>
>
> Hi all,
> There are some javascript code inserted in html with "javascrip:" instead of 
> "javascript:" . I found one of this mistake so I did a search on the whole 
> project and found two more.
> I corrected them in the associated patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OFBIZ-7160) Correction of typo "javascrip"

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS reassigned OFBIZ-7160:
-

Assignee: Julien NICOLAS

> Correction of typo "javascrip"
> --
>
> Key: OFBIZ-7160
> URL: https://issues.apache.org/jira/browse/OFBIZ-7160
> Project: OFBiz
>  Issue Type: Improvement
>  Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Assignee: Julien NICOLAS
>Priority: Minor
>  Labels: javascript, misspelled
> Attachments: OFBIZ-7160.patch
>
>
> Hi all,
> There are some javascript code inserted in html with "javascrip:" instead of 
> "javascript:" . I found one of this mistake so I did a search on the whole 
> project and found two more.
> I corrected them in the associated patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: OFBiz Committers Survey

[Julien NICOLAS]

done!

On 19/05/2016 15:24, Sharan-F wrote:

Hi Everyone

I've sent out the survey today so all our committers (including emeritus and
inactive) should get an email with a link to it.
I'll plan to keep the survey open for 7 days (less if I get all the
responses back beforehand!) to give people enough time to complete it.

Thanks in advance for your feedback.

Thanks
Sharan




--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/OFBiz-Committers-Survey-tp4680727p4680804.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: OFBiz Committers Survey

[Julien NICOLAS]

Good initiative Sharan !

Thanks !

Julien.

On 18/05/2016 17:10, Sharan-F wrote:

Hi Everyone

It's been a long while since I last did any kind of community survey and
this time I'd like to survey our committers – so I'm hoping our committers
are willing to participate. :-)

I'm currently working on finalising it all and hope that it can be sent out
by the end of this week. I'll keep it open for a fixed time (maybe up to a
week) and then will summarise and publish the results.

Thanks
Sharan




--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/OFBiz-Committers-Survey-tp4680727.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: User pref or not user pref

[Julien NICOLAS]

It could be loaded in the cache but if we push all user customisation in 
cache, it could use too much memories only for the UI (if you have a lot 
of users).


Julien.

Le 07/04/2016 12:34, Pierre Smits a écrit :

Aren't user prefs cached somehow?

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

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

On Thu, Apr 7, 2016 at 11:35 AM, Julien NICOLAS <julien.nico...@nereide.fr>
wrote:


Hi all,

We are thinking on a new theme (again) that will be more user friendly and
UX oriented.
We want to be able to customize menu (component and its sub menu).

User pref could be the clue but we are not sure because if all menu and
sub menu (and maybe 3rd or 4th level menu) user preference are recorded in
the user pref, it could be a nightmare for the database access if there is
a lot of users. And only for user preference, it's not a good idea.
We also think about using cookies but it could be a problem if the user
user several computers.

What do you think ? Do you already try to develop this kind of feature ?

Thanks,

Julien.

User pref or not user pref

[Julien NICOLAS]

Hi all,

We are thinking on a new theme (again) that will be more user friendly 
and UX oriented.

We want to be able to customize menu (component and its sub menu).

User pref could be the clue but we are not sure because if all menu and 
sub menu (and maybe 3rd or 4th level menu) user preference are recorded 
in the user pref, it could be a nightmare for the database access if 
there is a lot of users. And only for user preference, it's not a good idea.
We also think about using cookies but it could be a problem if the user 
user several computers.


What do you think ? Do you already try to develop this kind of feature ?

Thanks,

Julien.

Re: [VOTE] [RELEASE] Apache OFBiz 13.07.03

[Julien NICOLAS]

+1

Le 29/03/2016 11:42, Jacopo Cappellato a écrit :

This is the vote thread to release a new bug fix release for the
release13.07 branch. This new release, "Apache OFBiz 13.07.03", will
supersede all the previous releases from the same branch.

The release files can be downloaded from here:

https://dist.apache.org/repos/dist/dev/ofbiz/

and are:

* apache-ofbiz-13.07.03.zip

* KEYS: text file with keys

* apache-ofbiz-13.07.03.zip.asc: the detached signature file

* apache-ofbiz-13.07.03.zip.md5, apache-ofbiz-13.07.03.zip.sha: hashes

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 13.07.03

[ -1] do not release

This vote will be open for approximately 5 days.

For more details about this process please read
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 12.04.06

[Julien NICOLAS]

+1

Le 29/03/2016 11:05, Jacopo Cappellato a écrit :

This is the vote thread to release a new bug fix release for the
release12.04 branch. This new release, "Apache OFBiz 12.04.06" will
supersede all the previous releases from the same branch and it will be the
last release of the 12.06 series.

The release files can be downloaded from here:

https://dist.apache.org/repos/dist/dev/ofbiz/

and are:

* apache-ofbiz-12.04.06.zip

* KEYS: text file with keys

* apache-ofbiz-12.04.06.zip.asc: the detached signature file

* apache-ofbiz-12.04.06.zip.md5, apache-ofbiz-12.04.06.zip.sha: hashes

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 12.04.06

[ -1] do not release

This vote will be open for approximately 5 days.

For more details about this process please read
http://www.apache.org/foundation/voting.html

[jira] [Commented] (OFBIZ-5672) UOM conversion for supplier and sale order

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15187189#comment-15187189
 ] 

Julien NICOLAS commented on OFBIZ-5672:
---

I think it was initially developed for 13.07. I'll really be surprised if it 
works on trunk but not on 13.07.
I'm busy by now but next week, I hope to have time to take a look on that.

> UOM conversion for supplier and sale order
> --
>
> Key: OFBIZ-5672
> URL: https://issues.apache.org/jira/browse/OFBIZ-5672
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Release Branch 13.07, Trunk
> Environment: OOTB
>    Reporter: Julien NICOLAS
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: features
> Attachments: OFBIZ-5672-UOM-conversion-supplier-and-sale-order.13.07
>
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> It's possible to define different UomQuantity in measures tab, supplier tab 
> or price tab of a product but OFBiz don't manage it in stock.
> The improvement must manage it using UomConversion table for standard 
> conversions.
> When a new order (supplier or sale) is created, the user can choose the 
> UomQuantity if more than one UomQuantity is available.
> By default if only one conversion is defined in UomConversion table, OFBiz 
> will use it for both conversion way.
> However, it's possible to define different rules for each ways.
> Add new concept in UomConversion rules : rouding method and number of digit 
> after decimal point.
> To be more flexible, add new fields in price and supplier product tab.
>   - Uom conversion factor
>   - Rounding method
>   - Number of digit after decimal point
> If those fields are empty, OFBiz will use the standard UomConversion table.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proposal for the "Tweets" and "News" sections of the main web page of the OFBiz site

[Julien NICOLAS]

+1

There is a lot of tweet with @apacheOfibz and it could be interesting to 
have it as main news.


Le 09/03/2016 10:45, Jacopo Cappellato a écrit :

Proposal:
in the main page of the ofbiz web site, move the "Tweets" section from the
right bar to the main section of the page, before the "News" section; then
rename the "News" section into "Announcements" or similar.

Goal:
give more visibility to our tweets because it is a more dynamic section
while the "News" section is update less frequently only when some
announcements or milestone is reached.

What do you think?

Jacopo

Re: Welcome to our new committer Gregory Draperi

[Julien NICOLAS]

Congratulations & welcome aboard Gregory :)

Julien.

Le 08/03/2016 17:27, Jacopo Cappellato a écrit :

Gregory is a software security expert that has been "silently" helping the
OFBiz project for years by testing and assessing the security aspects of
our system and submitting valuable and precise reports and helping the PMC
to resolve them.

On behalf of the PMC, welcome onboard Gregory.

Re: Skype Group Call Next Week re-Framework Re-Factoring

[Julien NICOLAS]

Hello Sharan, Taher,

I'm interested by this meeting but unfortunately I've got another 
meeting at 13:00 today.

It could be better for me as weel to postpone this meeting to the next week.

Regards,

Julien.

Le 07/03/2016 08:27, Sharan-F a écrit :

Hi Taher

I didnt realise Ron was interested. If that's the case then that makes it
difficult for us to have our call today as it will only be 7am his time.

I think then it's better to postpone the call until next week to make sure
that we have the availability of everyone who is interested in a call.

We do have a Community Day coming up on the 19th March so as long as we can
have our call beforehand to co-ordinate the work then we should be able to
get things moving in time for that.

Thanks
Sharan






--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Skype-Group-Call-Next-Week-re-Framework-Re-Factoring-tp4677595p4677610.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: cascading deletes in ofbiz

[Julien NICOLAS]

I agree with Taher, It could be very dangerous and difficult to 
understand 'what's happens' after a product deletion...


Julien.

Le 22/02/2016 11:38, Taher Alkhateeb a écrit :

Also, generally speaking, most modern systems that I know of avoid delete
altogether, and instead just disable or make things "inactive" for
reporting or operational reasons. That is always a safer and more auditable
system.

[jira] [Commented] (OFBIZ-6907) 1

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15154263#comment-15154263
 ] 

Julien NICOLAS commented on OFBIZ-6907:
---

Don't really understand your needs.
You can change the UI easily in the ecommerce component to suit with your needs.

> 1
> -
>
> Key: OFBIZ-6907
> URL: https://issues.apache.org/jira/browse/OFBIZ-6907
> Project: OFBiz
>  Issue Type: Improvement
>  Components: specialpurpose/ecommerce
>Reporter: xin chang
>
> many of us think of the UI so bad,developer need to modify it,it meant need 
> more time to do this,I hope that your team can fix it,with many thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5840) Create bootstrap theme

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139793#comment-15139793
 ] 

Julien NICOLAS commented on OFBIZ-5840:
---

I was wondered to enhance rainbowstone to match with your preference Jacques. 
But, you spent time to merge this branch and it's a pity to not finish this 
work.
I'll take a look this night, not sure to find a solution but I don't want to 
leave you alone with an effort that I ask for :)

The more I understand CSS, the less I need bootstrap. Today, I'm not sure about 
integrate it in the backend. I'm convinced that it's interesting to use it for 
the default e-commerce website but for the backend... I'm not sure right now.

So I take a look and hope that I find something :)

> Create bootstrap theme
> --
>
> Key: OFBIZ-5840
> URL: https://issues.apache.org/jira/browse/OFBIZ-5840
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework, themes
>Affects Versions: Bootstrap theme
>    Reporter: Julien NICOLAS
>Assignee: Jacques Le Roux
>  Labels: bootstrap, theme
> Attachments: Facility.PNG, FindAgreement..png, Footer.jpg, 
> GlobalDecorator.patch, ImprovedFooter.patch, MacroMenuRenderer.patch, 
> OFBIZ-5840-Menufactory.patch, OFBIZ-5840-Menufactory.patch, 
> appbar_menu_ftl.patch, bootified.js, bootified_js_screentrans.patch, 
> bootstrap-theme.zip, bootstrap.zip, bootstrapThemeToTrunk.patch, 
> calendar.PNG, catalog.png, glyphicons-halflings-regular.zip, 
> htmlMenuMacroLibrary.patch, lookupField_patch.patch, 
> pagination_htmlFormMacroLibrary.patch, 
> panelCollapse_htmlSreenMacroLibrary.patch, party menu tab bar.PNG, 
> preferences.png, styling_issue_1.png, styling_issue_2.png, 
> styling_issue_3.png, styling_issue_4.png, styling_issue_5.png, 
> styling_issue_6.png, styling_issue_7.png, styling_issue_8.png, 
> styling_issue_9.png, tab-bar.png, workeffort.PNG
>
>
> 1- create a sub-directory called bootstrap under the image webapp to put
> the resources over there (js, css and fonts) as indicated earlier by Gavin.
> (Julien : not sure about location)
> 2- check to make sure that the current version of jQuery is compatible with
> the installed version or upgrade it accordingly
> 3- Create a new theme based on one of the existing themes as suggested by
> Julien and Gavin
> 4- Test the theme by switching to it and handle major bugs / issues.
> 5- Start to make a few test screens utilizing Bootstrap



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: entity-auto and cancel operation

[Julien NICOLAS]

+1

Le 06/02/2016 20:54, Pierre Smits a écrit :

What about 'expire'? Seems also appropriate.

Re: entity-auto and cancel operation

[Julien NICOLAS]

I like the idea, when we call delete I imagine that the data is deleted 
from the database.


As Gil said, cancel is not the word, close seems better.

But, what's happen if I call delete ? Do you plan to delete all 
dependent entity ?


Julien.

Le 06/02/2016 17:09, gil portenseigne a écrit :

Hi,

I'd propose "close", for closing de period where the data was active...

But i'm not sure if this is not going too far, the algorithm beneath 
is not quite simple to be an auto thing. When i develop i would prefer 
only updating my GV after setting my closing date.


What do you think ?

Gil

On 06/02/2016 10:18, Nicolas Malin wrote:

Hi guys,

During the simple crud service to entity-auto, I detect the 
remove(Entity) service that didn't remove the generic value from the 
data base put only set the field thruDate to now.


I think this operation isn't in coherence with the service name, yes 
generally the operation is logical on context but not really on the 
abstract interface. I wish introduce a new operation on the 
entity-auto invocation : cancel (or an other nice word that you fell 
better).




The idea, when you call cancel :
 * check if a field date is present on IN service fields and isn't a 
pk -> set at now
 * else check if a field like %statusId is present on IN service 
fields and isn't a pk -> check the related cancel status (if possible 
to resolve it by the StatusType)
 * else check if a thruDate is present and isn't a pk and it's empty 
-> set at now
 * else check if a%thruDate is present and isn't a pk and it's empty 
-> set at now

if one case match, call update

After we would be use the pattern like cancelProductCategoryMember.

default-entity-name="ProductCategoryMember" invoke="cancel" auth="true">

Cancel a ProductCategoryMember
main-action="UPDATE"/>




As usual any suggest are welcome :)

[jira] [Updated] (OFBIZ-6881) Rainbow Stone theme improvements

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS updated OFBIZ-6881:
--
Attachment: MenuFirstProposal.png

> Rainbow Stone theme improvements
> 
>
> Key: OFBIZ-6881
> URL: https://issues.apache.org/jira/browse/OFBIZ-6881
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: MenuFirstProposal.png
>
>
> These are some points I think are worth to be reported even if they will not 
> all  be taken in account.
> # Theme colorization to avoid themes duplication (this also applies to 
> Bootstrap themes)
> # Where are shown the "Last system notes"?
> # -Remove Julien's avatar from the theme images provided (in the list of 
> themes to choose).-
> # Is there a way for users to set their own avatar?
> #  how can contributors from countries with missing flags propose their 
> countries flag? Note: for some languages nothing appears (like ES or NL).
> # I like how menus are handled in Boostrap theme, could we use the same in  
> Rainbow?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6881) Rainbow Stone theme improvements

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134156#comment-15134156
 ] 

Julien NICOLAS commented on OFBIZ-6881:
---

What do you mean Pierre ?
You want to said that it's not easy to understand that you must click on the 
flag to change the language ?

> Rainbow Stone theme improvements
> 
>
> Key: OFBIZ-6881
> URL: https://issues.apache.org/jira/browse/OFBIZ-6881
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: MenuFirstProposal.png
>
>
> These are some points I think are worth to be reported even if they will not 
> all  be taken in account.
> # Theme colorization to avoid themes duplication (this also applies to 
> Bootstrap themes)
> # Where are shown the "Last system notes"?
> # -Remove Julien's avatar from the theme images provided (in the list of 
> themes to choose).-
> # Is there a way for users to set their own avatar?
> #  how can contributors from countries with missing flags propose their 
> countries flag? Note: for some languages nothing appears (like ES or NL).
> # I like how menus are handled in Boostrap theme, could we use the same in  
> Rainbow?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6881) Rainbow Stone theme improvements

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134155#comment-15134155
 ] 

Julien NICOLAS commented on OFBIZ-6881:
---

Thanks :)
You can see that I don't push the "Home menu" and the 2nd level drop down menu. 
This is a technical problem. I need to get the 2nd menu for each applications 
and no function exist for that today.
We have to think on that point because it's not as easy as it seems.

> Rainbow Stone theme improvements
> 
>
> Key: OFBIZ-6881
> URL: https://issues.apache.org/jira/browse/OFBIZ-6881
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: MenuFirstProposal.png
>
>
> These are some points I think are worth to be reported even if they will not 
> all  be taken in account.
> # Theme colorization to avoid themes duplication (this also applies to 
> Bootstrap themes)
> # Where are shown the "Last system notes"?
> # -Remove Julien's avatar from the theme images provided (in the list of 
> themes to choose).-
> # Is there a way for users to set their own avatar?
> #  how can contributors from countries with missing flags propose their 
> countries flag? Note: for some languages nothing appears (like ES or NL).
> # I like how menus are handled in Boostrap theme, could we use the same in  
> Rainbow?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6843) New theme Rainbow Stone

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15132085#comment-15132085
 ] 

Julien NICOLAS commented on OFBIZ-6843:
---

Good news! Tanks for your feedback Jacques :)

> New theme Rainbow Stone
> ---
>
> Key: OFBIZ-6843
> URL: https://issues.apache.org/jira/browse/OFBIZ-6843
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>        Reporter: Julien NICOLAS
>    Assignee: Julien NICOLAS
>Priority: Minor
>  Labels: features, theme
> Fix For: Trunk
>
> Attachments: patch3rainbowstone.patch, rainbowstone.tar.gz, 
> screenshot-1.png
>
>
> I create a new theme based on Flat Grey.
> It's the beginning but already functional, my goal is to provide a new style 
> for OFBiz.
> This is my tastes, so don't hesitate to criticize :)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Release 14.12.01 and Dedication for Adrian

[Julien NICOLAS]

+1!!!

Le 04/02/2016 11:33, Jacques Le Roux a écrit :
That's quite a good idea Sharan, the whole series would not be too 
much in my opinion


Jacques

Le 04/02/2016 09:53, Sharan-F a écrit :

Hi Everyone

Looking at our tentative release schedule we have said that this 
month we
would look at releasing 14.12.01. It has been maturing for over a 
year so

are we ready to begin preparing for its release this month ?

Also we talked about dedicating a release to Adrian so I think we 
could use

this one (or even the whole 14.12 series..). We could add a special
dedication on the Downloads page as part of the release description.

What do people think ?


Thanks
Sharan





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Release-14-12-01-and-Dedication-for-Adrian-tp4676835.html

Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] [Updated] (OFBIZ-6881) Rainbow Stone theme improvements

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS updated OFBIZ-6881:
--
Description: 
These are some points I think are worth to be reported even if they will not 
all  be taken in account.

# Theme colorization to avoid themes duplication (this also applies to 
Bootstrap themes)
# Where are shown the "Last system notes"?
-# Remove Julien's avatar from the theme images provided (in the list of themes 
to choose).-
# Is there a way for users to set their own avatar?
#  how can contributors from countries with missing flags propose their 
countries flag? Note: for some languages nothing appears (like ES or NL).
# I like how menus are handled in Boostrap theme, could we use the same in  
Rainbow?

  was:
These are some points I think are worth to be reported even if they will not 
all  be taken in account.

# Theme colorization to avoid themes duplication (this also applies to 
Bootstrap themes)
# Where are shown the "Last system notes"?
--# Remove Julien's avatar from the theme images provided (in the list of 
themes to choose).  
# Is there a way for users to set their own avatar?
#  how can contributors from countries with missing flags propose their 
countries flag? Note: for some languages nothing appears (like ES or NL).
# I like how menus are handled in Boostrap theme, could we use the same in  
Rainbow?


> Rainbow Stone theme improvements
> 
>
> Key: OFBIZ-6881
> URL: https://issues.apache.org/jira/browse/OFBIZ-6881
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> These are some points I think are worth to be reported even if they will not 
> all  be taken in account.
> # Theme colorization to avoid themes duplication (this also applies to 
> Bootstrap themes)
> # Where are shown the "Last system notes"?
> -# Remove Julien's avatar from the theme images provided (in the list of 
> themes to choose).-
> # Is there a way for users to set their own avatar?
> #  how can contributors from countries with missing flags propose their 
> countries flag? Note: for some languages nothing appears (like ES or NL).
> # I like how menus are handled in Boostrap theme, could we use the same in  
> Rainbow?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6881) Rainbow Stone theme improvements

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS updated OFBIZ-6881:
--
Description: 
These are some points I think are worth to be reported even if they will not 
all  be taken in account.

# Theme colorization to avoid themes duplication (this also applies to 
Bootstrap themes)
# Where are shown the "Last system notes"?
# -Remove Julien's avatar from the theme images provided (in the list of themes 
to choose).-
# Is there a way for users to set their own avatar?
#  how can contributors from countries with missing flags propose their 
countries flag? Note: for some languages nothing appears (like ES or NL).
# I like how menus are handled in Boostrap theme, could we use the same in  
Rainbow?

  was:
These are some points I think are worth to be reported even if they will not 
all  be taken in account.

# Theme colorization to avoid themes duplication (this also applies to 
Bootstrap themes)
# Where are shown the "Last system notes"?
-# Remove Julien's avatar from the theme images provided (in the list of themes 
to choose).-
# Is there a way for users to set their own avatar?
#  how can contributors from countries with missing flags propose their 
countries flag? Note: for some languages nothing appears (like ES or NL).
# I like how menus are handled in Boostrap theme, could we use the same in  
Rainbow?


> Rainbow Stone theme improvements
> 
>
> Key: OFBIZ-6881
> URL: https://issues.apache.org/jira/browse/OFBIZ-6881
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> These are some points I think are worth to be reported even if they will not 
> all  be taken in account.
> # Theme colorization to avoid themes duplication (this also applies to 
> Bootstrap themes)
> # Where are shown the "Last system notes"?
> # -Remove Julien's avatar from the theme images provided (in the list of 
> themes to choose).-
> # Is there a way for users to set their own avatar?
> #  how can contributors from countries with missing flags propose their 
> countries flag? Note: for some languages nothing appears (like ES or NL).
> # I like how menus are handled in Boostrap theme, could we use the same in  
> Rainbow?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6881) Rainbow Stone theme improvements

[Julien NICOLAS (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien NICOLAS updated OFBIZ-6881:
--
Description: 
These are some points I think are worth to be reported even if they will not 
all  be taken in account.

# Theme colorization to avoid themes duplication (this also applies to 
Bootstrap themes)
# Where are shown the "Last system notes"?
--# Remove Julien's avatar from the theme images provided (in the list of 
themes to choose).  
# Is there a way for users to set their own avatar?
#  how can contributors from countries with missing flags propose their 
countries flag? Note: for some languages nothing appears (like ES or NL).
# I like how menus are handled in Boostrap theme, could we use the same in  
Rainbow?

  was:
These are some points I think are worth to be reported even if they will not 
all  be taken in account.

# Theme colorization to avoid themes duplication (this also applies to 
Bootstrap themes)
# Where are shown the "Last system notes"?
# Remove Julien's avatar from the theme images provided (in the list of themes 
to choose).  
# Is there a way for users to set their own avatar?
#  how can contributors from countries with missing flags propose their 
countries flag? Note: for some languages nothing appears (like ES or NL).
# I like how menus are handled in Boostrap theme, could we use the same in  
Rainbow?


> Rainbow Stone theme improvements
> 
>
> Key: OFBIZ-6881
> URL: https://issues.apache.org/jira/browse/OFBIZ-6881
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> These are some points I think are worth to be reported even if they will not 
> all  be taken in account.
> # Theme colorization to avoid themes duplication (this also applies to 
> Bootstrap themes)
> # Where are shown the "Last system notes"?
> --# Remove Julien's avatar from the theme images provided (in the list of 
> themes to choose).  
> # Is there a way for users to set their own avatar?
> #  how can contributors from countries with missing flags propose their 
> countries flag? Note: for some languages nothing appears (like ES or NL).
> # I like how menus are handled in Boostrap theme, could we use the same in  
> Rainbow?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6881) Rainbow Stone theme improvements

[Julien NICOLAS (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133175#comment-15133175
 ] 

Julien NICOLAS commented on OFBIZ-6881:
---

1 - You can see that the theme duplication is only on data. The really 
difference is the .less file.
And in the less file, it's only colour variable that change.
But yes, I want to imagine a theme setting to let user change color.
2 - I remove it, but I'll add it soon :)
3 - Hummm, it's embarrassing... Yes, I'll do it
4 - Yes, just add your personal avatar in party content define as "logo image 
url". A square image is better, I'am using 180x180px
5 - Because flag is define like EN-gb or FR-fr. Try NL-be or ES-ar for example. 
I can define specific default flag but don't know all default language in all 
countries.
6 - For that and more other options, it could be interesting to have a theme 
tweak tools screen with preference. Then we may change menu style, colours and 
more.

> Rainbow Stone theme improvements
> 
>
> Key: OFBIZ-6881
> URL: https://issues.apache.org/jira/browse/OFBIZ-6881
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> These are some points I think are worth to be reported even if they will not 
> all  be taken in account.
> # Theme colorization to avoid themes duplication (this also applies to 
> Bootstrap themes)
> # Where are shown the "Last system notes"?
> # Remove Julien's avatar from the theme images provided (in the list of 
> themes to choose).  
> # Is there a way for users to set their own avatar?
> #  how can contributors from countries with missing flags propose their 
> countries flag? Note: for some languages nothing appears (like ES or NL).
> # I like how menus are handled in Boostrap theme, could we use the same in  
> Rainbow?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)