date:20150624


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

Nicolas Malin commented on OFBIZ-6526:
--

Christian you have a doubt to don't commit your patch ?

> ordermgr/control/searchorders findOrders service returns incorrect orderCount 
> and therefore viewSize
> 
>
> Key: OFBIZ-6526
> URL: https://issues.apache.org/jira/browse/OFBIZ-6526
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Trunk
>Reporter: Christian Carlow
> Attachments: OFBIZ-6526.patch
>
>




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

[jira] [Resolved] (OFBIZ-6198) Show estimatedShipDate for ordershippinginfo.ftl


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

Nicolas Malin resolved OFBIZ-6198.
--
   Resolution: Implemented
Fix Version/s: Upcoming Branch

sorry for the noise, bad resolution value set previously 

> Show estimatedShipDate for ordershippinginfo.ftl
> 
>
> Key: OFBIZ-6198
> URL: https://issues.apache.org/jira/browse/OFBIZ-6198
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Nicolas Malin
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6198.patch
>
>
> OrderItemShipGroup.estimatedShipDate should have a renderDateTimeField 
> available at ordermgr/control/orderview in ordershippinginfo.ftl.  OFBIZ-6197 
> proposes allowing production runs to be generated from 
> OrderItemShipGroupAssoc and I think the production run 
> estimatedCompletionDate should be set to the corresponding 
> OrderItemShipGroup.estimatedShipDate.



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

[jira] [Closed] (OFBIZ-6198) Show estimatedShipDate for ordershippinginfo.ftl


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

Nicolas Malin closed OFBIZ-6198.


> Show estimatedShipDate for ordershippinginfo.ftl
> 
>
> Key: OFBIZ-6198
> URL: https://issues.apache.org/jira/browse/OFBIZ-6198
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Nicolas Malin
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6198.patch
>
>
> OrderItemShipGroup.estimatedShipDate should have a renderDateTimeField 
> available at ordermgr/control/orderview in ordershippinginfo.ftl.  OFBIZ-6197 
> proposes allowing production runs to be generated from 
> OrderItemShipGroupAssoc and I think the production run 
> estimatedCompletionDate should be set to the corresponding 
> OrderItemShipGroup.estimatedShipDate.



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

[jira] [Resolved] (OFBIZ-6198) Show estimatedShipDate for ordershippinginfo.ftl


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

Nicolas Malin resolved OFBIZ-6198.
--
Resolution: Fixed

Christian, I commit the possibility to display estimated ship and delivery date 
on the orderItemShip group on trunk revision 1687371.

Your patch contains an other modification on quickReturn that I ignored because 
this wasn't in relation with this issue

> Show estimatedShipDate for ordershippinginfo.ftl
> 
>
> Key: OFBIZ-6198
> URL: https://issues.apache.org/jira/browse/OFBIZ-6198
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Nicolas Malin
> Attachments: OFBIZ-6198.patch
>
>
> OrderItemShipGroup.estimatedShipDate should have a renderDateTimeField 
> available at ordermgr/control/orderview in ordershippinginfo.ftl.  OFBIZ-6197 
> proposes allowing production runs to be generated from 
> OrderItemShipGroupAssoc and I think the production run 
> estimatedCompletionDate should be set to the corresponding 
> OrderItemShipGroup.estimatedShipDate.



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

[jira] [Reopened] (OFBIZ-6198) Show estimatedShipDate for ordershippinginfo.ftl


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

Nicolas Malin reopened OFBIZ-6198:
--

> Show estimatedShipDate for ordershippinginfo.ftl
> 
>
> Key: OFBIZ-6198
> URL: https://issues.apache.org/jira/browse/OFBIZ-6198
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Nicolas Malin
> Attachments: OFBIZ-6198.patch
>
>
> OrderItemShipGroup.estimatedShipDate should have a renderDateTimeField 
> available at ordermgr/control/orderview in ordershippinginfo.ftl.  OFBIZ-6197 
> proposes allowing production runs to be generated from 
> OrderItemShipGroupAssoc and I think the production run 
> estimatedCompletionDate should be set to the corresponding 
> OrderItemShipGroup.estimatedShipDate.



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

[jira] [Commented] (OFBIZ-6528) Add a mean to untie geo associations


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

Jacques Le Roux commented on OFBIZ-6528:


Thanks for report, just done

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch, OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

Hi Pierre

No offense taken.  I would like to hear from Julien on this issue so we can
move it forward.

Gavin

On Wed, Jun 24, 2015 at 4:05 PM, Pierre Smits 
wrote:

