Re: Common-theme next step

2017-08-17 Thread Jacques Le Roux

That sounds great,

Thanks Nicolas!

Jacques

Le 17/08/2017 à 22:00, Nicolas Malin a écrit :

Hello,

I started the documentation here 
https://github.com/nmalin/ofbiz-framework/blob/common-theme/themes/README.md

It's a begging, I hope improve it quickly

Nicolas


Le 16/08/2017 à 13:49, Nicolas Malin a écrit :

Hello;

To continue the common-theme subject, I haven't see negative return to the issue Create a common theme (OFBIZ-9138) [1] and on threads on the same 
subject [2] and the additional theme xml definition [3], I suggest to create a documentation on the wiki how work the "theme engine" and commit the 
current git branch [4] [5] on trunk


After that, the engine will be present on the trunk and we continue the work to 
:
* Clean the common-theme and create a real theme
* Migrate properly the current theme with the new structure
* Analyze more how organize the screen api

But don't panic, before that I'm listening to all suggest or remarks ;)

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-9138
[2] 
https://lists.apache.org/thread.html/6ab61eb5ddeb4669f6e8e15fff44db724a596ecfece34ba4e34ef490@%3Cdev.ofbiz.apache.org%3E
[3] 
https://lists.apache.org/thread.html/8c40f261d2d818aed6f38abe231030204f8f8d6ca8a366b9f040f326@%3Cdev.ofbiz.apache.org%3E
[4] https://github.com/nmalin/ofbiz-framework/tree/common-theme
[5] 
https://github.com/apache/ofbiz-framework/compare/trunk...nmalin:common-theme?expand=1









Re: Common-theme next step

2017-08-17 Thread Nicolas Malin

Hello,

I started the documentation here 
https://github.com/nmalin/ofbiz-framework/blob/common-theme/themes/README.md


It's a begging, I hope improve it quickly

Nicolas


Le 16/08/2017 à 13:49, Nicolas Malin a écrit :

Hello;

To continue the common-theme subject, I haven't see negative return to 
the issue Create a common theme (OFBIZ-9138) [1] and on threads on the 
same subject [2] and the additional theme xml definition [3], I 
suggest to create a documentation on the wiki how work the "theme 
engine" and commit the current git branch [4] [5] on trunk


After that, the engine will be present on the trunk and we continue 
the work to :

* Clean the common-theme and create a real theme
* Migrate properly the current theme with the new structure
* Analyze more how organize the screen api

But don't panic, before that I'm listening to all suggest or remarks ;)

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-9138
[2] 
https://lists.apache.org/thread.html/6ab61eb5ddeb4669f6e8e15fff44db724a596ecfece34ba4e34ef490@%3Cdev.ofbiz.apache.org%3E
[3] 
https://lists.apache.org/thread.html/8c40f261d2d818aed6f38abe231030204f8f8d6ca8a366b9f040f326@%3Cdev.ofbiz.apache.org%3E

[4] https://github.com/nmalin/ofbiz-framework/tree/common-theme
[5] 
https://github.com/apache/ofbiz-framework/compare/trunk...nmalin:common-theme?expand=1







Re: Common-theme next step

2017-08-17 Thread Nicolas Malin

Hi Michael,

Le 17/08/2017 à 10:44, Michael Brohl a écrit :

Hi Nicolas,

thank you very much for your ongoing work on this topic, I greatly 
appreciate it :-)

:) thanks, you escape me from the loneliness


I'm looking forward to have a deeper look into your solutions but have 
to wait until my return on end of August. The concept, as I understand 
it, provides an extendable mechanism to build themes on base of other 
themes, which seems very flexible.
It's exactly the purpose with keep in mind to separate the model and 
convention on framework and all surcharge for the rendering or structure 
page in themes


I'm in favor to have you commit the changes to trunk as long as they 
don't break existing functionality and themes. It would be much easier 
to work together then.
Normally I haven't detected a major regression. Just detect a problem 
when you have some sessions already enabled, when you change your theme, 
it's updated only on the current session where you did it and the newer. 
But the others enabled session keep the previous theme.


If some people are feedback on some regression, I'm really happy to 
understand and resolve it but I'm fear that we need to wait the commit 
in trunk.


