Re: svn commit: r1726542 - in /ofbiz/trunk/applications/order: script/org/ofbiz/order/communication/ script/org/ofbiz/order/order/ servicedef/ src/org/ofbiz/order/order/

[Deepak Dixit]

Thanks Suraj for reporting,

This has been fixed at r#1831608 and backported to 17.12 and 16.11 as well.



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

On Tue, May 15, 2018 at 11:43 AM, Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:

> Hi Nicolas,
>
> Permission action is not handled properly in this commit while converting
> services to entity-auto. It should be _CREATE, _DELETE instead of CREATE,
> DELETE.
>
> I have created a JIRA for the same here
>  and uploaded a patch
> for review.
> 
>
> --
> Thanks and Regards,
> *Suraj Khurana* | Omni-channel OMS Technical Expert
> HotWax Commerce  by  HotWax Systems
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>
> On Fri, Feb 12, 2016 at 2:45 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Le 12/02/2016 08:23, Nicolas Malin a écrit :
> >
> >>
> >> Hi Jacques
> >>
> >> Le 11/02/2016 23:10, Jacques Le Roux a écrit :
> >>
> >>> Le 11/02/2016 22:27, Jacques Le Roux a écrit :
> >>>
>  Hi Nicolas, All,
> 
>  I globally like the changes, I just have a question.
> 
>  With these changes the OrderSecurityError* properties which were used
>  here are now useless, should we not remove them?
>  Despite the lost, I think it's reasonable because these errors have
>  very few chances to appear, and if they appear it's not so hard to
> find
>  your way through the log.
> 
> >>> Yes I planned to remove all unused label before declare the conversion
> >> end.
> >>
> >>>
> >>> Oops, I did not see the elephant in the room: they are permission
> >>> issues. So I guess the message to the user will be less clear. Not sure
> >>> it's a real issue but we might consider it...
> >>>
> >> By default I return to more generic label (
> http://ofbiz.135035.n4.nabble
> >> .com/entity-auto-improvement-Act-2-td4655973.html) but if you think
> that
> >> it's big lost, I can try to improve the generic order permission
> service to
> >> resolve them
> >>
> >
> > No, it's OK with me, let's go
> >
> > Jacques
> >
> >
> >
> >> Nicolas
> >>
> >>>
> >>> Jacques
> >>>
> >>>
>  Jacques
> 
> 
>  Le 24/01/2016 20:06, nma...@apache.org a écrit :
> 
> > Author: nmalin
> > Date: Sun Jan 24 19:06:32 2016
> > New Revision: 1726542
> >
> > URL: http://svn.apache.org/viewvc?rev=1726542&view=rev
> > Log:
> >
> >
> > I converted following services from simple to entity-auto :
> >
> >  createOrderNotificationLog
> >  createOrderItemBilling
> >  createOrderAdjustment
> >  updateOrderAdjustment
> >  createOrderAdjustmentBilling
> >  createOrderShipment
> >  updateOrderShipment
> >  deleteOrderShipment
> >  createCommunicationEventOrder
> >  removeCommunicationEventOrder
> >  createOrderItemShipGroup
> >  createOrderContactMech
> >  removeOrderContactMech
> >  createOrderTerm
> >  removeOrderTerm
> >  createOrderRequirementCommitment
> >
> > And from java to entity-auto for createOrderPaymentPreference
> > Related issue OFBIZ-6854.
> >
> > Removed:
> > ofbiz/trunk/applications/order/script/org/ofbiz/order/communication/
> > Modified:
> > ofbiz/trunk/applications/order/script/org/ofbiz/order/order/
> > OrderServices.xml
> > ofbiz/trunk/applications/order/script/org/ofbiz/order/order/
> > OrderSimpleMethods.xml
> >  ofbiz/trunk/applications/order/servicedef/services.xml
> > ofbiz/trunk/applications/order/servicedef/services_requirement.xml
> > ofbiz/trunk/applications/order/src/org/ofbiz/order/order/
> > OrderServices.java
> >
> > Modified: ofbiz/trunk/applications/order/script/org/ofbiz/order/
> order/
> > OrderServices.xml
> > URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/
> > script/org/ofbiz/order/order/OrderServices.xml?rev=1726542&
> > r1=1726541&r2=1726542&view=diff
> > 
> > ==
> > --- ofbiz/trunk/applications/order/script/org/ofbiz/order/
> order/OrderServices.xml
> > (original)
> > +++ ofbiz/trunk/applications/order/script/org/ofbiz/order/
> order/OrderServices.xml
> > Sun Jan 24 19:06:32 2016
> > @@ -88,56 +88,8 @@ under the License.
> >> result-name="totalOrders"/>
> >   
> >   
> > - > short-description="Create OrderShipment">
> > -
> > -
> > - > property="OrderSecurityErrorToRunCreateOrderShipment"/>
> > -
> > -
> > -
> > - > entity-name="OrderShipment"/>
> > -
> > -
> > -
> > -
> > -
> > - > short-description="Update Order