> Gavin,
>
> Please don't see my posting as an attack on anyone participating in the
> branch. It is just a reflection of my observation infused with a viewpoint.
> I appreciate what has been done.
>
> And, how to do skin variants has popped up before in relation to ecommerce.
> See various mail threads in devML. So, the effort applied and the result
> achieved validate the added goal of the Bootstrap PoC.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Jun 24, 2015 at 3:54 PM, Gavin Mabie  wrote:
>
> > Hi Pierre
> >
> >
> > > Bootstrap Sunrise is, in effect, a beautification effort on top of
> > > Bootstrap Basic. Where the Bootstrap dev branch started out as a kind
> of
> > > Proof of Concept branch (proving that OFBiz could be leveraged to use
> the
> > > Bootstrap web framework, and investigating/implementing what was
> required
> > > to have).
> >
> >
> > When I initially included the "Bootstrap Tomahawk" theme,  the purpose
> was
> > solely to indicate how easy it would be to develop skins for a theme.
> > Naturally some might think that it is a "beautification", but that is a
> > matter of opinion.  In the real world you may find clients who do not
> agree
> > with this notion.  It's for this reason that most designers first
> present a
> > vanilla look-and-feel so that clients can bring their preferences into
> the
> > mix.  As a community our goal should be to present Ofbiz as visually
> > appealing as possible without being too prescriptive in terms of
> > look-and-feel.  Most projects do this by using generic (if not bland)
> > look-and-feel's for their apps.  Hence "Basic".  BTW Bootstrap is not a
> web
> > framework!
> >
> > With the effort spent on the additional skin (started as bootstrapped
> > > Tomahawk variant, now dubbed Sunrise), we went beyond that initial
> goal.
> > >
> > >
> > Going beyond the initial goal is perhaps at the crux of it.  I personally
> > think it is too early to do this.  There are other, higher priority
> issues
> > that need addressing before we get sexy on this. For one, we haven't
> dealt
> > with responsiveness sufficiently.  While we have demonstrated that the
> > Ofbiz framework is flexible enough to handle Bootstrap and perhaps any
> > other JavaScript framework, we have yet to address HTML 5 issues.
> >
> > Yet introducing another set of difficulties, being the effect of changes
> in
> > > the ftl files for the one on the other.
> >
> >
> > I don't agree with the idea that these are difficulties.  It is a simple
> > solution to the problem arising from treating "Sunrise" as a theme.
> Also,
> > it acknowledges the work done by Julien in line with the "People before
> > Code" mantra.
> >
> > That is why I created https://issues.apache.org/jira/browse/OFBIZ-6467,
> > and
> > > provided patches for the two disentangled themes in
> > > https://issues.apache.org/jira/browse/OFBIZ-6362
> >
> >
> > This, I believe, is a complication.  There is nothing complicated about
> the
> > recommendation to fork header.ftl and appbar.ftl.  In fact I would like
> to
> > see this kind of practice promoted in Ofbiz as it allows designers more
> > options.
> >
> > Regards
> >
> > Gavin
> >
> >
> >
> > On Wed, Jun 24, 2015 at 3:09 PM, Pierre Smits 
> > wrote:
> >
> > > Bootstrap Sunrise is, in effect, a beautification effort on top of
> > > Bootstrap Basic. Where the Bootstrap dev branch started out as a kind
> of
> > > Proof of Concept branch (proving that OFBiz could be leveraged to use
> the
> > > Bootstrap web framework, and investigating/implementing what was
> required
> > > to have).
> > >
> > > With the effort spent on the additional skin (started as bootstrapped
> > > Tomahawk variant, now dubbed Sunrise), we went beyond that initial
> goal.
> > > Yet introducing another set of difficulties, being the effect of
> changes
> > in
> > > the ftl files for the one on the other.
> > >
> > > That is why I created https://issues.apache.org/jira/browse/OFBIZ-6467
> ,
> > > and
> > > provided patches for the two disentangled themes in
> > > https://issues.apache.org/jira/browse/OFBIZ-6362
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM *
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Wed, Jun 24, 2015 at 2:42 PM, Gavin Mabie 
> > wrote:
> > >
> > > > >
> > > > > I did not review anything but from your explanation having
> > > > > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes
> > > sense
> > > > > to me (since it's a "skin")
> > > > > BTW I understand that <> because it's mostly a

Re: git commit workflow for ofbiz

2015-06-24 Thread Taher Alkhateeb

Hi Jacques, 

Very good read, thank you for sharing. 

The person who wrote complaining about gitflow (I think Adam Ruka) makes a good 
point. He prefers linear to branched history. I do not mind branched history 
myself as I know how to navigate it but to each his own. Either way, The 
workflow can be accomplished the way he suggested by rebasing rather than 
merging the history and making a few other changes like dropping "develop". It 
is up to community to decide, and git is flexible enough to accommodate any 
model. 

Taher Alkhateeb 

- Original Message -

From: "Jacques Le Roux"  
To: dev@ofbiz.apache.org 
Sent: Wednesday, 24 June, 2015 4:19:42 PM 
Subject: Re: git commit workflow for ofbiz 

Le 24/06/2015 14:06, Jacques Le Roux a écrit : 
> If you get a chance to read these articles I highly recommend them 
> 
> http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/
>  

Of course don't miss 
http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/
 

Jacques 

> 
> http://endoflineblog.com/gitflow-considered-harmful 
> http://endoflineblog.com/follow-up-to-gitflow-considered-harmful 
> 
> Jacques 
> 
> 
> Le 12/05/2015 19:28, Adam Heath a écrit : 
>> Nice. This is quite thorough. There is an option missing. SVN committers who 
>> use git offline. In this case, their changes can be published as 
>> primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and as an 
>> SVN branch, for an example. 
>> 
>> I've read through most of what follows, and am in agreement, but I'm dealing 
>> with hardware problems, so I need to let it sink in first. 
>> 
>> On 05/12/2015 04:43 AM, Taher Alkhateeb wrote: 
>>> Hi everyone, 
>>> 
>>> This email refers to the thread for voting to move to git (link at bottom) 
>>> in which the vote decision was to delay and elaborate on the workflow 
>>> first. I am not well versed in ASF guidelines and appreciate any help and 
>>> feedback and also please note some of the below is my opinion and not 
>>> necessarily 100% factual. 
>>> 
>>> ## First, identified problems 
>>> 
>>> 1. patches can quickly be outdated if not applied quickly 
>>> 2. big patches are hard to audit and not desired nor preferred and It is 
>>> hard to break big patches to smaller ones because if any of those patches 
>>> is outdated or modified then everything needs to be re-patched 
>>> 3. to collaborate with other people (non-committers) freely on big 
>>> features, we need a separate branch. On svn this is lengthy and heavily 
>>> controlled. If we create a git repository then we need to constantly update 
>>> from svn and merge . Another solution is to clone the ofbiz read-only 
>>> git repository but then there are some patch issues to convert them to 
>>> clean svn patches (I faced a few including things like white space) 
>>> 4. a lot of _local_ offline freedom to branch, merge, commit, share and 
>>> experiment cannot be easily done without initiating a local git repository 
>>> which triggers the other problems identified above. 
>>> 6. There are too many public branches in the repositoy. Some are not active 
>>> nor complete and quite old 
>>> 
>>> ## Second, how does git provide solutions 
>>> 
>>> So, adopting git in relation to the above mentioned problems solves them as 
>>> follows: 
>>> 
>>> 1. even if a patch gets outdated, I can easily recreate it by switching to 
>>> a branch that I created and has the work (e.g. OFBIZ-12345), merging 
>>> everything from trunk and re-patching 
>>> 2. to allow for proper feedback by community, a pull request can replace a 
>>> big patch and that request can hold an X amount of commits each with 
>>> its own message and diff details. If changes happen to any of the commits, 
>>> then reconciling that into the code base is minor, you just branch 
>>> again, do it, and merge. Furthermore, I suggest to follow the guidelines 
>>> which recommend rebasing before pushing to a shared repository to keep a 
>>> nice linear history as much as possible as shown here -> 
>>> https://git-wip-us.apache.org/docs/committer-practices.html 
>>> 3. large features can be done in a remote repository in github or bitbucket 
>>> with pull requests when complete and ready for review. 
>>> 4. the issue is immediately solved with git which is not only local but 
>>> much, much faster 
>>> 6. We do not need to pollute the main repository with branches if we decide 
>>> on a distributed model like git with remote repositories to contribute 
>>> to the project with pull requests. 
>>> 
>>> ## Third, proposed workflow 
>>> 
>>> I will make a distinction between small features / bug fixes and large 
>>> features. 
>>> 
>>> ### small features 
>>> 
>>> Small features follow the exact same workflow that currently exists in svn. 
>>> You do your work, diff it, and attach the patch to a JIRA and request 
>>> a commit from one of the committers. 
>>> 
>>> ### large features 
>>> 
>>> For large features usually mu

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

2015-06-24 Thread Pierre Smits

Gavin,

Please don't see my posting as an attack on anyone participating in the
branch. It is just a reflection of my observation infused with a viewpoint.
I appreciate what has been done.

And, how to do skin variants has popped up before in relation to ecommerce.
See various mail threads in devML. So, the effort applied and the result
achieved validate the added goal of the Bootstrap PoC.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Jun 24, 2015 at 3:54 PM, Gavin Mabie  wrote:

> Hi Pierre
>
>
> > Bootstrap Sunrise is, in effect, a beautification effort on top of
> > Bootstrap Basic. Where the Bootstrap dev branch started out as a kind of
> > Proof of Concept branch (proving that OFBiz could be leveraged to use the
> > Bootstrap web framework, and investigating/implementing what was required
> > to have).
>
>
> When I initially included the "Bootstrap Tomahawk" theme,  the purpose was
> solely to indicate how easy it would be to develop skins for a theme.
> Naturally some might think that it is a "beautification", but that is a
> matter of opinion.  In the real world you may find clients who do not agree
> with this notion.  It's for this reason that most designers first present a
> vanilla look-and-feel so that clients can bring their preferences into the
> mix.  As a community our goal should be to present Ofbiz as visually
> appealing as possible without being too prescriptive in terms of
> look-and-feel.  Most projects do this by using generic (if not bland)
> look-and-feel's for their apps.  Hence "Basic".  BTW Bootstrap is not a web
> framework!
>
> With the effort spent on the additional skin (started as bootstrapped
> > Tomahawk variant, now dubbed Sunrise), we went beyond that initial goal.
> >
> >
> Going beyond the initial goal is perhaps at the crux of it.  I personally
> think it is too early to do this.  There are other, higher priority issues
> that need addressing before we get sexy on this. For one, we haven't dealt
> with responsiveness sufficiently.  While we have demonstrated that the
> Ofbiz framework is flexible enough to handle Bootstrap and perhaps any
> other JavaScript framework, we have yet to address HTML 5 issues.
>
> Yet introducing another set of difficulties, being the effect of changes in
> > the ftl files for the one on the other.
>
>
> I don't agree with the idea that these are difficulties.  It is a simple
> solution to the problem arising from treating "Sunrise" as a theme.  Also,
> it acknowledges the work done by Julien in line with the "People before
> Code" mantra.
>
> That is why I created https://issues.apache.org/jira/browse/OFBIZ-6467,
> and
> > provided patches for the two disentangled themes in
> > https://issues.apache.org/jira/browse/OFBIZ-6362
>
>
> This, I believe, is a complication.  There is nothing complicated about the
> recommendation to fork header.ftl and appbar.ftl.  In fact I would like to
> see this kind of practice promoted in Ofbiz as it allows designers more
> options.
>
> Regards
>
> Gavin
>
>
>
> On Wed, Jun 24, 2015 at 3:09 PM, Pierre Smits 
> wrote:
>
> > Bootstrap Sunrise is, in effect, a beautification effort on top of
> > Bootstrap Basic. Where the Bootstrap dev branch started out as a kind of
> > Proof of Concept branch (proving that OFBiz could be leveraged to use the
> > Bootstrap web framework, and investigating/implementing what was required
> > to have).
> >
> > With the effort spent on the additional skin (started as bootstrapped
> > Tomahawk variant, now dubbed Sunrise), we went beyond that initial goal.
> > Yet introducing another set of difficulties, being the effect of changes
> in
> > the ftl files for the one on the other.
> >
> > That is why I created https://issues.apache.org/jira/browse/OFBIZ-6467,
> > and
> > provided patches for the two disentangled themes in
> > https://issues.apache.org/jira/browse/OFBIZ-6362
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Wed, Jun 24, 2015 at 2:42 PM, Gavin Mabie 
> wrote:
> >
> > > >
> > > > I did not review anything but from your explanation having
> > > > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes
> > sense
> > > > to me (since it's a "skin")
> > > > BTW I understand that <> because it's mostly a
> > copy
> > > > of basic, right?
> > >
> > >
> > > That's right.  If Julien is okay with it, I can move his commits to new
> > > folder "sunrise" under bootstrap/includes.  The "sunrise" folder can
> > serve
> > > as placeholder for templates that deviate from the "basic" templates.
> > >
> > > I agree with Pierre that we should try to get this into the trunk
> sooner
> > > rather then later because of the massive refactoring work.  New

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

Hi Pierre


> Bootstrap Sunrise is, in effect, a beautification effort on top of
> Bootstrap Basic. Where the Bootstrap dev branch started out as a kind of
> Proof of Concept branch (proving that OFBiz could be leveraged to use the
> Bootstrap web framework, and investigating/implementing what was required
> to have).


When I initially included the "Bootstrap Tomahawk" theme,  the purpose was
solely to indicate how easy it would be to develop skins for a theme.
Naturally some might think that it is a "beautification", but that is a
matter of opinion.  In the real world you may find clients who do not agree
with this notion.  It's for this reason that most designers first present a
vanilla look-and-feel so that clients can bring their preferences into the
mix.  As a community our goal should be to present Ofbiz as visually
appealing as possible without being too prescriptive in terms of
look-and-feel.  Most projects do this by using generic (if not bland)
look-and-feel's for their apps.  Hence "Basic".  BTW Bootstrap is not a web
framework!

With the effort spent on the additional skin (started as bootstrapped
> Tomahawk variant, now dubbed Sunrise), we went beyond that initial goal.
>
>
Going beyond the initial goal is perhaps at the crux of it.  I personally
think it is too early to do this.  There are other, higher priority issues
that need addressing before we get sexy on this. For one, we haven't dealt
with responsiveness sufficiently.  While we have demonstrated that the
Ofbiz framework is flexible enough to handle Bootstrap and perhaps any
other JavaScript framework, we have yet to address HTML 5 issues.

Yet introducing another set of difficulties, being the effect of changes in
> the ftl files for the one on the other.


I don't agree with the idea that these are difficulties.  It is a simple
solution to the problem arising from treating "Sunrise" as a theme.  Also,
it acknowledges the work done by Julien in line with the "People before
Code" mantra.

That is why I created https://issues.apache.org/jira/browse/OFBIZ-6467, and
> provided patches for the two disentangled themes in
> https://issues.apache.org/jira/browse/OFBIZ-6362


This, I believe, is a complication.  There is nothing complicated about the
recommendation to fork header.ftl and appbar.ftl.  In fact I would like to
see this kind of practice promoted in Ofbiz as it allows designers more
options.

Regards

Gavin



On Wed, Jun 24, 2015 at 3:09 PM, Pierre Smits 
wrote:

> Bootstrap Sunrise is, in effect, a beautification effort on top of
> Bootstrap Basic. Where the Bootstrap dev branch started out as a kind of
> Proof of Concept branch (proving that OFBiz could be leveraged to use the
> Bootstrap web framework, and investigating/implementing what was required
> to have).
>
> With the effort spent on the additional skin (started as bootstrapped
> Tomahawk variant, now dubbed Sunrise), we went beyond that initial goal.
> Yet introducing another set of difficulties, being the effect of changes in
> the ftl files for the one on the other.
>
> That is why I created https://issues.apache.org/jira/browse/OFBIZ-6467,
> and
> provided patches for the two disentangled themes in
> https://issues.apache.org/jira/browse/OFBIZ-6362
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Jun 24, 2015 at 2:42 PM, Gavin Mabie  wrote:
>
> > >
> > > I did not review anything but from your explanation having
> > > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes
> sense
> > > to me (since it's a "skin")
> > > BTW I understand that <> because it's mostly a
> copy
> > > of basic, right?
> >
> >
> > That's right.  If Julien is okay with it, I can move his commits to new
> > folder "sunrise" under bootstrap/includes.  The "sunrise" folder can
> serve
> > as placeholder for templates that deviate from the "basic" templates.
> >
> > I agree with Pierre that we should try to get this into the trunk sooner
> > rather then later because of the massive refactoring work.  New issues
> will
> > definitely emerge once in the trunk, but we can deal with that there.
> >
> > Gavin
> >
> > On Wed, Jun 24, 2015 at 12:58 PM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> > > Le 24/06/2015 11:47, Gavin Mabie a écrit :
> > >
> > >> Four issues:
> > >>
> > >>
> > >> 1. The Bootstrap Basic and "Bootstrap Sunrise" is in fact just one
> > >> theme
> > >> with Basic as theme and Sunrise as a "skin" (implementation of
> > Basic).
> > >> Hence the location of the css for Sunrise under
> bootstrap/css/skins.
> > >> Other
> > >> than that, Sunrise uses the same template libraries as Basic. It
> is
> > a
> > >> false
> > >> choice.
> > >> 2.  If we want to elevate Sunrise to theme status (i.e not just a
> > >> skin),
> > >> then we have to create separate template libr

Re: git commit workflow for ofbiz

2015-06-24 Thread Jacques Le Roux

Le 24/06/2015 14:06, Jacques Le Roux a écrit :

If you get a chance to read these articles I highly recommend them

http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/

Of course don't miss
http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/

Jacques

http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful

Jacques

Le 12/05/2015 19:28, Adam Heath a écrit :
Nice. This is quite thorough. There is an option missing. SVN committers who use git offline. In this case, their changes can be published as
primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and as an SVN branch, for an example.

I've read through most of what follows, and am in agreement, but I'm dealing
with hardware problems, so I need to let it sink in first.

On 05/12/2015 04:43 AM, Taher Alkhateeb wrote:

Hi everyone,

This email refers to the thread for voting to move to git (link at bottom) in which the vote decision was to delay and elaborate on the workflow
first. I am not well versed in ASF guidelines and appreciate any help and feedback and also please note some of the below is my opinion and not
necessarily 100% factual.

## First, identified problems

1. patches can quickly be outdated if not applied quickly
2. big patches are hard to audit and not desired nor preferred and It is hard to break big patches to smaller ones because if any of those patches
is outdated or modified then everything needs to be re-patched
3. to collaborate with other people (non-committers) freely on big features, we need a separate branch. On svn this is lengthy and heavily
controlled. If we create a git repository then we need to constantly update from svn and merge . Another solution is to clone the ofbiz read-only
git repository but then there are some patch issues to convert them to clean svn patches (I faced a few including things like white space)
4. a lot of _local_ offline freedom to branch, merge, commit, share and experiment cannot be easily done without initiating a local git repository
which triggers the other problems identified above.

6. There are too many public branches in the repositoy. Some are not active nor
complete and quite old

## Second, how does git provide solutions

So, adopting git in relation to the above mentioned problems solves them as
follows:

1. even if a patch gets outdated, I can easily recreate it by switching to a branch that I created and has the work (e.g. OFBIZ-12345), merging
everything from trunk and re-patching
2. to allow for proper feedback by community, a pull request can replace a big patch and that request can hold an X amount of commits each with
its own message and diff details. If changes happen to any of the commits, then reconciling that into the code base is minor, you just branch
again, do it, and merge. Furthermore, I suggest to follow the guidelines which recommend rebasing before pushing to a shared repository to keep a
nice linear history as much as possible as shown here -> https://git-wip-us.apache.org/docs/committer-practices.html

3. large features can be done in a remote repository in github or bitbucket
with pull requests when complete and ready for review.
4. the issue is immediately solved with git which is not only local but much,
much faster
6. We do not need to pollute the main repository with branches if we decide on a distributed model like git with remote repositories to contribute
to the project with pull requests.

## Third, proposed workflow

I will make a distinction between small features / bug fixes and large features.

### small features

Small features follow the exact same workflow that currently exists in svn. You do your work, diff it, and attach the patch to a JIRA and request
a commit from one of the committers.

### large features

For large features usually multiple people need to collaborate on a separate
branch. Here is where git shines and the distributed model kicks in:
1. A JIRA is created for a large feature
2. The team (not necessarily having a committer) creates a remote repository which itself may have many branches with the master branch having all
the work agreed upon and merged (actually, rebased)

3. The collaboration for this branch happens in the JIRA including discussions,
comments, and even links to the commits etc ...
4. A request is made to a committer to make a pull request from the repository after reaching a certain milestone with consensus from the
community of course
5. Here, for extra safety, the branch model may have a trunk and a develop branches. Everything is pulled to the develop branch and trickles down
to the master branch after thorough and proper testing.

The above workflow can also adhere to the now famous Vincent Driessen git branching model found here ->
http://nvie.com/posts/a-successful-git-branching-model/

I am not sure whether this proposal is enough

[jira] [Comment Edited] (OFBIZ-6528) Add a mean to untie geo associations


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

Gil Portenseigne edited comment on OFBIZ-6528 at 6/24/15 1:19 PM:
--

Thank you ! I like simplicity ;) 

Reading the commit mail, could you just rename the {code}+
Delete a Geo{code} to {code}+
Delete a GeoAssoc{code}
Sorry for this detail


was (Author: gil portenseigne):
Thank you ! I like simplicity ;) 

Reading the commit mail, could you just rename the {code}+
Delete a Geo{code} to {code}+
Delete a GeoAssoc{code}

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch, OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Commented] (OFBIZ-6528) Add a mean to untie geo associations


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