Cheers
Nicolas


I'll have some detailed questions which I will put in another message 
to prevent confusion.


Again, thank you very much for your efforts,

Best regards,

Michael



Am 16.08.17 um 13:49 schrieb Nicolas Malin:

Hello;

To continue the common-theme subject, I haven't see negative return 
to the issue Create a common theme (OFBIZ-9138) [1] and on threads on 
the same subject [2] and the additional theme xml definition [3], I 
suggest to create a documentation on the wiki how work the "theme 
engine" and commit the current git branch [4] [5] on trunk


After that, the engine will be present on the trunk and we continue 
the work to :

* Clean the common-theme and create a real theme
* Migrate properly the current theme with the new structure
* Analyze more how organize the screen api

But don't panic, before that I'm listening to all suggest or remarks ;)

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-9138
[2] 
https://lists.apache.org/thread.html/6ab61eb5ddeb4669f6e8e15fff44db724a596ecfece34ba4e34ef490@%3Cdev.ofbiz.apache.org%3E
[3] 
https://lists.apache.org/thread.html/8c40f261d2d818aed6f38abe231030204f8f8d6ca8a366b9f040f326@%3Cdev.ofbiz.apache.org%3E

[4] https://github.com/nmalin/ofbiz-framework/tree/common-theme
[5] 
https://github.com/apache/ofbiz-framework/compare/trunk...nmalin:common-theme?expand=1










buildbot success in on ofbiz-trunk-framework

2017-08-17 Thread buildbot
The Buildbot has detected a restored build on builder ofbiz-trunk-framework 
while building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk-framework/builds/377

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'on-ofbiz-framework-commit' triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1805286
Blamelist: jleroux

Build succeeded!

Sincerely,
 -The Buildbot





buildbot failure in on ofbiz-trunk-framework

2017-08-17 Thread buildbot
The Buildbot has detected a new failure on builder ofbiz-trunk-framework while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk-framework/builds/378

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'on-ofbiz-framework-commit' triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1805290
Blamelist: jleroux

BUILD FAILED: failed shell_2

Sincerely,
 -The Buildbot





buildbot failure in on ofbiz-trunk-framework

2017-08-17 Thread buildbot
The Buildbot has detected a new failure on builder ofbiz-trunk-framework while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk-framework/builds/376

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'on-ofbiz-framework-commit' triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1805285
Blamelist: jleroux

BUILD FAILED: failed shell_2

Sincerely,
 -The Buildbot





Re: Required field indicator (*) is missing for drop down type field.

2017-08-17 Thread Rohit Rai
Sounds good, Jacques. Thanks.

Rohit Rai
www.hotwaxsystems.com



On Thu, Aug 17, 2017 at 4:59 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Rohit,
>
> W/o answers in a week I think we can consider this a consensus and a
> status quo, ie nothing needed on our side
>
> Thanks
>
> Jacques
>
>
> Le 17/08/2017 à 07:39, Rohit Rai a écrit :
>
>> Hello Devs,
>>
>> In a form, the background color of a required field is yellow and an
>> asterisk symbol is shown next to it. But, if the required field is drop
>> down type, no asterisk symbol is shown near it.
>>
>> As per the discussion on OFBIZ-7439
>> , we can think of two
>> ways to take it forward. Either, we can continue with the above behavior
>> or
>> we can update the code to show an asterisk symbol next to drop down type
>> field.
>>
>> I would appreciate hearing communities thoughts over this.
>>
>> Rohit Rai
>> www.hotwaxsystems.com
>>
>>
>


Re: [PROPOSAL] Lead Source should be associated with the Lead only

2017-08-17 Thread Aditya Sharma
I have created a Jira for it at
https://issues.apache.org/jira/browse/OFBIZ-9588.

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Thu, Aug 10, 2017 at 2:01 PM, Aditya Sharma  wrote:

