Hi David,
inline
> Please keep in mind that is just your document. There is no such thing as
> implicit agreement, and if there are disagreements on the mailing list IMO
> that is just as valid as someone going in and changing your document (and
> most people would probably consider it less rud
--- On Sun, 1/3/10, David E Jones wrote:
> On Jan 3, 2010, at 2:04 PM, Adrian Crum wrote:
>
> > --- On Sun, 1/3/10, David E Jones
> wrote:
> >> One way or another if we're moving things around,
> >> especially moving higher level stuff into the
> framework,
> >> then we should definitely discuss
On Jan 3, 2010, at 2:04 PM, Adrian Crum wrote:
> --- On Sun, 1/3/10, David E Jones wrote:
>> One way or another if we're moving things around,
>> especially moving higher level stuff into the framework,
>> then we should definitely discuss it first and even try to
>> reach a consensus around it.
--- On Sun, 1/3/10, David E Jones wrote:
> One way or another if we're moving things around,
> especially moving higher level stuff into the framework,
> then we should definitely discuss it first and even try to
> reach a consensus around it.
>
> For example, one specific idea might be to move s
On Jan 3, 2010, at 3:53 AM, Bruno Busco wrote:
> When I sayd "at least me" I should have said "To implement the
> framework-only distribution end-user requirements here
> http://cwiki.apache.org/OFBIZ/framework-only-distribution.html";
> We should agree or change what is written there and then wo
When I sayd "at least me" I should have said "To implement the
framework-only distribution end-user requirements here
http://cwiki.apache.org/OFBIZ/framework-only-distribution.html";
We should agree or change what is written there and then work to implement it.
The framework-only work should of co
David E Jones wrote:
On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
One major question is whether framework, on its own, should even be
runnable as an application. In my opinion, it is a library, not an app
and doesn't need to be operational on its own.
The more we discuss about this
On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
>> One major question is whether framework, on its own, should even be
>> runnable as an application. In my opinion, it is a library, not an app
>> and doesn't need to be operational on its own.
>
> The more we discuss about this the more I get conv
Those are exactly the type of questions I was writing concurrently Adam -
thanks for bringing them up. My off the cuff response is that this isn't
tomcat or jboss - it runs in the containers, but is not one itself, so what
exactly would the framework do without an application sitting on top of
Those of us with strong Unix backgounds really don't want to see anything named
"core" - so I'd say let's look for some other name. What you're pushing for
Bruno - is much needed and could be a great enhancement to the usage of OFBiz.
Anything that'll make it easier for people to build - non-e
Ean Schuessler wrote:
> Adrian Crum wrote:
>> I don't agree that emailing forgotten passwords is like the Webtools
>> application. As you have discovered, emailing forgotten passwords
>> entails some decision making, looking up information in various
>> entities, selecting and rendering an email bo
> One major question is whether framework, on its own, should even be
> runnable as an application. In my opinion, it is a library, not an app
> and doesn't need to be operational on its own.
The more we discuss about this the more I get convinced that what we
(or at least me) intend for framework
Adrian Crum wrote:
> I don't agree that emailing forgotten passwords is like the Webtools
> application. As you have discovered, emailing forgotten passwords
> entails some decision making, looking up information in various
> entities, selecting and rendering an email body template, etc. From my
>
Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServl
It seems to me that a Framework+Party+Content installation would
better fit the requirements in
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution.
-Bruno
2009/12/30 Bruno Busco :
> Adrian,
> I think our divergence comes from how we imagine the framework-only being
> us
Adrian,
I think our divergence comes from how we imagine the framework-only being used.
I imagine the framework-only installation ready to be used as soon as installed.
Admin can login and start adding users, groups, set permissions.
Users can start logging in, personalizing their home Portal pages
I don't agree that emailing forgotten passwords is like the Webtools
application. As you have discovered, emailing forgotten passwords
entails some decision making, looking up information in various
entities, selecting and rendering an email body template, etc. From my
perspective, all of those
I would recommend changing #6 to:
#6 users can change their password
and then drop 7 through 9.
But that's just my opinion.
-Adrian
Bruno Busco wrote:
OK,
back to requirements.
I tryed to write down a list of requirements here:
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only
Bruno Busco wrote:
> One thing we need in the framework is the possibility to create a
> userLogin with an associated email address and have the possibility to
> have the password emailed if forgotten.
> This is actually done in
> public static String emailPassword(HttpServletRequest request,
>
Adrian,
I agree that this can be done in an application using the framework
but this application should be located in the framework folder like
the webtools application.
-Bruno
2009/12/30 Adrian Crum :
> All of the things you are describing could be done by an application
> developer that is usin
OK,
back to requirements.
I tryed to write down a list of requirements here:
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
Could we have a discussion and possibly change them as and refine them
as required?
-Bruno
2009/12/30 Adrian Crum :
> All of the things you a
All of the things you are describing could be done by an application
developer that is using the framework.
It would be wise to draw a very distinct and strict line between
framework-level functionality and application-level functionality.
-Adrian
Bruno Busco wrote:
Then we should have a se
Like Scott said, that feature is appropriate for applications, not for
the framework. So we can create framework services for the feature that
do nothing - which can then be overridden by applications, or we can
remove the feature from the framework and implement it entirely in the
Party applic
Then we should have a setPrimaryEmailAddress service defined in the
framework (that sets the userLogin.email field) and overridden in the
Party application that sets/create the propert PArty/ContactMech.
Does this make sense?
-Bruno
2009/12/30 Bruno Busco :
> Adrian,
> the getPrimaryEmailAddress
Adrian,
the getPrimaryEmailAddress defined in the framework could return the
email field stored in the userLogin entity and when it is override by
the Party application can retrieve the address from the
userlLogin->Party->ContactMech chain.
In this way we should get it working in the framawork-onl
Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).
-Bruno
2009/12/30 Adrian Crum :
> Or have a service - getPrimaryEmailAddress - that is defined in the
> framework and returns nothing. T
In the framework-only there will be the webtools, the example and the
MyPortal applications.
So it is something that should allow defining new users (userLogins)
to be defined with their permissions.
As soon as I have a new user defined I need the forgot password feature working.
This is why we nee
Or have a service - getPrimaryEmailAddress - that is defined in the
framework and returns nothing. The Party application can override the
service to return the primary email address, if it exists.
-Adrian
Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
use
My first question is why do we need this functionality in the
framework? At what point do we draw the line between framework and
application? Emailing passwords sounds very much like an application
feature to me.
Regards
Scott
On 30/12/2009, at 11:50 AM, Bruno Busco wrote:
One thing we
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response)
Hi Bruno,
The whole point of the securityext component is to allow portions of
security related functionality to depend on the application
components, I believe this was done as part of the effort to isolate
the framework from any application dependencies. I think it is
perfectly fine to
UserLogin has a partyId field extended in Party application. This is certainly something that is widely used (so convenient) and
should be taken with care.
Jacques
From: "Bruno Busco"
Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stu
Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in t
Scott,
from a securityext code browsing I see that there is a dependence from
Party, Product and Ecommerce.
Party:
1) The UserDemoData.xml file creates several Party, Person, PartyRole,
PartyContactMech entities
-> Could be moved to Party?
2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE p
I guess the first thing we need to understand is why it exists in the
first place? I'm assuming it has some dependencies on application
components that prevent it from being in the framework (even if
perhaps some of the logic could be moved).
Regards
Scott
HotWax Media
http://www.hotwaxme
Hi,
the securityext component is actually located in the application folder.
It implements the sending of the password remainder, password updated
services, permission groups etc. that we want available in the
framework-only release also.
Do we agree to change it to move it over there?
At least th
36 matches
Mail list logo
