[jira] Commented: (OFBIZ-2913) Write a new service for quick create customer profile.

[Sumit Pandit (JIRA)]

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

Sumit Pandit commented on OFBIZ-2913:
-

Thanks Bruno, It is good idea to place core features in a single one. +1.

> Write a new service for quick create customer profile.
> --
>
> Key: OFBIZ-2913
> URL: https://issues.apache.org/jira/browse/OFBIZ-2913
> Project: OFBiz
>  Issue Type: New Feature
>  Components: specialpurpose/ecommerce
>Affects Versions: SVN trunk
>Reporter: Sumit Pandit
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-2913.patch, OFBIZ-2913.patch, OFBIZ-2913.patch
>
>
> Write a new service for creating a customer profile. This could be called as 
> QuickCreateCustomerProfile.
> Create a Customer Profile based on following IN parameter - 
> 1) First Name 
> 2) Last Name
> 3) Email Address
> Based on above information create - Person, Party, PartyRole (CUSTOMER), 
> Contact (Email).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (OFBIZ-3387) Make AR Payment Groups screens consistent to the best practice.

[Ashish Vijaywargiya (JIRA)]

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

Ashish Vijaywargiya reassigned OFBIZ-3387:
--

Assignee: Ashish Vijaywargiya

> Make AR Payment Groups screens consistent to the best practice.
> ---
>
> Key: OFBIZ-3387
> URL: https://issues.apache.org/jira/browse/OFBIZ-3387
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Reporter: Sumit Pandit
>Assignee: Ashish Vijaywargiya
> Fix For: SVN trunk
>
> Attachments: 1.png, 2.png, 3.png, 4.png, OFBIZ-3387.patch
>
>
> Make "AR Payment Groups" screens consistent to the best practice. 
> Access URL -  https://demo.ofbiz.org/ar/control/FindArPaymentGroups

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-3379) Email sending process using one connection for To/CC/BCC causing issues

[Scott Gray (JIRA)]

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

Scott Gray commented on OFBIZ-3379:
---

If there are no objections I'll likely commit this patch in the next day or so, 
here's are summary of the changes in case anyone hasn't been following closely:
- Emails will now be sent to any valid recipients even if the SMTP server 
rejected any invalid ones.  This can be turned off if desired in 
general.properties and also on a per service call basis.
- A failure notification will be sent to the email's "from" address, listing 
the failed recipients and the reason for each failure.  The notification can be 
turned off by setting the sendFailureNotification parameter to false in the 
service context.  If a failure notification is sent then the service will 
return success even if there were failures (this prevents async calls from 
retrying and multiple failure notifications being sent).

> Email sending process using one connection for To/CC/BCC causing issues
> ---
>
> Key: OFBIZ-3379
> URL: https://issues.apache.org/jira/browse/OFBIZ-3379
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 9.04, SVN trunk
>Reporter: Pranay Pandey
>Assignee: Scott Gray
> Fix For: Release Branch 9.04, SVN trunk
>
> Attachments: OFBIZ-3379.patch, OFBIZ-3379.patch, OFBIZ-3379.patch
>
>
> Typically BCCs are handled via the sending mail client. That is, when the 
> client sees a BCC in an email, it will open up two connections to the mail 
> server, the first for the To/CC fields, the second for BCC fields, this way 
> the addresses are masked from the headers and there is that layer of 
> anonymity that BCC is used for.
> What appears to be happening is that OFBiz is sending all of the information 
> in one connection to the mail server and having the mail server sort out the 
> details. So when sendTo encountering an invalid email, and then terminating 
> the remaining execution of the outgoing process and no email sent to BCC 
> address which is usually going to be a valid address from email settings for 
> the company.
> To fix the issue, we need to send this via two connection to mail client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3379) Email sending process using one connection for To/CC/BCC causing issues

[Scott Gray (JIRA)]

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

Scott Gray updated OFBIZ-3379:
--

Attachment: OFBIZ-3379.patch

Updated patch for testing, prevents infinite recursion when the failure 
notification also fails to be sent