Gil Portenseigne commented on OFBIZ-6528:
-

Thank you ! I like simplicity ;) 

Reading the commit mail, could you just rename the {code}+
Delete a Geo{code} to {code}+
Delete a GeoAssoc{code}

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch, OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Closed] (OFBIZ-6528) Add a mean to untie geo associations


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

Jacques Le Roux closed OFBIZ-6528.
--
Resolution: Implemented

Thanks Guy,

Gil your patch is commited at revision: 1687259, well thought!

I also particularly like <> :)




> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch, OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Comment Edited] (OFBIZ-6528) Add a mean to untie geo associations


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

Jacques Le Roux edited comment on OFBIZ-6528 at 6/24/15 1:11 PM:
-

Thanks guys,

Gil your patch is commited at revision: 1687259, well thought!

I also particularly like <> :)





was (Author: jacques.le.roux):
Thanks Guy,

Gil your patch is commited at revision: 1687259, well thought!

I also particularly like <> :)




> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch, OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

>
> If we, as a community, are opting for multiple themes in one component,
> that would sure fit the bill. But is that what we want? Add complexities
> and bulk to a somewhat global theme management component?



> Or should we just have a strategy of one theme - one component? I am in
> favour of the latter option, even if it means some kind of duplication of
> functionality.