Re: svn commit: r1726542 - in /ofbiz/trunk/applications/order: script/org/ofbiz/order/communication/ script/org/ofbiz/order/order/ servicedef/ src/org/ofbiz/order/order/

[Suraj Khurana]

Hi Nicolas,

Permission action is not handled properly in this commit while converting
services to entity-auto. It should be _CREATE, _DELETE instead of CREATE,
DELETE.

I have created a JIRA for the same here
 and uploaded a patch
for review.


--
Thanks and Regards,
*Suraj Khurana* | Omni-channel OMS Technical Expert
HotWax Commerce  by  HotWax Systems
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010

On Fri, Feb 12, 2016 at 2:45 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 12/02/2016 08:23, Nicolas Malin a écrit :
>
>>
>> Hi Jacques
>>
>> Le 11/02/2016 23:10, Jacques Le Roux a écrit :
>>
>>> Le 11/02/2016 22:27, Jacques Le Roux a écrit :
>>>
 Hi Nicolas, All,

 I globally like the changes, I just have a question.

 With these changes the OrderSecurityError* properties which were used
 here are now useless, should we not remove them?
 Despite the lost, I think it's reasonable because these errors have
 very few chances to appear, and if they appear it's not so hard to find
 your way through the log.

>>> Yes I planned to remove all unused label before declare the conversion
>> end.
>>
>>>
>>> Oops, I did not see the elephant in the room: they are permission
>>> issues. So I guess the message to the user will be less clear. Not sure
>>> it's a real issue but we might consider it...
>>>
>> By default I return to more generic label (http://ofbiz.135035.n4.nabble
>> .com/entity-auto-improvement-Act-2-td4655973.html) but if you think that
>> it's big lost, I can try to improve the generic order permission service to
>> resolve them
>>
>
> No, it's OK with me, let's go
>
> Jacques
>
>
>
>> Nicolas
>>
>>>
>>> Jacques
>>>
>>>
 Jacques


 Le 24/01/2016 20:06, nma...@apache.org a écrit :

> Author: nmalin
> Date: Sun Jan 24 19:06:32 2016
> New Revision: 1726542
>
> URL: http://svn.apache.org/viewvc?rev=1726542&view=rev
> Log:
>
>
> I converted following services from simple to entity-auto :
>
>  createOrderNotificationLog
>  createOrderItemBilling
>  createOrderAdjustment
>  updateOrderAdjustment
>  createOrderAdjustmentBilling
>  createOrderShipment
>  updateOrderShipment
>  deleteOrderShipment
>  createCommunicationEventOrder
>  removeCommunicationEventOrder
>  createOrderItemShipGroup
>  createOrderContactMech
>  removeOrderContactMech
>  createOrderTerm
>  removeOrderTerm
>  createOrderRequirementCommitment
>
> And from java to entity-auto for createOrderPaymentPreference
> Related issue OFBIZ-6854.
>
> Removed:
> ofbiz/trunk/applications/order/script/org/ofbiz/order/communication/
> Modified:
> ofbiz/trunk/applications/order/script/org/ofbiz/order/order/
> OrderServices.xml
> ofbiz/trunk/applications/order/script/org/ofbiz/order/order/
> OrderSimpleMethods.xml
>  ofbiz/trunk/applications/order/servicedef/services.xml
> ofbiz/trunk/applications/order/servicedef/services_requirement.xml
> ofbiz/trunk/applications/order/src/org/ofbiz/order/order/
> OrderServices.java
>
> Modified: ofbiz/trunk/applications/order/script/org/ofbiz/order/order/
> OrderServices.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/
> script/org/ofbiz/order/order/OrderServices.xml?rev=1726542&
> r1=1726541&r2=1726542&view=diff
> 
> ==
> --- 
> ofbiz/trunk/applications/order/script/org/ofbiz/order/order/OrderServices.xml
> (original)
> +++ 
> ofbiz/trunk/applications/order/script/org/ofbiz/order/order/OrderServices.xml
> Sun Jan 24 19:06:32 2016
> @@ -88,56 +88,8 @@ under the License.
>    result-name="totalOrders"/>
>   
>   
> - short-description="Create OrderShipment">
> -
> -
> - property="OrderSecurityErrorToRunCreateOrderShipment"/>
> -
> -
> -
> - entity-name="OrderShipment"/>
> -
> -
> -
> -
> -
> - short-description="Update OrderShipment">
> -
> -
> - property="OrderSecurityErrorToRunDeleteOrderShipment"/>
> -
> -
> -
> - value-field="lookedUpValue"/>
> - value-field="lookedUpValue"/>
> -
> -
> - short-description="Delete OrderShipment">
> -
> -
> - property="OrderSecurityErrorToRunDeleteOrderShipment"/>
> -
> -
> -
> - value-field="look