> Email sending process using one connection for To/CC/BCC causing issues
> ---
>
> Key: OFBIZ-3379
> URL: https://issues.apache.org/jira/browse/OFBIZ-3379
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 9.04, SVN trunk
>Reporter: Pranay Pandey
>Assignee: Scott Gray
> Fix For: Release Branch 9.04, SVN trunk
>
> Attachments: OFBIZ-3379.patch, OFBIZ-3379.patch, OFBIZ-3379.patch
>
>
> Typically BCCs are handled via the sending mail client. That is, when the 
> client sees a BCC in an email, it will open up two connections to the mail 
> server, the first for the To/CC fields, the second for BCC fields, this way 
> the addresses are masked from the headers and there is that layer of 
> anonymity that BCC is used for.
> What appears to be happening is that OFBiz is sending all of the information 
> in one connection to the mail server and having the mail server sort out the 
> details. So when sendTo encountering an invalid email, and then terminating 
> the remaining execution of the outgoing process and no email sent to BCC 
> address which is usually going to be a valid address from email settings for 
> the company.
> To fix the issue, we need to send this via two connection to mail client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Conditional seed data loading

[Tim Ruppert]

That's really interesting.  As a power usage - the Atlassian tools 
implementation of these "gadgets" is really useful and powerful in their tools. 
 

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Jan 1, 2010, at 6:06 PM, Hans Bakker wrote:

> Yes we should seriously look at this. These "gadgets" are based on the
> apache shindig (http://incubator.apache.org/shindig/) project. perhaps
> we can also use this in ofbiz? Shindig is an implementation of the
> opensocial (http://code.google.com/apis/opensocial/) standard
> 
> so ofbiz portlets can be used in other systems and viceversa?
> 
> Regards,
> Hans
> 
> 
> On Fri, 2010-01-01 at 22:07 +0100, Bruno Busco wrote:
>> When Portlets were introduced in OFBiz I had in mind what I was
>> familiar with using JIRA:
>> http://www.atlassian.com/software/jira/docs/v3.12/portlets_summary.html
>> This was also why I initially called "Dashboard" the first portalPage
>> that is actually in the OFBiz example.
>> 
>> In the latest JIRA version 4.0 they are migrating from Portlets to
>> Gadgets http://confluence.atlassian.com/display/JIRA/Using+Dashboard+Gadgets
>> and still calling "Dashboard pages" what is our portalPages.
>> 
>> -Bruno
>>> 
> -- 
> Antwebsystems.com: Quality OFBiz services for competitive rates
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Conditional seed data loading

[Hans Bakker]

Yes we should seriously look at this. These "gadgets" are based on the
apache shindig (http://incubator.apache.org/shindig/) project. perhaps
we can also use this in ofbiz? Shindig is an implementation of the
opensocial (http://code.google.com/apis/opensocial/) standard

so ofbiz portlets can be used in other systems and viceversa?

Regards,
Hans


On Fri, 2010-01-01 at 22:07 +0100, Bruno Busco wrote:
> When Portlets were introduced in OFBiz I had in mind what I was
> familiar with using JIRA:
> http://www.atlassian.com/software/jira/docs/v3.12/portlets_summary.html
> This was also why I initially called "Dashboard" the first portalPage
> that is actually in the OFBiz example.
> 
> In the latest JIRA version 4.0 they are migrating from Portlets to
> Gadgets http://confluence.atlassian.com/display/JIRA/Using+Dashboard+Gadgets
> and still calling "Dashboard pages" what is our portalPages.
> 
> -Bruno
> >
-- 
Antwebsystems.com: Quality OFBiz services for competitive rates

[jira] Commented: (OFBIZ-2913) Write a new service for quick create customer profile.

[Bruno Busco (JIRA)]

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

Bruno Busco commented on OFBIZ-2913:


Sumit,
I only meant that creating a userLogin toghether with
1) First Name
2) Last Name
3) Email Address 

does not seem to be something specific to a certain application, ecommerce, 
SFA, or whatever.

But instead is seems to be a "core" feature.
I have found a similar, but with an additional captcha topping, in MyPortal 
( Write a new service for quick create customer profile.
> --
>
> Key: OFBIZ-2913
> URL: https://issues.apache.org/jira/browse/OFBIZ-2913
> Project: OFBiz
>  Issue Type: New Feature
>  Components: specialpurpose/ecommerce
>Affects Versions: SVN trunk
>Reporter: Sumit Pandit
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-2913.patch, OFBIZ-2913.patch, OFBIZ-2913.patch
>
>
> Write a new service for creating a customer profile. This could be called as 
> QuickCreateCustomerProfile.
> Create a Customer Profile based on following IN parameter - 
> 1) First Name 
> 2) Last Name
> 3) Email Address
> Based on above information create - Person, Party, PartyRole (CUSTOMER), 
> Contact (Email).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OFBIZ-3388) JSONGroovyEventHandler