I am for one basic theme.  Most projects maintain one basic theme and leave
further customization and development up to the design community.  I see
our task as developing and maintaining a solid basic theme.  Maybe that can
spawn a templating community of its own.

Gavin

On Wed, Jun 24, 2015 at 2:58 PM, Pierre Smits 
wrote:

> If we, as a community, are opting for multiple themes in one component,
> that would sure fit the bill. But is that what we want? Add complexities
> and bulk to a somewhat global theme management component?
>
> Or should we just have a strategy of one theme - one component? I am in
> favour of the latter option, even if it means some kind of duplication of
> functionality.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Jun 24, 2015 at 2:42 PM, Gavin Mabie  wrote:
>
> > >
> > > I did not review anything but from your explanation having
> > > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes
> sense
> > > to me (since it's a "skin")
> > > BTW I understand that <> because it's mostly a
> copy
> > > of basic, right?
> >
> >
> > That's right.  If Julien is okay with it, I can move his commits to new
> > folder "sunrise" under bootstrap/includes.  The "sunrise" folder can
> serve
> > as placeholder for templates that deviate from the "basic" templates.
> >
> > I agree with Pierre that we should try to get this into the trunk sooner
> > rather then later because of the massive refactoring work.  New issues
> will
> > definitely emerge once in the trunk, but we can deal with that there.
> >
> > Gavin
> >
> > On Wed, Jun 24, 2015 at 12:58 PM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> > > Le 24/06/2015 11:47, Gavin Mabie a écrit :
> > >
> > >> Four issues:
> > >>
> > >>
> > >> 1. The Bootstrap Basic and "Bootstrap Sunrise" is in fact just one
> > >> theme
> > >> with Basic as theme and Sunrise as a "skin" (implementation of
> > Basic).
> > >> Hence the location of the css for Sunrise under
> bootstrap/css/skins.
> > >> Other
> > >> than that, Sunrise uses the same template libraries as Basic. It
> is
> > a
> > >> false
> > >> choice.
> > >> 2.  If we want to elevate Sunrise to theme status (i.e not just a
> > >> skin),
> > >> then we have to create separate template libraries for it. To
> > qualify
> > >> as a
> > >> theme, it should have its own distinct widget implementation
> > including
> > >> headers, menus, forms, tables, pagination etc.
> > >> 3. The commits by Julien - r1683430 (header.ftl & appbar.ftl)
> > affects
> > >> both Basic and Sunrise. I have not seen patches for these and
> could
> > >> therefore not do reviews.
> > >> 4. The approach with the Basic theme is to keep it as basic as
> > >> possible,
> > >> minimizing personal preferences with regards to look-and-feel and
> > >> leaving
> > >> this level of styling up to individual designers.
> > >>
> > >> I have committed patches to deal with most if not all the issues
> flagged
> > >> by
> > >> Adrian on 19 May 2015.  New issues have cropped up as a result of
> > >> r1683430.  To get this merge-ready my recommendation is that we revert
> > >> r1683430 which deals with header.ftl & appbar.ft.  These are minor
> > issues
> > >> which relate mainly to personal preferences. If the changes introduced
> > >> with
> > >> r1683430 is absolutely necessary, then I recommend that separate
> > >> header.ftl
> > >> & appbar.ftl files are created and that themeResources in "Sunrise"
> > point
> > >> to locations where the new files reside.
> > >>
> > >
> > > I did not review anything but from your explanation having
> > > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes
> sense
> > > to me (since it's a "skin")
> > > BTW I understand that <> because it's mostly a
> copy
> > > of basic, right?
> > >
> > > Jacques
> > >
> > >
> > >
> > >> Regards
> > >>
> > >> Gavin
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Jun 24, 2015 at 12:21 AM, Pierre Smits <
> pierre.sm...@gmail.com>
> > >> wrote:
> > >>
> > >>  I am running the Bootstrap Basic (somewhat modified) against trunk.
> > >>>
> > >>> Best regards,
> > >>>
> > >>> Pierre Smits
> > >>>
> > >>> *ORRTIZ.COM *
> > >>> Services & Solutions for Cloud-
> > >>> Based Manufacturing, Professional
> > >>> Services and Retail & Trade
> > >>> http://www.orrtiz.com
> > >>>
> > >>> On Tue, Jun 23, 2015 at 9:56 PM, Adria

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

2015-06-24 Thread Pierre Smits

Bootstrap Sunrise is, in effect, a beautification effort on top of
Bootstrap Basic. Where the Bootstrap dev branch started out as a kind of
Proof of Concept branch (proving that OFBiz could be leveraged to use the
Bootstrap web framework, and investigating/implementing what was required
to have).

With the effort spent on the additional skin (started as bootstrapped
Tomahawk variant, now dubbed Sunrise), we went beyond that initial goal.
Yet introducing another set of difficulties, being the effect of changes in
the ftl files for the one on the other.

That is why I created https://issues.apache.org/jira/browse/OFBIZ-6467, and
provided patches for the two disentangled themes in
https://issues.apache.org/jira/browse/OFBIZ-6362

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Jun 24, 2015 at 2:42 PM, Gavin Mabie  wrote:

> >
> > I did not review anything but from your explanation having
> > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes sense
> > to me (since it's a "skin")
> > BTW I understand that <> because it's mostly a copy
> > of basic, right?
>
>
> That's right.  If Julien is okay with it, I can move his commits to new
> folder "sunrise" under bootstrap/includes.  The "sunrise" folder can serve
> as placeholder for templates that deviate from the "basic" templates.
>
> I agree with Pierre that we should try to get this into the trunk sooner
> rather then later because of the massive refactoring work.  New issues will
> definitely emerge once in the trunk, but we can deal with that there.
>
> Gavin
>
> On Wed, Jun 24, 2015 at 12:58 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Le 24/06/2015 11:47, Gavin Mabie a écrit :
> >
> >> Four issues:
> >>
> >>
> >> 1. The Bootstrap Basic and "Bootstrap Sunrise" is in fact just one
> >> theme
> >> with Basic as theme and Sunrise as a "skin" (implementation of
> Basic).
> >> Hence the location of the css for Sunrise under bootstrap/css/skins.
> >> Other
> >> than that, Sunrise uses the same template libraries as Basic. It is
> a
> >> false
> >> choice.
> >> 2.  If we want to elevate Sunrise to theme status (i.e not just a
> >> skin),
> >> then we have to create separate template libraries for it. To
> qualify
> >> as a
> >> theme, it should have its own distinct widget implementation
> including
> >> headers, menus, forms, tables, pagination etc.
> >> 3. The commits by Julien - r1683430 (header.ftl & appbar.ftl)
> affects
> >> both Basic and Sunrise. I have not seen patches for these and could
> >> therefore not do reviews.
> >> 4. The approach with the Basic theme is to keep it as basic as
> >> possible,
> >> minimizing personal preferences with regards to look-and-feel and
> >> leaving
> >> this level of styling up to individual designers.
> >>
> >> I have committed patches to deal with most if not all the issues flagged
> >> by
> >> Adrian on 19 May 2015.  New issues have cropped up as a result of
> >> r1683430.  To get this merge-ready my recommendation is that we revert
> >> r1683430 which deals with header.ftl & appbar.ft.  These are minor
> issues
> >> which relate mainly to personal preferences. If the changes introduced
> >> with
> >> r1683430 is absolutely necessary, then I recommend that separate
> >> header.ftl
> >> & appbar.ftl files are created and that themeResources in "Sunrise"
> point
> >> to locations where the new files reside.
> >>
> >
> > I did not review anything but from your explanation having
> > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes sense
> > to me (since it's a "skin")
> > BTW I understand that <> because it's mostly a copy
> > of basic, right?
> >
> > Jacques
> >
> >
> >
> >> Regards
> >>
> >> Gavin
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Jun 24, 2015 at 12:21 AM, Pierre Smits 
> >> wrote:
> >>
> >>  I am running the Bootstrap Basic (somewhat modified) against trunk.
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *ORRTIZ.COM *
> >>> Services & Solutions for Cloud-
> >>> Based Manufacturing, Professional
> >>> Services and Retail & Trade
> >>> http://www.orrtiz.com
> >>>
> >>> On Tue, Jun 23, 2015 at 9:56 PM, Adrian Crum <
> >>> adrian.c...@sandglass-software.com> wrote:
> >>>
> >>>  I evaluated the bootstrap branch as it currently exists. If there are
>  patches waiting to be applied to the branch, then I am not aware of
>  them.
> 
>  Adrian Crum
>  Sandglass Software
>  www.sandglass-software.com
> 
>  On 6/23/2015 12:43 PM, Pierre Smits wrote:
> 
>   Hi Adrian,
> >
> > Thanks for the feedback. That the existing patch files available in
> > JIRA
> > issues don't work in trunk has to do with the fact that the bootstrap
> >
>  dev
> >>>
>  branch is not in sync w

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

2015-06-24 Thread Pierre Smits

If we, as a community, are opting for multiple themes in one component,
that would sure fit the bill. But is that what we want? Add complexities
and bulk to a somewhat global theme management component?

Or should we just have a strategy of one theme - one component? I am in
favour of the latter option, even if it means some kind of duplication of
functionality.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Jun 24, 2015 at 2:42 PM, Gavin Mabie  wrote:

> >
> > I did not review anything but from your explanation having
> > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes sense
> > to me (since it's a "skin")
> > BTW I understand that <> because it's mostly a copy
> > of basic, right?
>
>
> That's right.  If Julien is okay with it, I can move his commits to new
> folder "sunrise" under bootstrap/includes.  The "sunrise" folder can serve
> as placeholder for templates that deviate from the "basic" templates.
>
> I agree with Pierre that we should try to get this into the trunk sooner
> rather then later because of the massive refactoring work.  New issues will
> definitely emerge once in the trunk, but we can deal with that there.
>
> Gavin
>
> On Wed, Jun 24, 2015 at 12:58 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Le 24/06/2015 11:47, Gavin Mabie a écrit :
> >
> >> Four issues:
> >>
> >>
> >> 1. The Bootstrap Basic and "Bootstrap Sunrise" is in fact just one
> >> theme
> >> with Basic as theme and Sunrise as a "skin" (implementation of
> Basic).
> >> Hence the location of the css for Sunrise under bootstrap/css/skins.
> >> Other
> >> than that, Sunrise uses the same template libraries as Basic. It is
> a
> >> false
> >> choice.
> >> 2.  If we want to elevate Sunrise to theme status (i.e not just a
> >> skin),
> >> then we have to create separate template libraries for it. To
> qualify
> >> as a
> >> theme, it should have its own distinct widget implementation
> including
> >> headers, menus, forms, tables, pagination etc.
> >> 3. The commits by Julien - r1683430 (header.ftl & appbar.ftl)
> affects
> >> both Basic and Sunrise. I have not seen patches for these and could
> >> therefore not do reviews.
> >> 4. The approach with the Basic theme is to keep it as basic as
> >> possible,
> >> minimizing personal preferences with regards to look-and-feel and
> >> leaving
> >> this level of styling up to individual designers.
> >>
> >> I have committed patches to deal with most if not all the issues flagged
> >> by
> >> Adrian on 19 May 2015.  New issues have cropped up as a result of
> >> r1683430.  To get this merge-ready my recommendation is that we revert
> >> r1683430 which deals with header.ftl & appbar.ft.  These are minor
> issues
> >> which relate mainly to personal preferences. If the changes introduced
> >> with
> >> r1683430 is absolutely necessary, then I recommend that separate
> >> header.ftl
> >> & appbar.ftl files are created and that themeResources in "Sunrise"
> point
> >> to locations where the new files reside.
> >>
> >
> > I did not review anything but from your explanation having
> > separated/specific header.ftl & appbar.ftl files in "Sunrise" makes sense
> > to me (since it's a "skin")
> > BTW I understand that <> because it's mostly a copy
> > of basic, right?
> >
> > Jacques
> >
> >
> >
> >> Regards
> >>
> >> Gavin
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Jun 24, 2015 at 12:21 AM, Pierre Smits 
> >> wrote:
> >>
> >>  I am running the Bootstrap Basic (somewhat modified) against trunk.
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *ORRTIZ.COM *
> >>> Services & Solutions for Cloud-
> >>> Based Manufacturing, Professional
> >>> Services and Retail & Trade
> >>> http://www.orrtiz.com
> >>>
> >>> On Tue, Jun 23, 2015 at 9:56 PM, Adrian Crum <
> >>> adrian.c...@sandglass-software.com> wrote:
> >>>
> >>>  I evaluated the bootstrap branch as it currently exists. If there are
>  patches waiting to be applied to the branch, then I am not aware of
>  them.
> 
>  Adrian Crum
>  Sandglass Software
>  www.sandglass-software.com
> 
>  On 6/23/2015 12:43 PM, Pierre Smits wrote:
> 
>   Hi Adrian,
> >
> > Thanks for the feedback. That the existing patch files available in
> > JIRA
> > issues don't work in trunk has to do with the fact that the bootstrap
> >
>  dev
> >>>
>  branch is not in sync with trunk. We have to take in consideration
> that
> > the
> > framework stack of the bootstrap branch is based (for the greater
> part)
> >
>  on
> >>>
>  r1634810.
> >
> > On top of that, the Bootstrap Basic and the other one were
> > co-developed.
> > And shortly before the disentanglement of the two themes changes in
> the
>

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

>
> I did not review anything but from your explanation having
> separated/specific header.ftl & appbar.ftl files in "Sunrise" makes sense
> to me (since it's a "skin")
> BTW I understand that <> because it's mostly a copy
> of basic, right?


That's right.  If Julien is okay with it, I can move his commits to new
folder "sunrise" under bootstrap/includes.  The "sunrise" folder can serve
as placeholder for templates that deviate from the "basic" templates.

I agree with Pierre that we should try to get this into the trunk sooner
rather then later because of the massive refactoring work.  New issues will
definitely emerge once in the trunk, but we can deal with that there.

Gavin

On Wed, Jun 24, 2015 at 12:58 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 24/06/2015 11:47, Gavin Mabie a écrit :
>
>> Four issues:
>>
>>
>> 1. The Bootstrap Basic and "Bootstrap Sunrise" is in fact just one
>> theme
>> with Basic as theme and Sunrise as a "skin" (implementation of Basic).
>> Hence the location of the css for Sunrise under bootstrap/css/skins.
>> Other
>> than that, Sunrise uses the same template libraries as Basic. It is a
>> false
>> choice.
>> 2.  If we want to elevate Sunrise to theme status (i.e not just a
>> skin),
>> then we have to create separate template libraries for it. To qualify
>> as a
>> theme, it should have its own distinct widget implementation including
>> headers, menus, forms, tables, pagination etc.
>> 3. The commits by Julien - r1683430 (header.ftl & appbar.ftl) affects
>> both Basic and Sunrise. I have not seen patches for these and could
>> therefore not do reviews.
>> 4. The approach with the Basic theme is to keep it as basic as
>> possible,
>> minimizing personal preferences with regards to look-and-feel and
>> leaving
>> this level of styling up to individual designers.
>>
>> I have committed patches to deal with most if not all the issues flagged
>> by
>> Adrian on 19 May 2015.  New issues have cropped up as a result of
>> r1683430.  To get this merge-ready my recommendation is that we revert
>> r1683430 which deals with header.ftl & appbar.ft.  These are minor issues
>> which relate mainly to personal preferences. If the changes introduced
>> with
>> r1683430 is absolutely necessary, then I recommend that separate
>> header.ftl
>> & appbar.ftl files are created and that themeResources in "Sunrise" point
>> to locations where the new files reside.
>>
>
> I did not review anything but from your explanation having
> separated/specific header.ftl & appbar.ftl files in "Sunrise" makes sense
> to me (since it's a "skin")
> BTW I understand that <> because it's mostly a copy
> of basic, right?
>
> Jacques
>
>
>
>> Regards
>>
>> Gavin
>>
>>
>>
>>
>>
>> On Wed, Jun 24, 2015 at 12:21 AM, Pierre Smits 
>> wrote:
>>
>>  I am running the Bootstrap Basic (somewhat modified) against trunk.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Tue, Jun 23, 2015 at 9:56 PM, Adrian Crum <
>>> adrian.c...@sandglass-software.com> wrote:
>>>
>>>  I evaluated the bootstrap branch as it currently exists. If there are
 patches waiting to be applied to the branch, then I am not aware of
 them.

 Adrian Crum
 Sandglass Software
 www.sandglass-software.com

 On 6/23/2015 12:43 PM, Pierre Smits wrote:

  Hi Adrian,
>
> Thanks for the feedback. That the existing patch files available in
> JIRA
> issues don't work in trunk has to do with the fact that the bootstrap
>
 dev
>>>
 branch is not in sync with trunk. We have to take in consideration that
> the
> framework stack of the bootstrap branch is based (for the greater part)
>
 on
>>>
 r1634810.
>
> On top of that, the Bootstrap Basic and the other one were
> co-developed.
> And shortly before the disentanglement of the two themes changes in the
> templates were implemented for the other theme that affected the
>
 Bootstrap
>>>
 Basic theme negatively.
>
> Nonetheless, I am ok with whatever which way the community chooses to
> go
> with these bootstrap themes and the ones in trunk. It remains a
> personal
> preference what one likes best.
>
> Best regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Jun 23, 2015 at 5:20 PM, Adrian Crum <
> adrian.c...@sandglass-software.com> wrote:
>
>   I don't think the new themes are ready. I updated my local copy
>
 yesterday
>>>
 and tried them out - many of the layout issues I reported still exist,
>

a quote pse

2015-06-24 Thread Heidi Dehaes

Hello,

Who can give me a quote for implementing a working VISA or Bank
payment method in the ecommerce package of ofbiz 11.04 ?

Regards,
Eric


Olagos bvba
Heidi Dehaes
Kerkstraat 34
2570 Duffel
Belgium
Tel. : 015/31 53 04
GSM :0485/22 35 80
E-mail : info.ola...@gmail.com
http://www.olagos.eu
http://www.olagos.com
http://www.olagos.be
http://www.olagos.nl

[jira] [Updated] (OFBIZ-6528) Add a mean to untie geo associations


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

Gil Portenseigne updated OFBIZ-6528:

Attachment: OFBIZ-6528.patch

Double wire crossed, here is the updated patch. :D

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch, OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

Re: git commit workflow for ofbiz

2015-06-24 Thread Jacques Le Roux

If you get a chance to read these articles I highly recommend them

http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/

http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful

Jacques

I've read through most of what follows, and am in agreement, but I'm dealing
with hardware problems, so I need to let it sink in first.

On 05/12/2015 04:43 AM, Taher Alkhateeb wrote:

Hi everyone,

## First, identified problems

6. There are too many public branches in the repositoy. Some are not active nor
complete and quite old

## Second, how does git provide solutions

So, adopting git in relation to the above mentioned problems solves them as
follows:

1. even if a patch gets outdated, I can easily recreate it by switching to a branch that I created and has the work (e.g. OFBIZ-12345), merging
everything from trunk and re-patching
2. to allow for proper feedback by community, a pull request can replace a big patch and that request can hold an X amount of commits each with its
own message and diff details. If changes happen to any of the commits, then reconciling that into the code base is minor, you just branch again, do
it, and merge. Furthermore, I suggest to follow the guidelines which recommend rebasing before pushing to a shared repository to keep a nice linear
history as much as possible as shown here -> https://git-wip-us.apache.org/docs/committer-practices.html

## Third, proposed workflow

I will make a distinction between small features / bug fixes and large features.

### small features

Small features follow the exact same workflow that currently exists in svn. You do your work, diff it, and attach the patch to a JIRA and request a
commit from one of the committers.

### large features

3. The collaboration for this branch happens in the JIRA including discussions,
comments, and even links to the commits etc ...
4. A request is made to a committer to make a pull request from the repository after reaching a certain milestone with consensus from the community
of course
5. Here, for extra safety, the branch model may have a trunk and a develop branches. Everything is pulled to the develop branch and trickles down
to the master branch after thorough and proper testing.

The above workflow can also adhere to the now famous Vincent Driessen git branching model found here ->
http://nvie.com/posts/a-successful-git-branching-model/

I am not sure whether this proposal is enough or correct so I appreciate your
guidance and feedback to fix whatever needs fixing.

Taher Alkhateeb

original voting thread:
http://ofbiz.markmail.org/search/?q=move%20t

[jira] [Commented] (OFBIZ-6528) Add a mean to untie geo associations


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

Gil Portenseigne commented on OFBIZ-6528:
-

Feel free, i can give another patch after your commit :)

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Commented] (OFBIZ-6528) Add a mean to untie geo associations


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

Jacques Le Roux commented on OFBIZ-6528:


OK cool, Gil, we crossed on wire, I will wait for your improvement

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Commented] (OFBIZ-6528) Add a mean to untie geo associations


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

Jacques Le Roux commented on OFBIZ-6528:


Thanks Pierre, I was ready to commit, but I think I will before improve it as 
suggested, if nobody beats me on it ;)

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Commented] (OFBIZ-6528) Add a mean to untie geo associations


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

Gil Portenseigne commented on OFBIZ-6528:
-

Indeed it's quite simple to do, i'll update my patch soon.

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Comment Edited] (OFBIZ-6528) Add a mean to untie geo associations

2015-06-24 Thread Pierre Smits (JIRA)


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

Pierre Smits edited comment on OFBIZ-6528 at 6/24/15 11:22 AM:
---

I have tested the patch. It works.

However, the grid showing the geos associated doesn't provide a clickable to 
open the associated geo. That could be another improvement.

Another plus would be to show the geoTypeId of the associated geo.


was (Author: pfm.smits):
I have tested the patch. It works.

However, the grid showing the geos associated doesn't provide a clickable to 
open the associated geo. That could be another improvement.

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Commented] (OFBIZ-6528) Add a mean to untie geo associations

2015-06-24 Thread Pierre Smits (JIRA)


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

Pierre Smits commented on OFBIZ-6528:
-

I have tested the patch. It works.

However, the grid showing the geos associated doesn't provide a clickable to 
open the associated geo. That could be another improvement.

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Commented] (OFBIZ-6495) The tag in view entity PartyExport does not work


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