Re: [Discussion] Introduction of Bootstrap and Vue.js

[Shi Jinghai]

Hi Taher,

+1 to the suggestion.

Personally I think Bootstrap and Vue are quite easy. We started a new project 
(a procurement platform) from this April 9th, we happened to choose Bootstrap 
and Vue(Element) as frontend. My team had zero Vue knowledge, and decided to 
use it by their own, the reason they told me is that they tried to play it and 
found they love it. I suggested react and they didn't like it. We bought a 
bootstrap theme, now we have completed v0.1 development and in the middle of 
v0.2. It's going to production this month or next month. Here is our internal 
test environment, hope you like it (BTW it's restarted frequently):

https://111.160.216.2:7235/
Username: TC_10110 or TC_10120
Password: 123456

Another story (bluffing part): my son is in his 3rd year in a university, he 
has just completed a 3-month practical training in Online Media Group of 
Tencent (Tencent is a local company in China) in his spare time, Tencent uses 
react, so he learned react from zero. At the end of the training, he 
contributed more than 1000 lines code to the news feed section of WeChat(a 
popular app in China) which is used by over 700 million android users in China 
every day.

Kind Regards,

Shi Jinghai



-邮件原件-
发件人: Taher Alkhateeb [mailto:slidingfilame...@gmail.com] 
发送时间: 2018年5月13日 2:03
收件人: OFBIZ Development Mailing List
主题: [Discussion] Introduction of Bootstrap and Vue.js

Hello Everyone,

Recently, we at Pythys had some interactions with clients, and the
user interface proved to be a sour point. It is functioning well, but
looks too classic, too rigid, too 2000s really :) We had many
discussion and attempts in the past like [1] [2] [3] [4] [5] [6] [7]
[8] [9] [10] just to name a few all of which seemed not to follow
through.

So what is the problem? Why is this hard to get right? I'm not sure I
have the magic answer, but it seems to me like part of the problem is
simply .. TOO BIG

So I was thinking about a possible solution, and after some initial
research, I think maybe the solution (like everything else) needs to
be slow, incremental and evolutionary rather than revolutionary. So I
am suggesting the following ideas to try and move forward:

- We include the assets for Bootstrap in the common theme. Bootstrap
will give us the Grid system which allows for a responsive website
that works on all devices, it will also give us beautiful widgets to
work with.
- We include Vue.js assets in the common theme. Vue.js is an excellent
framework for creating Single Page Applications (SPAs) to give dynamic
behavior to our pages and create ajax-heavy pages
- We slowly migrate our old CSS to bootstrap constructs. We can begin
for example by replacing our menus, then tables, then headers, then
buttons etc ..
- We slowly introduce dynamic screens using controller logic in Vue.js
- We slowly update our macro library to migrate to the above mentioned
libraries and widgets
- We do all of this live in Trunk, without branching. This means that
for some period of time, there will be transitional code (a little bit
of bootstrap and a little bit of our current code)

We can start with an initial proof of concept skeleton, and if that
gets consensus, then we can move forward with a full implementation in
trunk. I think this issue is many years over due. Our interface looks
oold and really needs a face lift.

What do you think? Ideas? Suggestions?

[1] https://s.apache.org/rf94
[2] https://s.apache.org/g5zr
[3] https://s.apache.org/XpBO
[4] https://s.apache.org/YIL1
[5] https://s.apache.org/836D
[6] https://s.apache.org/DhyB
[7] https://s.apache.org/Lv9E
[8] https://s.apache.org/zKIo
[9] https://s.apache.org/D6jx
[10] https://issues.apache.org/jira/browse/OFBIZ-5840