> Thanks Jacques.
> Moving the conversation to dev ML.
>
> Thanks and Regards,
>
> *Aditya Sharma* | Enterprise Software Engineer
> HotWax Systems 
> 
>
> On Thu, Aug 10, 2017 at 12:06 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Hi Aditya,
>>
>> I believe this conversation should rather be on dev ML
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 04/08/2017 à 16:23, Aditya Sharma a écrit :
>>
>>> Lead Source is essential information for assessing the effectiveness of
>>> marketing campaigns. It defines the primary source from which the given
>>> lead came from i.e. how the lead found the organization.
>>>
>>> While working in SFA component, I observed that when we create a Lead &
>>> select Lead Source from New Lead page it is not associated with lead.
>>> When
>>> we provide Group Name it is associated with Group and not with the Lead.
>>> However. when we add Lead Source from the Lead Profile page, it is
>>> associated with the lead only.
>>>
>>> These 2 pages contradict each other in terms of their business process.
>>>
>>> The sole purpose of Lead Source is to define the source of a lead, not
>>> the
>>> source of a group.
>>>
>>> I propose that we should update "createLead" service to associate Lead
>>> Source to Lead only.
>>>
>>> Please enlighten me if I missed out something here.
>>>
>>> Links to verify
>>> New Lead Page: https://demo-trunk.ofbiz.apache.org/sfa/control/NewLead
>>> Lead Profile Page:
>>> https://demo-trunk.ofbiz.apache.org/sfa/control/viewprofile?
>>> roleTypeId=LEAD=sfa101
>>>
>>> Thanks and Regards,
>>>
>>> *Aditya Sharma* | Enterprise Software Engineer
>>> HotWax Systems 
>>> 
>>>
>>>
>>
>


Re: Required field indicator (*) is missing for drop down type field.

2017-08-17 Thread Jacques Le Roux

Hi Rohit,

W/o answers in a week I think we can consider this a consensus and a status 
quo, ie nothing needed on our side

Thanks

Jacques


Le 17/08/2017 à 07:39, Rohit Rai a écrit :

Hello Devs,

In a form, the background color of a required field is yellow and an
asterisk symbol is shown next to it. But, if the required field is drop
down type, no asterisk symbol is shown near it.

As per the discussion on OFBIZ-7439
, we can think of two
ways to take it forward. Either, we can continue with the above behavior or
we can update the code to show an asterisk symbol next to drop down type
field.

I would appreciate hearing communities thoughts over this.

Rohit Rai
www.hotwaxsystems.com





Re: [Proposal] - Leverage the CMS capability for Product Store's Email

2017-08-17 Thread Renuka Srishti
+1 Swapnil

Thanks & Regards,

On Thu, Aug 17, 2017 at 2:42 PM, Marek Mosiewicz 
wrote:

> 17.08.2017 10:56 "Aditya Sharma" 
> napisał(a):
>
> > +1
> >
> > Thanks and Regards,
> >
> > *Aditya Sharma* | Enterprise Software Engineer
> > HotWax Systems 
> > 
> >
> > On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
> > arun.pati...@hotwaxsystems.com> wrote:
> >
> > > +1 Swapnil for content driven template.
> > >
> > > Also, like idea to remove redundancy of email templates settings.
> > >
> > > --
> > > Thanks & Regards
> > > ---
> > > Arun Patidar
> > > Manager, Enterprise Software Development
> > >
> > >
> > > HotWax Systems Pvt Ltd.www.hotwaxsystems.com
> > >
> > >
> > > On Thu, Aug 17, 2017 at 10:19 AM, Swapnil Mane <
> > > swapnil.m...@hotwaxsystems.com> wrote:
> > >
> > > > Thanks Nicolas for your inputs and sharing more details. This
> proposed
> > > > model is making sense to me.
> > > > Please give me some more time to look into the details, will get back
> > to
> > > > you in next week.
> > > >
> > > > Also, please see my comments inline.
> > > >
> > > > On Tue, Aug 15, 2017 at 1:52 AM, Nicolas Malin <
> > nicolas.ma...@nereide.fr
> > > >
> > > > wrote:
> > > >
> > > > > Hello Swapnil, in line
> > > > >
> > > > >
> > > > > Le 14/08/2017 à 04:35, Swapnil Mane a écrit :
> > > > >
> > > > >> Thank you Nicolas for your inputs and interest. I highly
> appreciate
> > > it.
> > > > >>
> > > > >> Based on my understanding, please see my comments inline and let
> me
> > > know
> > > > >> if
> > > > >> you have further inputs.
> > > > >>
> > > > >> On Fri, Aug 11, 2017 at 3:10 PM, Nicolas Malin <
> > > > nicolas.ma...@nereide.fr>
> > > > >> wrote:
> > > > >>
> > > > >> Hello Swapnil,
> > > > >>>
> > > > >>> In past I tried to refactoring email interface with the idea to :
> > > > >>> * deprecate current ProductStoreEmailSetting to link it to
> > > > >>> TemplateEmailSetting. The purpose is to centralize all email
> > > > >>> configuration
> > > > >>> in this entity
> > > > >>>
> > > > >>> We may have multiple product store and can have different email
> > > > templates
> > > > >> for them, ProductStoreEmailSetting will allow us to do that.
> > > > >>
> > > > > My fault, I'm not clear. ProductStoreEmailSetting and
> > > > EmailTemplateSetting
> > > > > are redundancy,
> > > > > I'm in favor to keep all email template information in
> > > > > EmailTemplateSetting and use ProductStoreEmailTemplate to link a
> > email
> > > > > template to a productStore throw a purpose.
> > > > > So we can deprecate all email template fields in
> > > ProductStoreEmailSetting
> > > > > to centralize all this part in EmailTemplateSetting
> > > > >
> > > >
> > > > +1
> > > >
> > > >
> > > > > * link TemplateEmailSetting with Content through
> > > > >>> TemplateEmailSettingContent and TemplateEmailSettingContentType.
> > > This
> > > > >>> offert the possibilty to link header, body, footer or some more
> > > complex
> > > > >>> case like link documents, pdf invoice, order, etc ...
> > > > >>>
> > > > >>> Having content model with us, the customizable header, footer
> > > > >> (decoratorContentId at content level) and other complex case can
> be
> > > > >> handled
> > > > >> easily with content model.
> > > > >>
> > > > > Completely, except for attached file. I agree for rendering the
> email
> > > > > content, but if you want link the file to your email its more
> easier
> > to
> > > > > indicate it on EmailTemplateSetting.
> > > > >
> > > > > An example, when you send a order confirmation, you want attach to
> > this
> > > > > email the the legal notice. We would be link directly the contentId
> > > where
> > > > > is the legal notice and an other content for the email body.
> > > > >
> > > >
> > > > I guess, this can be achieved by ContentAssoc model, but yes, your
> > > proposal
> > > > of using TemplateEmailSettingContent and
> TemplateEmailSettingContentTyp
> > e
> > > > is
> > > > also looks reasonable to me.
> > > >
> > > >
> > > > > * review all send email function to manage the content rendering
> > > > >>> Yes, during the proposed implementation, we were planning to do
> > this
> > > as
> > > > >>> well.
> > > > >>>
> > > > >>> But the time has been missed :(
> > > > >>> If you are motivate, we can try to revive this idea ?
> > > > >>>
> > > > >>
> > > > >> :-)
> > > > >> I would love to hear more about your idea, will it be possible for
> > you
> > > > to
> > > > >> share more information about this.
> > > > >>
> > > > > The issue where I started https://issues.apache.org/
> > > > jira/browse/OFBIZ-4333
> > > > >
> > > > > Nicolas
> > > > >
> > > >
> > > >
> > > >
> > > > - Best Regards,
> > > > Swapnil M Mane,
> > > > www.hotwaxsystems.com
> > > > www.hotwax.co
> > > >
> > >
> >
>



-- 
Renuka Srishti


Re: [Proposal] - Leverage the CMS capability for Product Store's Email

2017-08-17 Thread Marek Mosiewicz
17.08.2017 10:56 "Aditya Sharma" 
napisał(a):