Jacques Le Roux commented on OFBIZ-6495:


Yes thanks Zhang for the reminder, I hope this week :)

> The tag  in view entity PartyExport does not work
> 
>
> Key: OFBIZ-6495
> URL: https://issues.apache.org/jira/browse/OFBIZ-6495
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Trunk
>Reporter: Wei Zhang
>Assignee: Jacques Le Roux
> Attachments: patches-6495.zip
>
>
> The tag  in view entity PartyExport in 
> applications\party\entitydef\entitymodel.xml does not work.



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

[jira] [Commented] (OFBIZ-6529) Improve the Create/Edit Geo screen in WebTools/GeoManagement


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

Jacques Le Roux commented on OFBIZ-6529:


Or maybe not awaken rather

> Improve the Create/Edit Geo screen in WebTools/GeoManagement
> 
>
> Key: OFBIZ-6529
> URL: https://issues.apache.org/jira/browse/OFBIZ-6529
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>  Labels: creation, geo
> Fix For: Upcoming Branch
>
>
> After OFBIZ-6229, the Create/Edit Geo screen in WebTools/GeoManagement does 
> no longer make sense when accessed directly (ie not automatically from Find 
> Geos screen). So you can't no longer create a Geo from there. This need to be 
> clarified. 
> * Should we still provide a direct access for creation with a button menu, or
> * Should we only access it from Find Geosand no longer allow to create a Geo 
> (no button meny only update) ?



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