Re: [Discussion] Introduction of Bootstrap and Vue.js

[Scott Gray]

On Mon, 14 May 2018, 20:38 Taher Alkhateeb, 
wrote:

> Hello Scott, thank you for your thoughts, inline ...
>
> On Mon, May 14, 2018 at 10:45 AM, Scott Gray
>  wrote:
> > I think no matter what we use someone will always want something
> different.
> > I'm beginning to lose count of the number of custom APIs I've written
> over
> > the years to support custom UIs.
> >
> > I think the bigger win would be to start providing APIs and rewriting our
> > existing screens to use them. From there we could start looking at new UI
> > frameworks.
>
> Do you mean by APIs rewriting our XSD files and model objects? Why
> rewrite? Why not just enhance them for new / missing functionality?
> What are the flaws you'd like to redesign?
>

No, I'm talking about web services. With well designed web services custom
projects would be able to build out new user interfaces in a lot less time
and we'd be able to poc new interfaces for the community project without
even touching the existing codebase.


>
> >
> > Most of the projects I've worked on have needed huge amounts of UI
> > customization and having prebuilt APIs would have reduced the workload
> much
> > more than having a shinier UI that still needs to be completely
> rewritten,
> > although I'll admit the latter would probably help the sales process.
>
> The "shiny" part is a plus, but not the core of my suggestion. The
> reasons I suggested these libraries are:
> - bootstrap: the grid system, this is the cake for me. You have a
> powerful responsive grid system for better layouts. The buttons,
> tables and other bling bling are icing on the cake.
> - Vue: The core of this technology is to allow binding of your context
> model to the DOM so that you don't write oodles of JavaScript and
> Jquery to create dynamic behavior. It's really old school in 2018 to
> keep jumping between many pages to get something done.
>
> >
> > Does it not worry anyone else that our service engine still only defines
> a
> > basic map for in/out parameters when the rest of the world is using the
> > likes of swagger and restful APIs?
>
> Of course it worries me, and if you start an initiative I will be the
> first to jump in and volunteer. In fact it's on my todo list, and I
> was looking at multiple options lately and I'm very attracted to
> GraphQL for example because of the reduced visits to the backend.
> However, I don't see this as being related to my proposal here, I'm
> just setting my own priorities of what to work on next. What's wrong
> with starting _both_ initiatives for that matter?
>

Nothing is wrong with both, but as you pointed out many discussions and
efforts have begun and then floundered. I'm simply offering some thoughts
on where I see the most potential benefit from a large scale effort.


>
> >
> > Regards
> > Scott
> >
> > On Sun, 13 May 2018, 06:03 Taher Alkhateeb, 
> > wrote:
> >
> >> Hello Everyone,
> >>
> >> Recently, we at Pythys had some interactions with clients, and the
> >> user interface proved to be a sour point. It is functioning well, but
> >> looks too classic, too rigid, too 2000s really :) We had many
> >> discussion and attempts in the past like [1] [2] [3] [4] [5] [6] [7]
> >> [8] [9] [10] just to name a few all of which seemed not to follow
> >> through.
> >>
> >> So what is the problem? Why is this hard to get right? I'm not sure I
> >> have the magic answer, but it seems to me like part of the problem is
> >> simply .. TOO BIG
> >>
> >> So I was thinking about a possible solution, and after some initial
> >> research, I think maybe the solution (like everything else) needs to
> >> be slow, incremental and evolutionary rather than revolutionary. So I
> >> am suggesting the following ideas to try and move forward:
> >>
> >> - We include the assets for Bootstrap in the common theme. Bootstrap
> >> will give us the Grid system which allows for a responsive website
> >> that works on all devices, it will also give us beautiful widgets to
> >> work with.
> >> - We include Vue.js assets in the common theme. Vue.js is an excellent
> >> framework for creating Single Page Applications (SPAs) to give dynamic
> >> behavior to our pages and create ajax-heavy pages
> >> - We slowly migrate our old CSS to bootstrap constructs. We can begin
> >> for example by replacing our menus, then tables, then headers, then
> >> buttons etc ..
> >> - We slowly introduce dynamic screens using controller logic in Vue.js
> >> - We slowly update our macro library to migrate to the above mentioned
> >> libraries and widgets
> >> - We do all of this live in Trunk, without branching. This means that
> >> for some period of time, there will be transitional code (a little bit
> >> of bootstrap and a little bit of our current code)
> >>
> >> We can start with an initial proof of concept skeleton, and if that
> >> gets consensus, then we can move forward with a full implementation in
> >> trunk. I think this issue is many years over due. Our interface looks
> >> oold and real