> +1
>
> Thanks and Regards,
>
> *Aditya Sharma* | Enterprise Software Engineer
> HotWax Systems 
> 
>
> On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
> arun.pati...@hotwaxsystems.com> wrote:
>
> > +1 Swapnil for content driven template.
> >
> > Also, like idea to remove redundancy of email templates settings.
> >
> > --
> > Thanks & Regards
> > ---
> > Arun Patidar
> > Manager, Enterprise Software Development
> >
> >
> > HotWax Systems Pvt Ltd.www.hotwaxsystems.com
> >
> >
> > On Thu, Aug 17, 2017 at 10:19 AM, Swapnil Mane <
> > swapnil.m...@hotwaxsystems.com> wrote:
> >
> > > Thanks Nicolas for your inputs and sharing more details. This proposed
> > > model is making sense to me.
> > > Please give me some more time to look into the details, will get back
> to
> > > you in next week.
> > >
> > > Also, please see my comments inline.
> > >
> > > On Tue, Aug 15, 2017 at 1:52 AM, Nicolas Malin <
> nicolas.ma...@nereide.fr
> > >
> > > wrote:
> > >
> > > > Hello Swapnil, in line
> > > >
> > > >
> > > > Le 14/08/2017 à 04:35, Swapnil Mane a écrit :
> > > >
> > > >> Thank you Nicolas for your inputs and interest. I highly appreciate
> > it.
> > > >>
> > > >> Based on my understanding, please see my comments inline and let me
> > know
> > > >> if
> > > >> you have further inputs.
> > > >>
> > > >> On Fri, Aug 11, 2017 at 3:10 PM, Nicolas Malin <
> > > nicolas.ma...@nereide.fr>
> > > >> wrote:
> > > >>
> > > >> Hello Swapnil,
> > > >>>
> > > >>> In past I tried to refactoring email interface with the idea to :
> > > >>> * deprecate current ProductStoreEmailSetting to link it to
> > > >>> TemplateEmailSetting. The purpose is to centralize all email
> > > >>> configuration
> > > >>> in this entity
> > > >>>
> > > >>> We may have multiple product store and can have different email
> > > templates
> > > >> for them, ProductStoreEmailSetting will allow us to do that.
> > > >>
> > > > My fault, I'm not clear. ProductStoreEmailSetting and
> > > EmailTemplateSetting
> > > > are redundancy,
> > > > I'm in favor to keep all email template information in
> > > > EmailTemplateSetting and use ProductStoreEmailTemplate to link a
> email
> > > > template to a productStore throw a purpose.
> > > > So we can deprecate all email template fields in
> > ProductStoreEmailSetting
> > > > to centralize all this part in EmailTemplateSetting
> > > >
> > >
> > > +1
> > >
> > >
> > > > * link TemplateEmailSetting with Content through
> > > >>> TemplateEmailSettingContent and TemplateEmailSettingContentType.
> > This
> > > >>> offert the possibilty to link header, body, footer or some more
> > complex
> > > >>> case like link documents, pdf invoice, order, etc ...
> > > >>>
> > > >>> Having content model with us, the customizable header, footer
> > > >> (decoratorContentId at content level) and other complex case can be
> > > >> handled
> > > >> easily with content model.
> > > >>
> > > > Completely, except for attached file. I agree for rendering the email
> > > > content, but if you want link the file to your email its more easier
> to
> > > > indicate it on EmailTemplateSetting.
> > > >
> > > > An example, when you send a order confirmation, you want attach to
> this
> > > > email the the legal notice. We would be link directly the contentId
> > where
> > > > is the legal notice and an other content for the email body.
> > > >
> > >
> > > I guess, this can be achieved by ContentAssoc model, but yes, your
> > proposal
> > > of using TemplateEmailSettingContent and TemplateEmailSettingContentTyp
> e
> > > is
> > > also looks reasonable to me.
> > >
> > >
> > > > * review all send email function to manage the content rendering
> > > >>> Yes, during the proposed implementation, we were planning to do
> this
> > as
> > > >>> well.
> > > >>>
> > > >>> But the time has been missed :(
> > > >>> If you are motivate, we can try to revive this idea ?
> > > >>>
> > > >>
> > > >> :-)
> > > >> I would love to hear more about your idea, will it be possible for
> you
> > > to
> > > >> share more information about this.
> > > >>
> > > > The issue where I started https://issues.apache.org/
> > > jira/browse/OFBIZ-4333
> > > >
> > > > Nicolas
> > > >
> > >
> > >
> > >
> > > - Best Regards,
> > > Swapnil M Mane,
> > > www.hotwaxsystems.com
> > > www.hotwax.co
> > >
> >
>