[jira] [Assigned] (OFBIZ-6528) Add a mean to untie geo associations


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

Jacques Le Roux reassigned OFBIZ-6528:
--

Assignee: Jacques Le Roux  (was: Gil Portenseigne)

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Closed] (OFBIZ-6529) Improve the Create/Edit Geo screen in WebTools/GeoManagement


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

Jacques Le Roux closed OFBIZ-6529.
--
Resolution: Not A Problem

Oops seems I was tired when I created that :D

> Improve the Create/Edit Geo screen in WebTools/GeoManagement
> 
>
> Key: OFBIZ-6529
> URL: https://issues.apache.org/jira/browse/OFBIZ-6529
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>  Labels: creation, geo
> Fix For: Upcoming Branch
>
>
> After OFBIZ-6229, the Create/Edit Geo screen in WebTools/GeoManagement does 
> no longer make sense when accessed directly (ie not automatically from Find 
> Geos screen). So you can't no longer create a Geo from there. This need to be 
> clarified. 
> * Should we still provide a direct access for creation with a button menu, or
> * Should we only access it from Find Geosand no longer allow to create a Geo 
> (no button meny only update) ?



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

[jira] [Commented] (OFBIZ-6528) Add a mean to untie geo associations


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

Jacques Le Roux commented on OFBIZ-6528:


Thanks Gil, I will take care of that

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Gil Portenseigne
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

2015-06-24 Thread Jacques Le Roux

Le 24/06/2015 11:47, Gavin Mabie a écrit :

Four issues:

1. The Bootstrap Basic and "Bootstrap Sunrise" is in fact just one theme
with Basic as theme and Sunrise as a "skin" (implementation of Basic).
Hence the location of the css for Sunrise under bootstrap/css/skins. Other
than that, Sunrise uses the same template libraries as Basic. It is a false
choice.
2. If we want to elevate Sunrise to theme status (i.e not just a skin),
then we have to create separate template libraries for it. To qualify as a
theme, it should have its own distinct widget implementation including
headers, menus, forms, tables, pagination etc.
3. The commits by Julien - r1683430 (header.ftl & appbar.ftl) affects
both Basic and Sunrise. I have not seen patches for these and could
therefore not do reviews.
4. The approach with the Basic theme is to keep it as basic as possible,
minimizing personal preferences with regards to look-and-feel and leaving
this level of styling up to individual designers.

I have committed patches to deal with most if not all the issues flagged by
Adrian on 19 May 2015. New issues have cropped up as a result of
r1683430. To get this merge-ready my recommendation is that we revert
r1683430 which deals with header.ftl & appbar.ft. These are minor issues
which relate mainly to personal preferences. If the changes introduced with
r1683430 is absolutely necessary, then I recommend that separate header.ftl
& appbar.ftl files are created and that themeResources in "Sunrise" point
to locations where the new files reside.

I did not review anything but from your explanation having separated/specific header.ftl & appbar.ftl files in "Sunrise" makes sense to me (since it's
a "skin")

BTW I understand that <> because it's mostly a copy of
basic, right?

Jacques

Regards

Gavin

On Wed, Jun 24, 2015 at 12:21 AM, Pierre Smits
wrote:

I am running the Bootstrap Basic (somewhat modified) against trunk.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Tue, Jun 23, 2015 at 9:56 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:

I evaluated the bootstrap branch as it currently exists. If there are
patches waiting to be applied to the branch, then I am not aware of them.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 6/23/2015 12:43 PM, Pierre Smits wrote:

Hi Adrian,

Thanks for the feedback. That the existing patch files available in JIRA
issues don't work in trunk has to do with the fact that the bootstrap

dev

branch is not in sync with trunk. We have to take in consideration that
the
framework stack of the bootstrap branch is based (for the greater part)

r1634810.

On top of that, the Bootstrap Basic and the other one were co-developed.
And shortly before the disentanglement of the two themes changes in the
templates were implemented for the other theme that affected the

Bootstrap

Basic theme negatively.

Nonetheless, I am ok with whatever which way the community chooses to go
with these bootstrap themes and the ones in trunk. It remains a personal
preference what one likes best.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Tue, Jun 23, 2015 at 5:20 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:

I don't think the new themes are ready. I updated my local copy

yesterday

and tried them out - many of the layout issues I reported still exist,
plus
I found another one.

I don't mind if there are just a few minor quirks - those can be fixed
after the themes are in the trunk, but right now there are too many.

Also, we need to discuss how many themes we want to include in the

trunk.

The Bootstrap Basic theme doesn't seem to get as much attention as the
other one, and it shows - its layout is much worse. I suggest we port
over
one of the themes instead of two.

Also, it would be nice to drop one or two existing themes.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 6/23/2015 2:08 AM, Pierre Smits wrote:

Hi all,

Recently we have seen that great strides have been made with respect

widget refactoring, theme functions disentanglement from framework (
OFBIZ-6362 ) and in
the
Bootstrap dev branch (OFBIZ-5840
).

Based on this all I am inclined to believe that both the Bootstrap

Basic

and the Bootstrap Sunrise themes are trunk ready.

What do you think?

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[jira] [Issue Comment Deleted] (OFBIZ-6529) Improve the Create/Edit Geo screen in WebTools/GeoManagement


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

Gil Portenseigne updated OFBIZ-6529:

Comment: was deleted

(was: Same Here, i managed to create a Geo (with or without giving a geoId), on 
local up-to-date Trunk, so I guess there is no problem (or I do not understand 
it))

> Improve the Create/Edit Geo screen in WebTools/GeoManagement
> 
>
> Key: OFBIZ-6529
> URL: https://issues.apache.org/jira/browse/OFBIZ-6529
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>  Labels: creation, geo
> Fix For: Upcoming Branch
>
>
> After OFBIZ-6229, the Create/Edit Geo screen in WebTools/GeoManagement does 
> no longer make sense when accessed directly (ie not automatically from Find 
> Geos screen). So you can't no longer create a Geo from there. This need to be 
> clarified. 
> * Should we still provide a direct access for creation with a button menu, or
> * Should we only access it from Find Geosand no longer allow to create a Geo 
> (no button meny only update) ?



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

[jira] [Commented] (OFBIZ-6529) Improve the Create/Edit Geo screen in WebTools/GeoManagement


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

Gil Portenseigne commented on OFBIZ-6529:
-

Same Here, i managed to create a Geo (with or without giving a geoId), on local 
up-to-date Trunk, so I guess there is no problem (or I do not understand it)

> Improve the Create/Edit Geo screen in WebTools/GeoManagement
> 
>
> Key: OFBIZ-6529
> URL: https://issues.apache.org/jira/browse/OFBIZ-6529
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>  Labels: creation, geo
> Fix For: Upcoming Branch
>
>
> After OFBIZ-6229, the Create/Edit Geo screen in WebTools/GeoManagement does 
> no longer make sense when accessed directly (ie not automatically from Find 
> Geos screen). So you can't no longer create a Geo from there. This need to be 
> clarified. 
> * Should we still provide a direct access for creation with a button menu, or
> * Should we only access it from Find Geosand no longer allow to create a Geo 
> (no button meny only update) ?



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

[jira] [Commented] (OFBIZ-6529) Improve the Create/Edit Geo screen in WebTools/GeoManagement


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

Gil Portenseigne commented on OFBIZ-6529:
-

Same Here, i managed to create a Geo (with or without giving a geoId), on local 
up-to-date Trunk, so I guess there is no problem (or I do not understand it)

> Improve the Create/Edit Geo screen in WebTools/GeoManagement
> 
>
> Key: OFBIZ-6529
> URL: https://issues.apache.org/jira/browse/OFBIZ-6529
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>  Labels: creation, geo
> Fix For: Upcoming Branch
>
>
> After OFBIZ-6229, the Create/Edit Geo screen in WebTools/GeoManagement does 
> no longer make sense when accessed directly (ie not automatically from Find 
> Geos screen). So you can't no longer create a Geo from there. This need to be 
> clarified. 
> * Should we still provide a direct access for creation with a button menu, or
> * Should we only access it from Find Geosand no longer allow to create a Geo 
> (no button meny only update) ?



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

Re: [DISCUSSION] Bootstrap Themes - is it trunk ready?