Improve look of ecommerce main ftl when checking out

[Jacques Le Roux]

Hi,

Though defined as a list in plugins/ecommerce/template/cart/MiniCart.ftl the

    View Cart
    Check out
    Quick Checkout
    One Page Checkout

block is not vertical but horizontal. I think we should change that to mare it 
more legible

Thanks

Jacques

Re: [Discussion] Introduction of Bootstrap and Vue.js

[Taher Alkhateeb]

Hello Scott, thank you for your thoughts, inline ...

On Mon, May 14, 2018 at 10:45 AM, Scott Gray
 wrote:
> I think no matter what we use someone will always want something different.
> I'm beginning to lose count of the number of custom APIs I've written over
> the years to support custom UIs.
>
> I think the bigger win would be to start providing APIs and rewriting our
> existing screens to use them. From there we could start looking at new UI
> frameworks.

Do you mean by APIs rewriting our XSD files and model objects? Why
rewrite? Why not just enhance them for new / missing functionality?
What are the flaws you'd like to redesign?

>
> Most of the projects I've worked on have needed huge amounts of UI
> customization and having prebuilt APIs would have reduced the workload much
> more than having a shinier UI that still needs to be completely rewritten,
> although I'll admit the latter would probably help the sales process.

The "shiny" part is a plus, but not the core of my suggestion. The
reasons I suggested these libraries are:
- bootstrap: the grid system, this is the cake for me. You have a
powerful responsive grid system for better layouts. The buttons,
tables and other bling bling are icing on the cake.
- Vue: The core of this technology is to allow binding of your context
model to the DOM so that you don't write oodles of JavaScript and
Jquery to create dynamic behavior. It's really old school in 2018 to
keep jumping between many pages to get something done.

>
> Does it not worry anyone else that our service engine still only defines a
> basic map for in/out parameters when the rest of the world is using the
> likes of swagger and restful APIs?

Of course it worries me, and if you start an initiative I will be the
first to jump in and volunteer. In fact it's on my todo list, and I
was looking at multiple options lately and I'm very attracted to
GraphQL for example because of the reduced visits to the backend.
However, I don't see this as being related to my proposal here, I'm
just setting my own priorities of what to work on next. What's wrong
with starting _both_ initiatives for that matter?

>
> Regards
> Scott
>
> On Sun, 13 May 2018, 06:03 Taher Alkhateeb, 
> wrote:
>
>> Hello Everyone,
>>
>> Recently, we at Pythys had some interactions with clients, and the
>> user interface proved to be a sour point. It is functioning well, but
>> looks too classic, too rigid, too 2000s really :) We had many
>> discussion and attempts in the past like [1] [2] [3] [4] [5] [6] [7]
>> [8] [9] [10] just to name a few all of which seemed not to follow
>> through.
>>
>> So what is the problem? Why is this hard to get right? I'm not sure I
>> have the magic answer, but it seems to me like part of the problem is
>> simply .. TOO BIG
>>
>> So I was thinking about a possible solution, and after some initial
>> research, I think maybe the solution (like everything else) needs to
>> be slow, incremental and evolutionary rather than revolutionary. So I
>> am suggesting the following ideas to try and move forward:
>>
>> - We include the assets for Bootstrap in the common theme. Bootstrap
>> will give us the Grid system which allows for a responsive website
>> that works on all devices, it will also give us beautiful widgets to
>> work with.
>> - We include Vue.js assets in the common theme. Vue.js is an excellent
>> framework for creating Single Page Applications (SPAs) to give dynamic
>> behavior to our pages and create ajax-heavy pages
>> - We slowly migrate our old CSS to bootstrap constructs. We can begin
>> for example by replacing our menus, then tables, then headers, then
>> buttons etc ..
>> - We slowly introduce dynamic screens using controller logic in Vue.js
>> - We slowly update our macro library to migrate to the above mentioned
>> libraries and widgets
>> - We do all of this live in Trunk, without branching. This means that
>> for some period of time, there will be transitional code (a little bit
>> of bootstrap and a little bit of our current code)
>>
>> We can start with an initial proof of concept skeleton, and if that
>> gets consensus, then we can move forward with a full implementation in
>> trunk. I think this issue is many years over due. Our interface looks
>> oold and really needs a face lift.
>>
>> What do you think? Ideas? Suggestions?
>>
>> [1] https://s.apache.org/rf94
>> [2] https://s.apache.org/g5zr
>> [3] https://s.apache.org/XpBO
>> [4] https://s.apache.org/YIL1
>> [5] https://s.apache.org/836D
>> [6] https://s.apache.org/DhyB
>> [7] https://s.apache.org/Lv9E
>> [8] https://s.apache.org/zKIo
>> [9] https://s.apache.org/D6jx
>> [10] https://issues.apache.org/jira/browse/OFBIZ-5840
>>

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: Website Translation in French need contributors