Re: Deadlock on InventoryItem during load test

2017-08-17 Thread Arun Patidar
Hello Taher, All,

We are now able to proceed ahead with deadlock condition.  Thanks Scott and
Jacopo for discussing and suggesting solution.

We fixed it by acquiring all InventoryItem records that are going to affect
by inventory reservation and item issuance process of order. Acquiring of
record means that we performed delegator.storeByCondition() operation on
all selected inventoryItem records before actual reservation and issuance.

This solution is still an experiment. I believe that some refactoring and
data model changes in inventory management process will require for getting
proper fix.



-- 
Thanks & Regards
---
Arun Patidar
Manager, Enterprise Software Development


HotWax Systems Pvt Ltd.www.hotwaxsystems.com


On Thu, Jul 27, 2017 at 10:04 AM, Arun Patidar <
arun.pati...@hotwaxsystems.com> wrote:

> Hello Taher, All,
>
> I have added details on ticket regarding my test plan. Also, attached
> Jmeter script which creates and fulfil sales orders. I am still working on
> this and will share more updates.
>
>
>
> --
> Thanks & Regards
> ---
> Arun Patidar
> Manager, Enterprise Software Development
>
>
> HotWax Systems Pvt Ltd.www.hotwaxsystems.com
>
>
> On Wed, Jul 12, 2017 at 6:23 PM, Arun Patidar  com> wrote:
>
>> Hello Taher,
>>
>> Created a JIRA ticket OFBIZ-9491
>>  and added some more
>> details.
>>
>> --
>> Thanks & Regards
>> ---
>> Arun Patidar
>> Manager, Enterprise Software Development
>>
>>
>> HotWax Systems Pvt Ltd.www.hotwaxsystems.com
>>
>>
>> On Wed, Jul 12, 2017 at 5:45 PM, Arun Patidar <
>> arun.pati...@hotwaxsystems.com> wrote:
>>
>>> Thanks Taher for showing interest. I will create a Jira issue with more
>>> details and share it with you.
>>>
>>> --
>>> Thanks & Regards
>>> ---
>>> Arun Patidar
>>> Manager, Enterprise Software Development
>>>
>>>
>>> HotWax Systems Pvt Ltd.www.hotwaxsystems.com
>>>
>>>
>>> On Wed, Jul 12, 2017 at 4:12 PM, Taher Alkhateeb <
>>> slidingfilame...@gmail.com> wrote:
>>>
 If there is a JIRA with exact repeat steps then I would be interested
 in working on this issue as it sounds like a good place to do some
 proper refactoring on many moving parts.

 On Wed, Jul 12, 2017 at 12:08 PM, Arun Patidar
  wrote:
 > Hello All,
 >
 > I was trying to load test OFBiz with huge numbers of order creation
 and
 > fulfilment. During test, I found a deadlock on InventoryItem enttiy.
 > Current system, invoke 'UpdateInventoryItemFromDetail' service to
 update
 > InventoryItem QOH total and ATP total record. There is an Eca rule on
 > create/update of InventoryItemDetail entity record which triggers
 service
 > 'UpdateInventoryItemFromDetail'. So, with heavy load, InventoryItem
 record
 > get lock and create deadlock condition.
 >
 > I know that most of you are already aware with this issue. Please let
 me
 > know if someone worked on it and have any idea to avoid this type of
 > deadlock.
 >
 > --
 > Thanks & Regards
 > ---
 > Arun Patidar
 > Manager, Enterprise Software Development
 >
 >
 > HotWax Systems Pvt Ltd.www.hotwaxsystems.com

>>>
>>>
>>
>


common-theme questions, was: Re: Common-theme next step

2017-08-17 Thread Michael Brohl

Hi Nicolas,

During my work on the bootstrap theme [1] (which got stuck due to other 
tasks) I stumbled upon some problems which possibly get solved by your 
approach or we can consider a solution for it during the work.


In detail, I'm referring to [2] where you had the same problem I'm 
facing: Instead of displaying the application menu bar when it is active 
I want to have the menu items as sub level items in a global navigation 
sidebar. It does not seem to be possible completely dynamically because 
of the configuration inside the screen definitions but it might be 
better doable if we would have a configuration standard for the menus, 
using always the same patterns (convention over configuration).