[Scott Gray (JIRA)]

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

Scott Gray closed OFBIZ-3388.
-

Resolution: Won't Fix
  Assignee: Scott Gray

Hi Kojo

The Json event handlers have been deprecated recently and you should instead 
just call your groovy event and then chain the json request from 
common-controller.xml to achieve the desired result

> JSONGroovyEventHandler
> --
>
> Key: OFBIZ-3388
> URL: https://issues.apache.org/jira/browse/OFBIZ-3388
> Project: OFBiz
>  Issue Type: New Feature
>Reporter: Kojo Gambrah
>Assignee: Scott Gray
>Priority: Minor
>
> an event handler just like JSONServiceEventHandler and JSONJavaEventhandler. 
> This is particularly useful for achieving fast turn around time when dealing 
> with groovy and require JSON responses. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Discussion: BuildBot component independence check

[Adam Heath]

Bruno Busco wrote:
> Hi Adam,
> thank you for the hint but I need some other (basic) information.
> How should I use the debian package?
> What is intended for?
> 
> I see a .pl script. Can I use it to get a partial (framework-only)
> deploy directory from a checked out OFBiz working directory ?
> 
> Sorry for this basic questions.

Update the debian/changelog, to at least contain the current svn
version. Update the date.  Do this by making a new stanza.

debian/rules clean
debian/rules binary

Install debs that get created in ..