[Olivier Heintz]

Hi,

Clearly, with only me, it's not possible to publish it.
I will continue to synch french version because it's not a large task and very 
"automatic" (no thinking, only doing), waiting there are more peoples
interesting by a Apache OFBiz website in french.

For history, I will put a comment to jira to say "no-one, currently want (or 
have time) to support translation, so it's normal that it's not publish"

Thanks to all
Olivier

Le 11/05/2018 à 10:36, Sharan Foga a écrit :
> 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] Introduction of Bootstrap and Vue.js

[Scott Gray]

I think no matter what we use someone will always want something different.
I'm beginning to lose count of the number of custom APIs I've written over
the years to support custom UIs.

I think the bigger win would be to start providing APIs and rewriting our
existing screens to use them. From there we could start looking at new UI
frameworks.

Most of the projects I've worked on have needed huge amounts of UI
customization and having prebuilt APIs would have reduced the workload much
more than having a shinier UI that still needs to be completely rewritten,
although I'll admit the latter would probably help the sales process.

Does it not worry anyone else that our service engine still only defines a
basic map for in/out parameters when the rest of the world is using the
likes of swagger and restful APIs?

Regards
Scott

On Sun, 13 May 2018, 06:03 Taher Alkhateeb, 
wrote:

> Hello Everyone,
>
> Recently, we at Pythys had some interactions with clients, and the
> user interface proved to be a sour point. It is functioning well, but
> looks too classic, too rigid, too 2000s really :) We had many
> discussion and attempts in the past like [1] [2] [3] [4] [5] [6] [7]
> [8] [9] [10] just to name a few all of which seemed not to follow
> through.
>
> So what is the problem? Why is this hard to get right? I'm not sure I
> have the magic answer, but it seems to me like part of the problem is
> simply .. TOO BIG
>
> So I was thinking about a possible solution, and after some initial
> research, I think maybe the solution (like everything else) needs to
> be slow, incremental and evolutionary rather than revolutionary. So I
> am suggesting the following ideas to try and move forward:
>
> - We include the assets for Bootstrap in the common theme. Bootstrap
> will give us the Grid system which allows for a responsive website
> that works on all devices, it will also give us beautiful widgets to
> work with.
> - We include Vue.js assets in the common theme. Vue.js is an excellent
> framework for creating Single Page Applications (SPAs) to give dynamic
> behavior to our pages and create ajax-heavy pages
> - We slowly migrate our old CSS to bootstrap constructs. We can begin
> for example by replacing our menus, then tables, then headers, then
> buttons etc ..
> - We slowly introduce dynamic screens using controller logic in Vue.js
> - We slowly update our macro library to migrate to the above mentioned
> libraries and widgets
> - We do all of this live in Trunk, without branching. This means that
> for some period of time, there will be transitional code (a little bit
> of bootstrap and a little bit of our current code)
>
> We can start with an initial proof of concept skeleton, and if that
> gets consensus, then we can move forward with a full implementation in
> trunk. I think this issue is many years over due. Our interface looks
> oold and really needs a face lift.
>
> What do you think? Ideas? Suggestions?
>
> [1] https://s.apache.org/rf94
> [2] https://s.apache.org/g5zr
> [3] https://s.apache.org/XpBO
> [4] https://s.apache.org/YIL1
> [5] https://s.apache.org/836D
> [6] https://s.apache.org/DhyB
> [7] https://s.apache.org/Lv9E
> [8] https://s.apache.org/zKIo
> [9] https://s.apache.org/D6jx
> [10] https://issues.apache.org/jira/browse/OFBIZ-5840
>