Four issues:

   1. The Bootstrap Basic and "Bootstrap Sunrise" is in fact just one theme
   with Basic as theme and Sunrise as a "skin" (implementation of Basic).
   Hence the location of the css for Sunrise under bootstrap/css/skins. Other
   than that, Sunrise uses the same template libraries as Basic. It is a false
   choice.
   2.  If we want to elevate Sunrise to theme status (i.e not just a skin),
   then we have to create separate template libraries for it. To qualify as a
   theme, it should have its own distinct widget implementation including
   headers, menus, forms, tables, pagination etc.
   3. The commits by Julien - r1683430 (header.ftl & appbar.ftl) affects
   both Basic and Sunrise. I have not seen patches for these and could
   therefore not do reviews.
   4. The approach with the Basic theme is to keep it as basic as possible,
   minimizing personal preferences with regards to look-and-feel and leaving
   this level of styling up to individual designers.

I have committed patches to deal with most if not all the issues flagged by
Adrian on 19 May 2015.  New issues have cropped up as a result of
r1683430.  To get this merge-ready my recommendation is that we revert
r1683430 which deals with header.ftl & appbar.ft.  These are minor issues
which relate mainly to personal preferences. If the changes introduced with
r1683430 is absolutely necessary, then I recommend that separate header.ftl
& appbar.ftl files are created and that themeResources in "Sunrise" point
to locations where the new files reside.

Regards

Gavin

On Wed, Jun 24, 2015 at 12:21 AM, Pierre Smits 
wrote:

> I am running the Bootstrap Basic (somewhat modified) against trunk.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Jun 23, 2015 at 9:56 PM, Adrian Crum <
> adrian.c...@sandglass-software.com> wrote:
>
> > I evaluated the bootstrap branch as it currently exists. If there are
> > patches waiting to be applied to the branch, then I am not aware of them.
> >
> > Adrian Crum
> > Sandglass Software
> > www.sandglass-software.com
> >
> > On 6/23/2015 12:43 PM, Pierre Smits wrote:
> >
> >> Hi Adrian,
> >>
> >> Thanks for the feedback. That the existing patch files available in JIRA
> >> issues don't work in trunk has to do with the fact that the bootstrap
> dev
> >> branch is not in sync with trunk. We have to take in consideration that
> >> the
> >> framework stack of the bootstrap branch is based (for the greater part)
> on
> >> r1634810.
> >>
> >> On top of that, the Bootstrap Basic and the other one were co-developed.
> >> And shortly before the disentanglement of the two themes changes in the
> >> templates were implemented for the other theme that affected the
> Bootstrap
> >> Basic theme negatively.
> >>
> >> Nonetheless, I am ok with whatever which way the community chooses to go
> >> with these bootstrap themes and the ones in trunk. It remains a personal
> >> preference what one likes best.
> >>
> >> Best regards,
> >>
> >>
> >> Pierre Smits
> >>
> >> *ORRTIZ.COM *
> >> Services & Solutions for Cloud-
> >> Based Manufacturing, Professional
> >> Services and Retail & Trade
> >> http://www.orrtiz.com
> >>
> >> On Tue, Jun 23, 2015 at 5:20 PM, Adrian Crum <
> >> adrian.c...@sandglass-software.com> wrote:
> >>
> >>  I don't think the new themes are ready. I updated my local copy
> yesterday
> >>> and tried them out - many of the layout issues I reported still exist,
> >>> plus
> >>> I found another one.
> >>>
> >>> I don't mind if there are just a few minor quirks - those can be fixed
> >>> after the themes are in the trunk, but right now there are too many.
> >>>
> >>> Also, we need to discuss how many themes we want to include in the
> trunk.
> >>> The Bootstrap Basic theme doesn't seem to get as much attention as the
> >>> other one, and it shows - its layout is much worse. I suggest we port
> >>> over
> >>> one of the themes instead of two.
> >>>
> >>> Also, it would be nice to drop one or two existing themes.
> >>>
> >>>
> >>> Adrian Crum
> >>> Sandglass Software
> >>> www.sandglass-software.com
> >>>
> >>> On 6/23/2015 2:08 AM, Pierre Smits wrote:
> >>>
> >>>  Hi all,
> 
>  Recently we have seen that great strides have been made with respect
> to
>  widget refactoring, theme functions disentanglement from framework (
>  OFBIZ-6362 ) and in
>  the
>  Bootstrap dev branch (OFBIZ-5840
>  ).
> 
>  Based on this all I am inclined to believe that both the Bootstrap
> Basic
>  and the Bootstrap Sunrise themes are trunk ready.
> 
>  What do you think?
> 
>  Best regards,
> 
>  Pierre Smits
> 
>  *ORRTIZ.COM *
>  Services & Solutions for C

Fwd: ofbiz VISA payment connection with provider

2015-06-24 Thread Heidi Dehaes

Hello,

Has anyone in Europe an idea if it is possible to connect ofbiz with a
VISA payment provider who accepts connections with ofbiz?
And how this can be done?

Regards,
Eric

Olagos bvba
Heidi Dehaes
Kerkstraat 34
2570 Duffel
Belgium
Tel. : 015/31 53 04
GSM :0485/22 35 80
E-mail : info.ola...@gmail.com
http://www.olagos.eu
http://www.olagos.com
http://www.olagos.be
http://www.olagos.nl

[jira] [Updated] (OFBIZ-6528) Add a mean to untie geo associations


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

Gil Portenseigne updated OFBIZ-6528:

Attachment: OFBIZ-6528.patch

This patch add a new grid in EditGeoScreen to see/delete GeoAssoc. 
I had CommonEntityLabels  default-resource-name on GeoAssocType for translation 
purpose.

> Add a mean to untie geo associations
> 
>
> Key: OFBIZ-6528
> URL: https://issues.apache.org/jira/browse/OFBIZ-6528
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Gil Portenseigne
>Priority: Minor
>  Labels: association, geo
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6528.patch
>
>
> In the Webtools we can asociate Geos but we have yet no means to untie them



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

[jira] [Commented] (OFBIZ-6529) Improve the Create/Edit Geo screen in WebTools/GeoManagement

2015-06-24 Thread Pierre Smits (JIRA)


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

Pierre Smits commented on OFBIZ-6529:
-

Tested against demo trunk this morning, I found I could still create a new GEO 
via the 'create/edit Geo' button. 

> Improve the Create/Edit Geo screen in WebTools/GeoManagement
> 
>
> Key: OFBIZ-6529
> URL: https://issues.apache.org/jira/browse/OFBIZ-6529
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>  Labels: creation, geo
> Fix For: Upcoming Branch
>
>
> After OFBIZ-6229, the Create/Edit Geo screen in WebTools/GeoManagement does 
> no longer make sense when accessed directly (ie not automatically from Find 
> Geos screen). So you can't no longer create a Geo from there. This need to be 
> clarified. 
> * Should we still provide a direct access for creation with a button menu, or
> * Should we only access it from Find Geosand no longer allow to create a Geo 
> (no button meny only update) ?



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

[jira] [Commented] (OFBIZ-6450) Docbook and OFBIz Online Help

2015-06-24 Thread Sharan Foga (JIRA)


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

Sharan Foga commented on OFBIZ-6450:


Hi Taher

No I don't know if the old implementation was done using Xalan but I think the 
webhelp uses Saxon.

I have a copy of the code the Webhelp addon uses and I'm doing a first pass 
through it all listing the files modified and any new files created. It's just 
a simple spreadsheet but it could give us some ideas of what code could be 
re-used and what we ones we dont need. I'm part way through so hopefully will 
be done this week and then will upload the addon code itself and my spreadsheet 
for you (or anyone else) to look at.





> Docbook and OFBIz Online Help
> -
>
> Key: OFBIZ-6450
> URL: https://issues.apache.org/jira/browse/OFBIZ-6450
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Sharan Foga
>Assignee: Sharan Foga
> Attachments: 02-docbook_overview_diagram.pdf, humanres.xml
>
>
> Jira created based on the steps suggested by Taher as follows:
> - First, we attempt to fix whatever is wrong in DocBook at the moment. If you 
> can share exactly what you spotted then this would save us a lot of time in 
> trying to dig to the problem. So a repeat process to identify the bugs from 
> you would be great.
> - Second, we decide on a category structure for the sections of the 
> documentation if we do not like the existing one
> - We also introduce or enforce a workflow that mandates an update of the 
> documentation on each JIRA that affects functionality that requires 
> documentation. For example, if we add or modify a screen in the party 
> component, then we must provide the documentation for that screen before 
> closing the JIRA for example.
> - As a last step we decide on the appropriate technology to move forward. 



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

[jira] [Assigned] (OFBIZ-6528) Add a mean to untie geo associations