There may be a few things that don't work, I've got a local git branch
that has a few very small improvements in debian/* that need to be added.

The packages do *not* support upgrades between different ofbiz
versions, because ofbiz doesn't support that itself.

Re: Discussion: BuildBot component independence check

[Bruno Busco]

Hi Adam,
thank you for the hint but I need some other (basic) information.
How should I use the debian package?
What is intended for?

I see a .pl script. Can I use it to get a partial (framework-only)
deploy directory from a checked out OFBiz working directory ?

Sorry for this basic questions.

-Bruno


2009/12/31 Adam Heath :
> Bruno Busco wrote:
>> How could we define new ant targets to deploy partial OFBiz configurations?
>>
>> I mean, an OFBiz configuration I would like to build and get working
>> is the one with the following applications:
>>
>> - application/commonext
>> - application/content
>> - application/party
>> - application/securityext
>> - specialpurpose/myportal
>> - specialpurpose/ofbizwebsite
>>
>> Does make sense to define a new ant target that removes all other
>> directories and then build what remains?
>> This new ant target could be executed in the BuildBot also.
>
> For reference, the debian packages have a
> -framework/-applications/-specialpurpose split.  I'd like to be able
> to split each application and specialpurpose component into it's own
> package, tho, and use dependencies/etc to bring them all back
> together.  However, the components still aren't 100% separated yet.
>
>

Re: Conditional seed data loading

[Bruno Busco]

When Portlets were introduced in OFBiz I had in mind what I was
familiar with using JIRA:
http://www.atlassian.com/software/jira/docs/v3.12/portlets_summary.html
This was also why I initially called "Dashboard" the first portalPage
that is actually in the OFBiz example.

In the latest JIRA version 4.0 they are migrating from Portlets to
Gadgets http://confluence.atlassian.com/display/JIRA/Using+Dashboard+Gadgets
and still calling "Dashboard pages" what is our portalPages.

-Bruno

2010/1/1 Tim Ruppert :
> +1 - thanks for bringing sanity back to the discussion.  What shall all of 
> these lost souls in the PHP world with with their creations?  
> http://www.hotscripts.com/category/php/scripts-programs/portal-systems/
>
> Cheers,
> Ruppert
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> On Dec 31, 2009, at 10:28 AM, David E Jones wrote:
>
>>
>> Bring confusion in the future? That's like saying you shouldn't use the term 
>> object-relational mapping unless you're talking about JPA.
>>
>> Just like object-relational mapping is a general term with many variations 
>> and implementations, and supporting the JPA interfaces is simply a feature 
>> of some of those implementations, portal and portlet are also general terms 
>> with many variations and implementations, and only some of them support the 
>> JSR 168 specification.
>>
>> Should we then say that portal/portlet software not written in Java should 
>> not use those terms?
>>
>> If so, which terms should those unfortunate souls use to describe their 
>> creations?
>>
>> -David
>>
>>
>> On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:
>>
>>> I agree with Ruth, this will (and has already) certainly bring some 
>>> confusion in future.
>>>
>>> Jacques
>>>
>>> From: "Ruth Hoffman" 
 Hi David:
 IMO the term "portlet" should only be applied to JSR 168/268 compliant 
 code.

 Regards,
 Ruth

 David E Jones wrote:
> MyPortal still needs a lot of work.
>
> It should really be just the shell of the portal and include only a very 
> few portlets that are part of the framework.
>
> Higher level components, including applications components, can have 
> their own portlets that appear in MyPortal by having data in seed/etc 
> data files, and that data will tell MyPortal about these portlets.
>
> OOTB the MyPortal stuff shouldn't know anything about any portlets (other 
> than a few basic framework ones). At runtime MyPortal will look for 
> information about other portlets, but that information should come only 
> from the higher level components where the portlets themselves live.
>
> -David
>
>
> On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:
>
>
>> That's true, it would be still a dependence.
>>
>> Anyway, in this case the MyPortal is considered to be dependent from
>> all other components (because it "mounts" portlets defined by all
>> other components in the default portalPages).
>> It should be possible to use the MyPortal component even if one of the
>> other components is not used.
>>
>> I think a different logic is needed here.
>>
>> -Bruno
>>
>> 2009/12/31 David E Jones :
>>
>>> That still represents a dependency on the other component.
>>>
>>> Lower level components should not even have anything that represents an 
>>> awareness of a higher level component.
>>>
>>> The solution, and the only solution, is to move the data to the higher 
>>> level components. It's that simple.
>>>
>>> -David
>>>
>>>
>>> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
>>>
>>>
 Hi,
 the MyPortal component has many seed data that create a dependence
 from many other components.
 This is done because the seed data create the default MyPortal
 portalPages that include several portlets from all other components.

 For example:
  >>> portalPortletId="SystemInfoNotes" portletSeqId="1"
 columnSeqId="1" sequenceNum="0"/>
  >>> portalPortletId="SystemInfoStatus" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
  >>> portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
 sequenceNum="2"/>
  >>> portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
 columnSeqId="1" sequenceNum="0"/>
  >>> portalPortletId="MyCommunications" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
  >>> portalPortletId="party" portletSeqId="1" columnSeqId="1"
 sequenceNum="0"/>
  >>> portalPortletId="partyRelContacts" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
  >>> portalPortletId="partyRelAccounts" portletSeqId="1"
 columnSeqId="1" sequence

Re: buildbot failure in ASF Buildbot on ofbiz-trunk

[Scott Gray]

On 1/01/2010, at 1:12 PM, David E Jones wrote:



Is there any way to get more details about this?


The stdio links are all we have at the moment



Evidently I'm to blame for a compile failure... but my last commit  
that involves something to be compiled was on Dec 27 in rev 894047.


It seems a compile failure is reported whenever an ant task fails,  
compile_1 is the run-tests task and based on the stdio output my guess  
is that we've got some accounting tests in there that will only pass  
in 2009 so your only mistake was to be the first to commit something  
this year :-)


I won't have time to look at fixing the tests for a few days at least  
but if anyone else wants to jump on it that would be appreciated.


Or does the blame list just look at the most recent commit even  
though the test may have included various commits since the last test?


Correct, buildbot doesn't test every commit but instead just plays  
catchup by grabbing the latest revision if multiple commits have  
occurred during the previous build cycle.  I think the blamelist will  
include everyone who has committed something to the build being  
reported on.




-David


On Dec 31, 2009, at 6:39 PM, build...@apache.org wrote:

The Buildbot has detected a new failure of ofbiz-trunk on ASF  
Buildbot.

Full details are available at:
http://ci.apache.org/builders/ofbiz-trunk/builds/2234

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

Buildslave for this Build: isis_ubuntu

Build Reason:
Build Source Stamp: [branch ofbiz/trunk] 894956
Blamelist: jonesde

BUILD FAILED: failed compile_1

sincerely,
-The ASF Buildbot







smime.p7s
Description: S/MIME cryptographic signature

[jira] Created: (OFBIZ-3388) JSONGroovyEventHandler

[Kojo Gambrah (JIRA)]

JSONGroovyEventHandler
--

 Key: OFBIZ-3388
 URL: https://issues.apache.org/jira/browse/OFBIZ-3388
 Project: OFBiz
  Issue Type: New Feature
Reporter: Kojo Gambrah
Priority: Minor


an event handler just like JSONServiceEventHandler and JSONJavaEventhandler. 
This is particularly useful for achieving fast turn around time when dealing 
with groovy and require JSON responses. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Conditional seed data loading

[Tim Ruppert]

+1 - thanks for bringing sanity back to the discussion.  What shall all of 
these lost souls in the PHP world with with their creations?  
http://www.hotscripts.com/category/php/scripts-programs/portal-systems/

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Dec 31, 2009, at 10:28 AM, David E Jones wrote:

> 
> Bring confusion in the future? That's like saying you shouldn't use the term 
> object-relational mapping unless you're talking about JPA.
> 
> Just like object-relational mapping is a general term with many variations 
> and implementations, and supporting the JPA interfaces is simply a feature of 
> some of those implementations, portal and portlet are also general terms with 
> many variations and implementations, and only some of them support the JSR 
> 168 specification.
> 
> Should we then say that portal/portlet software not written in Java should 
> not use those terms?
> 
> If so, which terms should those unfortunate souls use to describe their 
> creations?
> 
> -David
> 
> 
> On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:
> 
>> I agree with Ruth, this will (and has already) certainly bring some 
>> confusion in future.
>> 
>> Jacques
>> 
>> From: "Ruth Hoffman" 
>>> Hi David:
>>> IMO the term "portlet" should only be applied to JSR 168/268 compliant code.
>>> 
>>> Regards,
>>> Ruth
>>> 
>>> David E Jones wrote:
 MyPortal still needs a lot of work.
 
 It should really be just the shell of the portal and include only a very 
 few portlets that are part of the framework.
 
 Higher level components, including applications components, can have their 
 own portlets that appear in MyPortal by having data in seed/etc data 
 files, and that data will tell MyPortal about these portlets.
 
 OOTB the MyPortal stuff shouldn't know anything about any portlets (other 
 than a few basic framework ones). At runtime MyPortal will look for 
 information about other portlets, but that information should come only 
 from the higher level components where the portlets themselves live.
 
 -David
 
 
 On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:
 
 
> That's true, it would be still a dependence.
> 
> Anyway, in this case the MyPortal is considered to be dependent from
> all other components (because it "mounts" portlets defined by all
> other components in the default portalPages).
> It should be possible to use the MyPortal component even if one of the
> other components is not used.
> 
> I think a different logic is needed here.
> 
> -Bruno
> 
> 2009/12/31 David E Jones :
> 
>> That still represents a dependency on the other component.
>> 
>> Lower level components should not even have anything that represents an 
>> awareness of a higher level component.
>> 
>> The solution, and the only solution, is to move the data to the higher 
>> level components. It's that simple.
>> 
>> -David
>> 
>> 
>> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
>> 
>> 
>>> Hi,
>>> the MyPortal component has many seed data that create a dependence
>>> from many other components.
>>> This is done because the seed data create the default MyPortal
>>> portalPages that include several portlets from all other components.
>>> 
>>> For example:
>>>  >> portalPortletId="SystemInfoNotes" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="0"/>
>>>  >> portalPortletId="SystemInfoStatus" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>  >> portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="2"/>
>>>  >> portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="0"/>
>>>  >> portalPortletId="MyCommunications" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>  >> portalPortletId="party" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="0"/>
>>>  >> portalPortletId="partyRelContacts" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>  >> portalPortletId="partyRelAccounts" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="2"/>
>>>  >> portalPortletId="contact" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="3"/>
>>>  >> portalPortletId="LoyaltyPoints" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="4"/>
>>>  >> portalPortletId="PaymentMethods" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="5"/>
>>>  >> portalPortletId="AvsSettings" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="6"/>
>>>  >> portalPortletId="UserLogin" portletSeqId="1" columnSeqId="2"
>>> sequenceNum="1"/>
>>>  >> portalPortletId="Attributes" port

Re: Conditional seed data loading

[Jacques Le Roux]

Sorry Michael,

So you idea is to propose to use mahsups instead of standard portlets (already 2 std actually, even 3 with JSR enhancements), that's 
it?


FYO: there has been already a proposition on Mashup
http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document#NewFeaturesRoadmap-LivingDocument-IntroduceMashups

Jacques

From: "Michael Xu (xudong)" 

Maybe we can take a look at mashup, which is not that heavy as portlets.

http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

--
Regards,
Michael Xu (xudong)
www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
9807 | Fax: (8610) 62670096


On Fri, Jan 1, 2010 at 2:37 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Actually we would just have to change the name at the surface, from a
marketing POV if you prefer. No need to change underneath.
But sincerely I have not much time for that... Where is it used in
documentation which could induce new users in error?


Jacques

From: "Ruth Hoffman" 


Hi Jacques:
IMO, it is a big deal. When someone is looking at OFBiz for an enterprise
solution and the competition is Jetspeed, Liferay, Websphere etc., we should
be clear  that when the OFBiz project says "Portal" it does not mean what
everyone else "thinks it means". It is misleading.

Just to be clear: I don't think OFBiz needs a JSR compliant portal server.
In my experience, portal servers are bloated and overrated and have limited
use.

Maybe we could take a little survey - do some marketing - and come up with
another label for these features/functions?

Just a thought.
Ruth

Jacques Le Roux wrote:


From: "David E Jones" 


Bring confusion in the future? That's like saying you shouldn't use the
term object-relational mapping unless you're talking about JPA.

Just like object-relational mapping is a general term with many
variations and implementations, and supporting the JPA interfaces is simply
a feature of some of those implementations, portal and portlet are also
general terms with many variations and implementations, and only some of
them support the JSR 168 specification.

Should we then say that portal/portlet software not written in Java
should not use those terms?

If so, which terms should those unfortunate souls use to describe their
creations?



OFBiz-portlets and OFBiz-portal ? Not a big deal anyway, just that some
people think they will be able to embed some external portlets in OFBiz and
are dissapointed.

Jacques

 -David



On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:

 I agree with Ruth, this will (and has already) certainly bring some

confusion in future.

Jacques

From: "Ruth Hoffman" 


Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 compliant
code.

Regards,
Ruth

David E Jones wrote:


MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only a
very few portlets that are part of the framework.

Higher level components, including applications components, can have
their own portlets that appear in MyPortal by having data in seed/etc data
files, and that data will tell MyPortal about these portlets.

OOTB the MyPortal stuff shouldn't know anything about any portlets
(other than a few basic framework ones). At runtime MyPortal will look for
information about other portlets, but that information should come only from
the higher level components where the portlets themselves live.

-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:


 That's true, it would be still a dependence.


Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one of
the
other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :

 That still represents a dependency on the other component.


Lower level components should not even have anything that
represents an awareness of a higher level component.

The solution, and the only solution, is to move the data to the
higher level components. It's that simple.

-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:


 Hi,

the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other
components.

For example:
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

How can we have a conditional seed data loading that would load
only
seed data for the portlets really available in the system?
I mean, could we have something like this:


 
 


or is there any other tecnique to do this?

Many thanks,
Bruno

Re: buildbot failure in ASF Buildbot on ofbiz-trunk

[Jacques Le Roux]

Hi David,

It's only tests that are failing 
http://ci.apache.org/builders/ofbiz-trunk/builds/2234/steps/compile_1/logs/stdio
You can see it looking through the stdio link in the red block

Or were you looking for something else? What do you call test below?

Jacques


From: "David E Jones" 


Is there any way to get more details about this?

Evidently I'm to blame for a compile failure... but my last commit that involves something to be compiled was on Dec 27 in rev 
894047.


Or does the blame list just look at the most recent commit even though the test may have included various commits since the last 
test?


-David


On Dec 31, 2009, at 6:39 PM, build...@apache.org wrote:


The Buildbot has detected a new failure of ofbiz-trunk on ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/ofbiz-trunk/builds/2234

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

Buildslave for this Build: isis_ubuntu

Build Reason:
Build Source Stamp: [branch ofbiz/trunk] 894956
Blamelist: jonesde

BUILD FAILED: failed compile_1

sincerely,
-The ASF Buildbot