Do you already have an idea how to solve this/ will the new approach 
help with this?


Another base question is how we can provide different style classes and 
ids to the base html code so that we can reuse the html but use 
different UI frameworks with their specific style class terminology. It 
would be great if users can choose their preferred UI framework like 
Bootstrap, Foundation & Co. to build new themes. Will this be covered by 
your approach?


[1] 
https://lists.apache.org/thread.html/de49bb2fd2f9c82ab99bd08e603e9625c9c5a532a80b5226ccd5a4fc@%3Cdev.ofbiz.apache.org%3E


[2] 
https://lists.apache.org/thread.html/91e3e5cab3b233f9587d69f0419eb652744cc5afcd39bc97df269ace@1444926106@%3Cuser.ofbiz.apache.org%3E


Thanks,
Michael


Am 16.08.17 um 13:49 schrieb Nicolas Malin:

Hello;

To continue the common-theme subject, I haven't see negative return to 
the issue Create a common theme (OFBIZ-9138) [1] and on threads on the 
same subject [2] and the additional theme xml definition [3], I 
suggest to create a documentation on the wiki how work the "theme 
engine" and commit the current git branch [4] [5] on trunk


After that, the engine will be present on the trunk and we continue 
the work to :

* Clean the common-theme and create a real theme
* Migrate properly the current theme with the new structure
* Analyze more how organize the screen api

But don't panic, before that I'm listening to all suggest or remarks ;)

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-9138
[2] 
https://lists.apache.org/thread.html/6ab61eb5ddeb4669f6e8e15fff44db724a596ecfece34ba4e34ef490@%3Cdev.ofbiz.apache.org%3E
[3] 
https://lists.apache.org/thread.html/8c40f261d2d818aed6f38abe231030204f8f8d6ca8a366b9f040f326@%3Cdev.ofbiz.apache.org%3E

[4] https://github.com/nmalin/ofbiz-framework/tree/common-theme
[5] 
https://github.com/apache/ofbiz-framework/compare/trunk...nmalin:common-theme?expand=1








smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Proposal] - Leverage the CMS capability for Product Store's Email

2017-08-17 Thread Aditya Sharma
+1

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
arun.pati...@hotwaxsystems.com> wrote:

> +1 Swapnil for content driven template.
>
> Also, like idea to remove redundancy of email templates settings.
>
> --
> Thanks & Regards
> ---
> Arun Patidar
> Manager, Enterprise Software Development
>
>
> HotWax Systems Pvt Ltd.www.hotwaxsystems.com
>
>
> On Thu, Aug 17, 2017 at 10:19 AM, Swapnil Mane <
> swapnil.m...@hotwaxsystems.com> wrote:
>
> > Thanks Nicolas for your inputs and sharing more details. This proposed
> > model is making sense to me.
> > Please give me some more time to look into the details, will get back to
> > you in next week.
> >
> > Also, please see my comments inline.
> >
> > On Tue, Aug 15, 2017 at 1:52 AM, Nicolas Malin  >
> > wrote:
> >
> > > Hello Swapnil, in line
> > >
> > >
> > > Le 14/08/2017 à 04:35, Swapnil Mane a écrit :
> > >
> > >> Thank you Nicolas for your inputs and interest. I highly appreciate
> it.
> > >>
> > >> Based on my understanding, please see my comments inline and let me
> know
> > >> if
> > >> you have further inputs.
> > >>
> > >> On Fri, Aug 11, 2017 at 3:10 PM, Nicolas Malin <
> > nicolas.ma...@nereide.fr>
> > >> wrote:
> > >>
> > >> Hello Swapnil,
> > >>>
> > >>> In past I tried to refactoring email interface with the idea to :
> > >>> * deprecate current ProductStoreEmailSetting to link it to
> > >>> TemplateEmailSetting. The purpose is to centralize all email
> > >>> configuration
> > >>> in this entity
> > >>>
> > >>> We may have multiple product store and can have different email
> > templates
> > >> for them, ProductStoreEmailSetting will allow us to do that.
> > >>
> > > My fault, I'm not clear. ProductStoreEmailSetting and
> > EmailTemplateSetting
> > > are redundancy,
> > > I'm in favor to keep all email template information in
> > > EmailTemplateSetting and use ProductStoreEmailTemplate to link a email
> > > template to a productStore throw a purpose.
> > > So we can deprecate all email template fields in
> ProductStoreEmailSetting
> > > to centralize all this part in EmailTemplateSetting
> > >
> >
> > +1
> >
> >
> > > * link TemplateEmailSetting with Content through
> > >>> TemplateEmailSettingContent and TemplateEmailSettingContentType.
> This
> > >>> offert the possibilty to link header, body, footer or some more
> complex
> > >>> case like link documents, pdf invoice, order, etc ...
> > >>>
> > >>> Having content model with us, the customizable header, footer
> > >> (decoratorContentId at content level) and other complex case can be
> > >> handled
> > >> easily with content model.
> > >>
> > > Completely, except for attached file. I agree for rendering the email
> > > content, but if you want link the file to your email its more easier to
> > > indicate it on EmailTemplateSetting.
> > >
> > > An example, when you send a order confirmation, you want attach to this
> > > email the the legal notice. We would be link directly the contentId
> where
> > > is the legal notice and an other content for the email body.
> > >
> >
> > I guess, this can be achieved by ContentAssoc model, but yes, your
> proposal
> > of using TemplateEmailSettingContent and TemplateEmailSettingContentType
> > is
> > also looks reasonable to me.
> >
> >
> > > * review all send email function to manage the content rendering
> > >>> Yes, during the proposed implementation, we were planning to do this
> as
> > >>> well.
> > >>>
> > >>> But the time has been missed :(
> > >>> If you are motivate, we can try to revive this idea ?
> > >>>
> > >>
> > >> :-)
> > >> I would love to hear more about your idea, will it be possible for you
> > to
> > >> share more information about this.
> > >>
> > > The issue where I started https://issues.apache.org/
> > jira/browse/OFBIZ-4333
> > >
> > > Nicolas
> > >
> >
> >
> >
> > - Best Regards,
> > Swapnil M Mane,
> > www.hotwaxsystems.com
> > www.hotwax.co
> >
>


Re: Common-theme next step

2017-08-17 Thread Michael Brohl

Hi Nicolas,

thank you very much for your ongoing work on this topic, I greatly 
appreciate it :-)


I'm looking forward to have a deeper look into your solutions but have 
to wait until my return on end of August. The concept, as I understand 
it, provides an extendable mechanism to build themes on base of other 
themes, which seems very flexible.


I'm in favor to have you commit the changes to trunk as long as they 
don't break existing functionality and themes. It would be much easier 
to work together then.


I'll have some detailed questions which I will put in another message to 
prevent confusion.


Again, thank you very much for your efforts,

Best regards,

Michael



Am 16.08.17 um 13:49 schrieb Nicolas Malin:

Hello;

To continue the common-theme subject, I haven't see negative return to 
the issue Create a common theme (OFBIZ-9138) [1] and on threads on the 
same subject [2] and the additional theme xml definition [3], I 
suggest to create a documentation on the wiki how work the "theme 
engine" and commit the current git branch [4] [5] on trunk


After that, the engine will be present on the trunk and we continue 
the work to :

* Clean the common-theme and create a real theme
* Migrate properly the current theme with the new structure
* Analyze more how organize the screen api

But don't panic, before that I'm listening to all suggest or remarks ;)

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-9138
[2] 
https://lists.apache.org/thread.html/6ab61eb5ddeb4669f6e8e15fff44db724a596ecfece34ba4e34ef490@%3Cdev.ofbiz.apache.org%3E
[3] 
https://lists.apache.org/thread.html/8c40f261d2d818aed6f38abe231030204f8f8d6ca8a366b9f040f326@%3Cdev.ofbiz.apache.org%3E

[4] https://github.com/nmalin/ofbiz-framework/tree/common-theme
[5] 
https://github.com/apache/ofbiz-framework/compare/trunk...nmalin:common-theme?expand=1








smime.p7s
Description: S/MIME Cryptographic Signature