Re: svn commit: r1031655 - /ofbiz/trunk/framework/images/webapp/images/selectall.js
Jacques,
When using the auto complete, the value isn't properly set until after
the description is parsed. The value field may contain the key and the
description until after it is parsed out. The onchange event runs
before this happens, so it needs to be called after the string is
parsed and placed into the proper fields.
That explains why the onchange event is called from here. The reason
the onchange event is called in the first place is because these
events don't trigger when you set values programmatically only when
the value is actually changed by the user (through the browser). So we
call the event manually to make sure any listeners are notified.
---
Andrew Zeneski
and...@andrewzeneski.com
-- Forwarded message --
From: "Jacques Le Roux"
To:
Date: Sun, 7 Nov 2010 16:49:50 +0100
Subject: Re: svn commit: r1031655 -
/ofbiz/trunk/framework/images/webapp/images/selectall.js
Hi Andrew,
I try to understand how and when this is helpful. In other words why
did you add this? Could you please give an example?
This question because I wonder if I should use it in the jQuery branch.
Thanks
Jacques
From:
Author: jaz
Date: Fri Nov 5 16:13:00 2010
New Revision: 1031655
URL: http://svn.apache.org/viewvc?rev=1031655&view=rev
Log:
small change to call the onchange event when updating the autocomplete
fields after the description is set
Modified:
ofbiz/trunk/framework/images/webapp/images/selectall.js
Modified: ofbiz/trunk/framework/images/webapp/images/selectall.js
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/images/webapp/images/selectall.js?rev=1031655&r1=1031654&r2=1031655&view=diff
==
--- ofbiz/trunk/framework/images/webapp/images/selectall.js (original)
+++ ofbiz/trunk/framework/images/webapp/images/selectall.js Fri Nov 5
16:13:00 2010
@@ -410,6 +410,12 @@ function setLookDescription(textFieldId,
tooltipElement.update(description);
lookupWrapperEl.appendChild(tooltipElement);
}
+
+// after the description is set; the text field may have been updated
+// just in case, call onchange again
+if ($(textFieldId).onchange != null) {
+$(textFieldId).onchange();
+}
}
Re: dev Digest 29 Dec 2010 11:42:10 -0000 Issue 2758
Why not check it into SVN so its easy for everyone to use? On Dec 29, 2010, at 6:42 AM, dev-digest-h...@ofbiz.apache.org wrote: > From: "Jacques Le Roux" > Date: December 28, 2010 5:59:20 AM EST > To: > Subject: Re: svn commit: r1053198 - > /ofbiz/trunk/framework/images/webapp/images/getDependentDropdownValues.js > > > Hi, > > Following this, I'd like to suggest to use, if possible, Eclipse/Aptana for > editing Javascript files and notably to format them correctly. I suggest also > to not use tabs in *our* javascript files but 4 spaces (like in Java) > I have put the Aptana formatting template as an attachment of OFBiz > Contributors Best Practices > > Thanks to share your opinion > > Jacques > > From: >> URL: http://svn.apache.org/viewvc?rev=1053198&view=rev >> Log: >> Use the power of Aptana to format correctly this file. I have adapted the >> default format setting to be more near our best practices. If you are >> interested I can share the formatting template. >> >> Anyway I think I will discuss that on dev ML latter. We could have it posted >> in the wiki, when agreed upon its content, and use it as part of our best >> practices... >> >
Re: Re: svn commit: r1089946 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/DateTimeConverters.java
I hate that it breaks a pattern, but implementing the reverse would really
be pointless; the whole point of this is to catch dates passed to services
that are not formatted in pre-definied format in UtilDateTime (i.e. no
milliseconds, etc) that would be caught otherwise.
This is just a failsafe for those conditions.
Andrew
On Thu, Apr 7, 2011 at 3:59 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
>
>
> Original Message Subject: Re: svn commit: r1089946 -
> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/DateTimeConverters.java
> Date:
> Thu, 07 Apr 2011 12:30:37 -0700 From: Adrian Crum
>
> Reply-To:
> dev@ofbiz.apache.org Organization: Sandglass Software To:
> dev@ofbiz.apache.org
>
> Keep in mind that this change breaks one of the converter design goals:
> Conversions should be bi-directional.
>
> -Adrian
>
>
> On 4/7/2011 12:27 PM, j...@apache.org wrote:
> > Author: jaz
> > Date: Thu Apr 7 19:27:53 2011
> > New Revision: 1089946
> >
> > URL: http://svn.apache.org/viewvc?rev=1089946&view=rev
> > Log:
> > added fall back to default date formatter when conversion fails before
> >
> > Modified:
> >
> > ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/DateTimeConverters.java
> >
> > Modified:
> > ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/DateTimeConverters.java
> > URL:
> > http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/DateTimeConverters.java?rev=1089946&r1=1089945&r2=1089946&view=diff
> > ==
> > ---
> > ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/DateTimeConverters.java
> > (original)
> > +++
> > ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/DateTimeConverters.java
> > Thu Apr 7 19:27:53 2011
> > @@ -522,7 +522,16 @@ public class DateTimeConverters implemen
> > try {
> > return new java.sql.Timestamp(df.parse(str).getTime());
> > } catch (ParseException e) {
> > -throw new ConversionException(e);
> > +// before throwing an exception, try a generic format first
> > +df = DateFormat.getDateTimeInstance();
> > +if (timeZone != null) {
> > +df.setTimeZone(timeZone);
> > +}
> > +try {
> > +return new java.sql.Timestamp(df.parse(str).getTime());
> > +} catch (ParseException e2) {
> > +throw new ConversionException(e);
> > +}
> > }
> > }
> > }
> >
> >
>
>
Re: svn commit: r1211073 - in /ofbiz/trunk: applications/accounting/src/org/ofbiz/accounting/thirdparty/worldpay/WorldPayEvents.java framework/common/src/org/ofbiz/common/CommonServices.java framework
Yeah, I noticed that right after I checked it in. Its been reverted.
Andrew
On Dec 6, 2011, at 3:25 PM, Adrian Crum wrote:
> Please revert this. It does not compile on Sun/Oracle JDK.
>
> -Adrian
>
> On 12/6/2011 7:51 PM, j...@apache.org wrote:
>> Author: jaz
>> Date: Tue Dec 6 19:51:28 2011
>> New Revision: 1211073
>>
>> URL: http://svn.apache.org/viewvc?rev=1211073&view=rev
>> Log:
>> few minor changes to fix compiling with openjdk icetea6 1.7.9
>>
>> Modified:
>>
>> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/worldpay/WorldPayEvents.java
>> ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonServices.java
>> ofbiz/trunk/framework/security/src/org/ofbiz/security/OFBizSecurity.java
>>
>> Modified:
>> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/worldpay/WorldPayEvents.java
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/worldpay/WorldPayEvents.java?rev=1211073&r1=1211072&r2=1211073&view=diff
>> ==
>> ---
>> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/worldpay/WorldPayEvents.java
>> (original)
>> +++
>> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/worldpay/WorldPayEvents.java
>> Tue Dec 6 19:51:28 2011
>> @@ -399,7 +399,7 @@ public class WorldPayEvents {
>> // attempt to release the offline hold on the order (workflow)
>> OrderChangeHelper.releaseInitialOrderHold(dispatcher, orderId);
>> // call the email confirm service
>> -Map emailContext = UtilMisc.toMap("orderId",
>> orderId, "userLogin", userLogin);
>> +Map emailContext = UtilMisc.toMap("orderId",
>> orderId, "userLogin", userLogin);
>> try {
>> dispatcher.runSync("sendOrderConfirmation", emailContext);
>> } catch (GenericServiceException e) {
>>
>> Modified:
>> ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonServices.java
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonServices.java?rev=1211073&r1=1211072&r2=1211073&view=diff
>> ==
>> --- ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonServices.java
>> (original)
>> +++ ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonServices.java
>> Tue Dec 6 19:51:28 2011
>> @@ -184,7 +184,7 @@ public class CommonServices {
>> partyId = userLogin.getString("partyId");
>> }
>>
>> -Map fields = UtilMisc.toMap("noteId", noteId,
>> "noteName", noteName, "noteInfo", note,
>> +Map fields = UtilMisc.toMap("noteId", noteId,
>> "noteName", noteName, "noteInfo", note,
>> "noteParty", partyId, "noteDateTime", noteDate);
>>
>> try {
>>
>> Modified:
>> ofbiz/trunk/framework/security/src/org/ofbiz/security/OFBizSecurity.java
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/security/src/org/ofbiz/security/OFBizSecurity.java?rev=1211073&r1=1211072&r2=1211073&view=diff
>> ==
>> --- ofbiz/trunk/framework/security/src/org/ofbiz/security/OFBizSecurity.java
>> (original)
>> +++ ofbiz/trunk/framework/security/src/org/ofbiz/security/OFBizSecurity.java
>> Tue Dec 6 19:51:28 2011
>> @@ -49,7 +49,7 @@ public class OFBizSecurity implements Se
>>
>> protected Delegator delegator = null;
>>
>> -protected static final Map>
>> simpleRoleEntity = UtilMisc.toMap(
>> +protected static final Map>
>> simpleRoleEntity = UtilMisc.toMap(
>> "ORDERMGR", UtilMisc.toMap("name", "OrderRole", "pkey", "orderId"),
>> "FACILITY", UtilMisc.toMap("name", "FacilityParty", "pkey",
>> "facilityId"),
>> "MARKETING", UtilMisc.toMap("name", "MarketingCampaignRole",
>> "pkey", "marketingCampaignId"));
>> @@ -208,10 +208,10 @@ public class OFBizSecurity implements Se
>> if (hasEntityPermission(application + "_ROLE", action,
>> userLogin)) return true;
>> }
>>
>> -Map simpleRoleMap =
>> OFBizSecurity.simpleRoleEntity.get(application);
>> +Map simpleRoleMap =
>> OFBizSecurity.simpleRoleEntity.get(application);
>> if (simpleRoleMap != null&& roles != null) {
>> -entityName = simpleRoleMap.get("name");
>> -String pkey = simpleRoleMap.get("pkey");
>> +entityName = (String) simpleRoleMap.get("name");
>> +String pkey = (String) simpleRoleMap.get("pkey");
>> if (pkey != null) {
>> List expressions = new ArrayList();
>> for (String role: roles) {
>>
>>
Re: webslinger quick start guide?
I actually wrote a little prototype app using JackRabbit late last year. Its a really nifty framework. Just a different way of thinking. I think this is a really good idea.. Andrew On Wed, Jul 1, 2009 at 10:33 PM, David E Jones wrote: > > There has been a little bit of discussion about this, but not recently. > Thanks for bringing it up as it certainly applies to this discussion. > > I did a little reading on JackRabbit... it's great to see it is SO far > along! In fact, it looks like it is far enough along that we should probably > just go for it... IMO. It supports versioning, JTA transaction, WebDAV for > editors that support/like that, and all sorts of other goodies. > > -David > > > On Jul 1, 2009, at 6:16 PM, Mike Rose wrote: > >> Have you folks looked into JSR-170, the Java Content Repository spec? It >> covers these classes of use cases pretty thoroughly and there are some very >> compelling implementations out there. Alfresco is probably the most notable >> and Apache JackRabbit is pretty impressive as well. >> >> Mike >> >> (new to the list, please forgive me if I've violated some protocol known >> to long-term list members...) >> >> On Jul 1, 2009, at 8:12 PM, Adrian Crum wrote: >> >>> >>> --- On Wed, 7/1/09, David E Jones wrote: >>> From: David E Jones Subject: Re: webslinger quick start guide? To: dev@ofbiz.apache.org Date: Wednesday, July 1, 2009, 2:45 PM This is an interesting overview and while I'm not sure why I hadn't thought along these lines before, at least it's through my thick skull now... I asked Adam about how this would deploy on multiple servers with the stuff in the filesystem versus the database, and I think what you've written Ean is the answer. Why not treat a source repo (either plain SVN or something more exotic like GIT) like the database? Each app server would read from and write to the source repo just like it would a database record. If SVN or GIT support 2-phase commits we could probably even do write operations in the a transaction that includes connections to both data stores. >>> >>> Why not have the repositories use the OFBiz database as their data store? >>> >>> -Adrian >>> >>> >>> >>> >> > >
Re: Brainstorming: Security Requirements/Scenarios
+1 on abstracting the Authorization API. +1 on dynamic hierarchies I should have some time to knock out some of this code too, so I am happy to coordinate with whom ever takes the lead. Andrew On Fri, Jul 10, 2009 at 3:03 AM, David E Jones wrote: > > On Jul 9, 2009, at 9:36 PM, Adrian Crum wrote: > >> >> --- On Thu, 7/9/09, David E Jones wrote: 1. The document proposes converting the Security >>> >>> abstract class to an interface, and adding new methods to >>> the interface that will implement the new security design. >>> If there are no objections to changing Security to an >>> interface, then I will design and document the new Security >>> API. >>> >>> What would go in the new security API? Isn't the idea to >>> externalize this and make it configurable? >> >> One of Andrew's goals was to make the OFBiz security implementation more >> compatible with third party authorization software - a goal I am 100% in >> agreement with. I was picturing (and I thought I made this clear in the >> document, but maybe it needs more work) having a Java interface with a set >> of methods that would define a security API. The artifacts would interact >> with that API. The idea is to decouple the implementation of security. The >> interface's implementation might use OFBiz entities, or Andrew's Cloud, or >> LDAP. The artifacts won't know the difference - they only see the API. >> >> Artifact <--> Authorization Manager API <--> ??? > > You're talking about authorization and not authentication, right? Are there > any standards for authorization that we could implement to? (I'm not aware > of any...) > > >>> What I mean by that is that the point of the dynamic >>> ones is that the "path" as it were doesn't depend at all on >>> where the artifact is located, it only depends on how the >>> artifact is referred to or "invoked" at run time. >>> >>> In fact, to be frank, I don't think there is any reason we >>> should consider not using the "dynamic" method. >> >> The reason I see a problem with that approach (and I'm not trying to be >> argumentative, just trying to make sure we understand each other's concepts) >> is there could be hundreds of execution paths leading to an artifact. Each >> of those execution paths would have to have permissions assigned to them. > > I'm not sure if you'd ever want to do that. The general idea is that you > specify permissions for a particular artifact and generally you'd say it is > an "inheritable" permission so that anything the artifact refers to or calls > would inherit the permission and not need one of its own. > > With the stuff I wrote up you wouldn't typically even have permissions for > individual services, and sometimes not even for screens. More commonly you'd > grant permission to a webapp, a decorator screen, etc. If you want to you > could do lower level permissions but most of the time it simply wouldn't be > desired or necessary. > >> In the static hierarchy, the Authorization Manager doesn't care how you >> got to an artifact, it only cares about what your permissions are once you >> get there. > > For lower level artifacts isn't how we go there more important than the > permissions on the artifact itself? For example, a screen may be used in > more than one application and we probably care more about the application > (or part of that application) that it was rendered in than we do about that > particular screen. If we do care about the particular screen we'd probably > still want different permissions depending on which application it was > rendered in. > > >>> BTW, to do this one thing that will need to be done is to >>> implement the "ExecutionContext" object, and on that note I >>> think that will help with the multi-tenancy and deployment >>> flexibility things that have been discussed on the list >>> recently (especially by Marc and Henning). The idea is that >>> nothing would keep a local reference to the delegator or >>> dispatcher, not even the service engine, control servlet, >>> and other framework components too. >> >> Now that I have written a servlet for the iCalendar integration, I know >> exactly what you're saying here. And I agree 100%. Even if we made that >> change without the security redesign, it would be a huge plus for the >> framework. > > Yeah, one way or another this lower-level object should (and hopefully soon > will!) be implemented. It wouldn't depend on the security changes and the > new security stuff could/would use it. > > -David > > >
Re: Discussion: Main Content Layout Best Practices
I can agree with most except list results and the form should be rendered as one screen. This is to make usage easier when the user wants to change the search parameters. Having the form collapsed by default when there are results is good. Andrew On May 30, 2008, at 12:16 PM, Adrian Crum <[EMAIL PROTECTED]> wrote: Getting back to this... Here are the layout best practices discussed so far: "In the case where items are being added to a list, it is preferable to have the item data entry screen and the item list on separate screens. If the two functions are incorporated into one screen, then the item data entry screen should be above the item list. In addition, the item data entry screen should be collapsible and initially collapsed." "If a Find Item screen has a form for search options, the search options form should be above the list of items found. The list of items found should display all items initially - giving the user the ability to narrow the results via the search options form." Can we agree on these? -Adrian Jacques Le Roux wrote: From: "Scott Gray" <[EMAIL PROTECTED]> It looks nice but if we did that the user would lose the ability to refer back to the list while entering data, I would prefer an expand/ collapse form if we are going to keep them on the same page. Yes I agree, but I really like the idea for the calendar (I can't propose it for lookups are they are too much to be loaded when lauching and the probability of use is far more low, but maybe one day, when machines will be more powerful :D Jacques Regards Scott 2008/5/24 Anil Patel <[EMAIL PROTECTED]>: I think what David is suggesting is something like this http://www.wildbit.com/demos/modalbox/ Regards Anil Patel On May 23, 2008, at 1:57 PM, David E Jones wrote: I didn't say open a new window, I said either expand a hidden area or popup using JavaScript within the window (ie over top of the list behind it). -David On May 23, 2008, at 11:55 AM, Jacques Le Roux wrote: IMHO, we should avoid to overuse popping as opening a new window is time consuming (especially in Firefox). This is currently a major inconvenience for Lookups and Calendar for instance Jacques From: "David E Jones" <[EMAIL PROTECTED]> Since we're entering the world of using more javascript in the browser, why not have the add form on the top but hidden by default with and Add button of some sort that would cause the form to be shown? We could even make it fancy and popup over top of the list form and have it go away after submission with an update of the list behind it... without any page loads even. -David On May 22, 2008, at 11:38 PM, Scott Gray wrote: I would agree with that but personally I would prefer to see them on completely different pages. If I wanted to be able to refer back to the list while adding I would ctrl+click and then ctrl+tab to flick back and forth, that's what makes tabbed browsers so handy. One of the problems with having them on the same page is that any errors after adding would be displayed before the list while the add form would be way down the bottom. Regards Scott 2008/5/23 David E Jones <[EMAIL PROTECTED]>: On May 22, 2008, at 9:11 AM, Adrian Crum wrote: 2) If a screen has a list and add form, what should be the order of these forms (I have seen in your recent work that add form should come on top and I completely agree with this). I believe the form should be on top of the list. Otherwise, as you add items to the list, the form is scrolled off the bottom of the screen. The main question is: what is going to be used more? Will it be the list or the add form? If in most cases it will be the list, and if you have to scroll down every time to see it... that's a pain. -David
Re: OutOfMemoryError: Java heap space
+1 Andrew On Jul 7, 2008, at 6:17 AM, Jacopo Cappellato <[EMAIL PROTECTED] > wrote: I did some load testing and it seems that the issue is caused by the upgrade to Tomcat 6: we are probably doing something wrong in the way we init the embedded instance. What if I downgrade to Tomcat 5 and I move the patch for the upgrade to Tomcat 6 in Jira? Then we will have more time to investigate and fix this rather critical issue. What do you think? Jacopo On Jul 5, 2008, at 7:35 PM, Tom Burns wrote: Test SVN to Eclipse Ganymede> build > run install > setup an OFBiz run configuration (without VM arguments) > Goto Entity Reference - Interactive > Fail Closed Eclipse Ran from command line (ofbiz start) with same result Ran from Eclipse with arguments set -Xms128M -Xmx512M > Success :) os.name=Windows XP os.version=5.1 osgi.arch=x86 512mb eclipse.vmargs=-Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx512m -XX:MaxPermSize=256M Hope this helps. Tom - Original Message From: Tim Ruppert <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Saturday, July 5, 2008 12:53:41 PM Subject: Re: OutOfMemoryError: Java heap space Tom, can you please give us information on how you are running it and what the heap size setups are? Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Jul 5, 2008, at 7:49 AM, Tom Burns wrote: Yesterday a fresh trunk copy ran out of memory... org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen [component://webtools/widget/EntityScreens.xml#EntityRefMain]: java.lang.IllegalArgumentException: Error calling service with name getEntityRefData: org.ofbiz.service.GenericServiceException: Service target threw an unexpected exception (Java heap space) (Error calling service with name getEntityRefData: org.ofbiz.service.GenericServiceException: Service target threw an unexpected exception (Java heap space)) I had a similar problem some weeks ago. Did nothing about it - well I'm only a lurker :) ! Tom - Original Message From: Jacopo Cappellato <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Saturday, July 5, 2008 3:55:32 AM Subject: OutOfMemoryError: Java heap space Hi all, I have noticed a "OutOfMemoryError: Java heap space" error happening quite frequently on some production ecommerce site running on OFBiz. Anybody else have noticed this error on a recently updated server? This error may be related (but not sure) to the upgrade to Tomcat 6... maybe there is something wrong in the way we create the embedded instance of Tomcat. Thanks, Jacopo
Re: Knowing a back end exists
You should secure your backend, and at the very least tell robots.txt to not search. IMO this is the job of the webmaster not the open source project. Andrew On Aug 18, 2008, at 2:38 PM, BJ Freeman wrote: while doing google I found a lot of links to the actual back end of the ofbiz demo this got me to wondering how more susceptible we are if the a search engine finds a link to our backend. I have a domain that even though the page is now gone, there are attempts to hack the page for security. I get like 100s of posts and gets to this page everyday, for different IP addresses. smime.p7s Description: S/MIME cryptographic signature
Re: Application framework technology set
Anil, These are really great questions to ask, and I am excited to see this thread start. Let me be the first to say, I agree with you 100% that now is the time to plan for the future. When we started OFBiz in 2001, the tools available were less powerful and less appealing than the ones available today. If we were starting today I think a lot would be different. For example, I would probably vote for JPA over writing another persistence layer. I would vote for using Stripes, Wicket, or maybe JSF (but v2) for presentation. On the service layer, I would prefer to use an existing framework be it EJB (session beans) or some flavor of an ESB (maybe ServiceMix). In the end, focus 100% on the applications and let the other projects focus on each specific framework piece. Most of all, I would vote in favor standardized deployment. OFBiz is not SAP, we just don't have enough clout to dictate how the application should be deployed. People bend over backwards and design their entire infrastructure around SAP, we should do the opposite; allow OFBiz to adjust to a company's infrastructure (without headaches). The last thing I would do differently, if I could figure out a way how, is to decouple the applications. So that a CRM application does not require the overhead needed for Orders and Products. Then we have the next question, what types of applications should we focus now to be the leader in the next 5 years? Do with stick with ERP, or do we look to make some changes? But I think this should be a thread all in itself. Andrew On Oct 24, 2008, at 7:36 PM, Anil Patel wrote: Hi, I am having little difficulty to envision, What Ofbiz will look like a year or two down the road? I am personally satisfied with most of core technologies of ofbiz except for Form widget. Form widgets needs some enhancements and even those don't seem too difficult. Ofbiz framework technologies made development lot easy back in day when J2EE made things impossible. Now, 7 years down the road, Java enterprise application development tool set has changed a lot. What I am trying to get out of this thread is, What others in community think about it?" At different times, people have asked for ability to deploy ofbiz on application servers other then Tomcat, and in JEE recommended style, like create war or ear. I am curious what did these people do? Did we loose those potential ofbiz users!, Or Did they accept whatever is available and used ofbiz to solve their business problems. There are some JEE spec compliant technologies that we can use instead of home grown like, use 1) Ice Faces (or Myfaces) instead of Form Widget 2) JPA instead of Entity engine 3) EJB instead of Service engine 4) Integrate with Pluto for Portal server 5) use third party Content management I think Ofbiz community is more interested in solving business process problems instead of building cool framework. We can focus much more on business problems if we utilize third party framework technologies. Some of the frameworks have excellent support from IDE venders, great books are available to learn, existing pool of skilled developers and many more goodies that we all know. Open source ERP space is growing. We need to think fresh. Take a break, Plan for next 5 years, Set our goals. All other open source ERP/CRM applications are doing it. There is no corporation behind ofbiz so its community's responsibility. Put a plan together. Make it easy for people to contribute. I am sure there are tons of people in community who want to contribute but don't know how. I am worried because, After working on minilang, screen widgets, form widgets, service engine, entity engine for so long I almost forgot Java/J2EE skills set. What if Ofbiz does not remain as popular 5 years down the road, How am I going to pay for my daughters college expenses? This email is not intended to hurt anybody's feeling or scare anybody. Ofbiz is in great shape, I wanted to get people to speak up and help plan for future. Thanks and Regards Anil Patel smime.p7s Description: S/MIME cryptographic signature
Re: TrackingCode vs TrackingNumber
Joe, I agree with you 100%. When I think of tracking numbers I think of tracking shipments, when I think of tracking codes I think of tracking URLs and referrers, usually in some sort of marketing campaign. I think what you propose is to change this to be consistent. Consistency is always a good thing, and lack of consistency leads to confusion and incorrect implementations. I agree with this change. Keep in mind though, when changing this field, it will require and upgrade path. Keeping the old field and providing a way to migrate the old data to the new field. Just my two cents. Andrew On Oct 28, 2008, at 2:25 AM, Joe Eckard wrote: On Oct 27, 2008, at 4:08 PM, David E Jones wrote: To me this doesn't seem like enough of a reason to change the field name. Did you run into some big confusion between the terms "tracking code" and "tracking number"? In a way I don't like tracking number because most tracking "numbers" aren't really numbers, they include alpha letters and sometimes punctuation too. No, nothing like that - I just wasn't sure why we refer to this identifier as "trackingIdNumber" in the ShipmentRouteSegment entity, "trackingNumber" in the OrderItemShipGroup entity, and "trackingCode" in the ShipmentPackageRouteSeg entity. I think that all three are describing the same thing. Also, I agree that "tracking ID" would have been a better choice for everyone to somehow agree on, however... see below I must admit though that I've never run into anything like this sort of confusion or any sort of related conflict in terms. Is there something online somewhere that my be helpful for me, and others similarly uniformed (if there are any)? In all of the documentation / advertising / help sections / FAQs / confirmation emails, etc. I have read, this identifier is called a tracking number. If you google "tracking number", the first results are pages from the four main carriers that all refer to this identifier as a tracking number. If you look at the existing code in OFBiz, it is already referred to as a tracking number in most places, but mapped back to trackingCode for the package route segment. The Fedex and UPS APIs accept / return this identifier explicitly as TrackingNumber. Actually, it feels a little bizarre even stopping to write this - maybe because the term is just ingrained in my vocabulary, and I think I may be misreading some sarcasm? In any case, the reason I brought this up is that I am working on some code dealing with shipments, packages and tracking numbers and it seemed like a clear-cut, genuine naming inconsistency that should be corrected before any more code was written to follow it. -David On Oct 26, 2008, at 9:38 AM, Joe Eckard wrote: ShipmentPackageRouteSeg has a field called trackingCode which should really be trackingNumber (see: OrderItemShipGroup field "trackingNumber" & standard industry terminology). The field name "trackingCode" is used in the marketing entities and code to describe something completely different. I created a patch for this, and it touches quite a few files - are there any objections to this change? -Joe smime.p7s Description: S/MIME cryptographic signature
Re: list of developers
If you can get away with the apache.org email, the SVN ID is the same as the account name. Andrew On Oct 29, 2008, at 1:29 PM, Jacques Le Roux wrote: Maybe you can found more (only names, no emails) here looking for OFBiz http://people.apache.org/~jim/committers.html But I think OFBiz PMC page is up to date Jacques From: "Adam Heath" <[EMAIL PROTECTED]> David E Jones wrote: One of the standard administrative docs we maintain: http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+PMC+Members+and+Committers Yup, already found it, but it's not complete. It's missing email addresses, and Paul Querna is not listed. In any event, I found the above shortly after I sent that email. smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r762610 - in /ofbiz/trunk/framework: base/src/org/ofbiz/base/util/GroovyUtil.java base/src/org/ofbiz/base/util/string/FlexibleStringExpander.java example/config/ExampleUiLabels.xml exa
No problem. :) If there is a JIRA issue for this, please let me know.
I couldn't find it.
Andrew
On Apr 7, 2009, at 4:12 AM, Jacques Le Roux wrote:
Yes, thanks Andrew,
I wished to do it but I'm pretty happier you did :o)
Jacques
From: "Ashish Vijaywargiya"
Thanks Andrew.
--
Ashish
j...@apache.org wrote:
Author: jaz
Date: Tue Apr 7 03:17:31 2009
New Revision: 762610
URL: http://svn.apache.org/viewvc?rev=762610&view=rev
Log:
Added Groovy support to the FlexibleStringExpander; updated example
component to show usage
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/GroovyUtil.java
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/string/
FlexibleStringExpander.java
ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
ofbiz/trunk/framework/example/widget/example/
FormWidgetExampleForms.xml
Modified: ofbiz/trunk/framework/base/src/org/ofbiz/base/util/
GroovyUtil.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/GroovyUtil.java?rev=762610&r1=762609&r2=762610&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/util/
GroovyUtil.java (original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/util/
GroovyUtil.java Tue Apr 7 03:17:31 2009
@@ -33,6 +33,7 @@
import groovy.lang.Script;
import org.codehaus.groovy.control.CompilationFailedException;
import org.codehaus.groovy.runtime.InvokerHelper;
+import bsh.EvalError;
/**
* GroovyUtil - Groovy Utilities
@@ -61,6 +62,44 @@
return binding;
}
+/**
+ * Evaluate a Groovy condition or expression
+ * @param expression The expression to evaluate
+ * @param context The context to use in evaluation (re-written)
+ * @return Object The result of the evaluation
+ * @throws CompilationFailedException
+ */
+public static Object eval(String expression, MapObject> context) throws CompilationFailedException {
+Object o;
+if (expression == null || expression.equals("")) {
+Debug.logError("Groovy Evaluation error. Empty
expression", module);
+return null;
+}
+
+if (Debug.verboseOn())
+Debug.logVerbose("Evaluating -- " + expression, module);
+if (Debug.verboseOn())
+Debug.logVerbose("Using Context -- " + context, module);
+
+try {
+GroovyShell shell = new
GroovyShell(getBinding(context));+o =
shell.evaluate(expression);
+
+if (Debug.verboseOn())
+Debug.logVerbose("Evaluated to -- " + o, module);
+
+// read back the context info
+Binding binding = shell.getContext();
+context.putAll(binding.getVariables());
++} catch (CompilationFailedException e) {
+Debug.logError(e, "Groovy Evaluation error.", module);
+throw e;
+}
++return o;
+}
+
public static Object runScriptAtLocation(String location,
Map context) throws GeneralException {
try {
Class scriptClass = parsedScripts.get(location);
Modified: ofbiz/trunk/framework/base/src/org/ofbiz/base/util/string/
FlexibleStringExpander.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/string/FlexibleStringExpander.java?rev=762610&r1=762609&r2=762610&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/util/string/
FlexibleStringExpander.java (original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/util/string/
FlexibleStringExpander.java Tue Apr 7 03:17:31 2009
@@ -26,13 +26,9 @@
import java.util.Map;
import java.util.TimeZone;
-import org.ofbiz.base.util.BshUtil;
-import org.ofbiz.base.util.Debug;
-import org.ofbiz.base.util.ObjectType;
import org.ofbiz.base.util.cache.UtilCache;
-import org.ofbiz.base.util.UtilDateTime;
-import org.ofbiz.base.util.UtilFormatOut;
-import org.ofbiz.base.util.UtilMisc;
+import org.ofbiz.base.util.*;
+import org.codehaus.groovy.control.CompilationFailedException;
import bsh.EvalError;
@@ -230,9 +226,13 @@
// append everything from the current index to the
start of the var
strElems.add(new
ConstElem(original.substring(currentInd, start)));
}
-// check to see if this starts with a "bsh:", if so
treat the rest of the string as a bsh scriptlet
+
if (original.indexOf("bsh:", start + 2) == start + 2) {
+// checks to see if this starts with a "bsh:", if
so treat the rest of the string as a bsh scriptlet
strElems.add(new BshElem(original.substring(start +
6, end)));
+} else if (original.indexOf("groovy:", start + 2) ==
start + 2) {
+// checks to see if this starts with a "groovy:",
if so tr
Re: Adding description field(s) to the UserLogin entity
This could be a common term called displayName. I'm for it. Andrew On Apr 21, 2009, at 6:48 AM, Ashish Vijaywargiya wrote: Hello Jacopo, I hope you are doing good now a days. :-) I like the idea of adding a field in UserLogin table. But instead of Description or FirstName/ LastName pair I would prefer to add field by title "User Name". It will contain the First Name + Last Name or which ever name is provided from the console if we run ant create-admin-user target (we can add this option on the available ant target). And it will be Self Explanatory for readers I guess. Thoughts ? -- Ashish On Tue, Apr 21, 2009 at 4:00 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: What about adding field(s) to the UserLogin entity to describe the user login record? It could be just a "description" field, or maybe a "firstName"/"lastName" pair (all of them will be optional). The idea is that, in a framework only installation, you don't have the Party/Person entities, but you can create UserLogin records (with associated permissions) to interact with the system. It would be nice to have a mean to add some optional details to the UserLogin. What do you think? Jacopo smime.p7s Description: S/MIME cryptographic signature
Codes
I think this is due to the new HTML security, but now we have these " " codes floating all over the place. I'm not sure what the best solution for this is, but I thought I would check in a change like this: Index: config/CommonUiLabels.xml === --- config/CommonUiLabels.xml (revision 767649) +++ config/CommonUiLabels.xml (working copy) @@ -1997,7 +1997,7 @@ 电子邮件 - + شغال Any thoughts??? Andrew
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))
I don't know about this, what if I used my (or yours for that matter) email address as my userLoginId andrew.zene...@hotwaxmedia.com that is 31 right there. Its really tough to say how much space is needed for such a field. 100 might be enough, but it is the change worth it? My vote is no, but maybe you have a specific reason in mind for the suggestion? Andrew On Apr 22, 2009, at 12:19 AM, Ashish Vijaywargiya wrote: Hello, Yesterday I was reviewing few entities, then I realized that we are using "id-vlong" for the fields acting as foreign key & referring to the "userLoginId" of the UserLogin table. "id-vlong" = VARCHAR(255) is too much space for saving the userLoginId. At max I can think of userLoginId to be of length of 25 or 30. For ex. few reference are : createdByUserLogin field in MarketingCampaign entity. dontCancelSetUserLogin in OrderItem entity. If there is any specific reason for keeping it of this much length then please share your thoughts on this. Thanks in Advance. -- Ashish Vijaywargiya
Re: Codes
Well there is an option which might be viable. We could simply wrap all values in the uiLabelMap using StringUtil.wrapString(). This will allow HTML characters in the UI labels again and shouldn't be too much of a security risk, as only developers have access to these strings. Thoughts? Andrew On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote: I agree. We should look into the widget code and the label manager code to get these issues fixed properly. -Adrian Scott Gray wrote: That's probably something we can fix in the widget code isn't it? If the title attribute is missing then use the field name otherwise render whatever is specified in the title even if it is just an empty string. Regards Scott HotWax Media http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote: I think it is related to the situation where you want to specify an empty content for the "title" attribute in form widgets. if title element is missing or is set to title="" then the widgets render it with the name of the field or simialr. Jacopo On Apr 23, 2009, at 10:43 AM, Scott Gray wrote: I can't remember the reason for adding the CommonEmptyHeader label but I'm wondering if we should consider removing it and find another solution to whatever problem it solved? Regards Scott HotWax Media http://www.hotwaxmedia.com On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote: Hi Andrew, From: "Andrew Zeneski" mailto:andrew.zene...@hotwaxmedia.com >> I think this is due to the new HTML security, but now we have these " " codes floating all over the place. I'm not sure what the best solution for this is, but I thought I would check in a change like this: This is not as simple. I agree it's a quick fix for the issue at hand. But this is due to Labels Manager. If you put a sole space (ie > < ) then if you do some modifications with Labels Manager in this file and then save in the file you will get In order to cope with this I tried to write directly at SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String " " which should be ok. But I guess I would have to change the format passed to UtilXml.writeXmlDocument some lines below since else it write " " and not " " as intended. Not sure it's possible though. And I have no time to look at it right now. So I made the change you proposed at r767845 and r767848 for R9.04 And we will have to deal with that in a complete way since else we will find an even worst trouble later (as soon someone will use Labels Manager to save changes in this file) Jacques I had some zele here (ok not only here ;o) Index: config/CommonUiLabels.xml = = = --- config/CommonUiLabels.xml (revision 767649) +++ config/CommonUiLabels.xml (working copy) @@ -1997,7 +1997,7 @@ 电子邮件 -  + شغال Any thoughts??? Andrew
Re: Proposal to change name of two entities in Portal
+1 to David's -1 :) I totally agree with these points, to me the name change is very minor and not worth the pain which it will cause. Andrew On Apr 23, 2009, at 1:39 PM, David E Jones wrote: -1. In fact, a big huge -1. I don't think those names make it easier to understand but rather more difficult, and then they are also not grouped so well in the entity data maintenance and other webtools pages, etc. If this was a case where the names were misleading or plain wrong then we might consider it. However, changing entities names causes lots of problems, and results in a database change that is not backwards-compatible, which also means people upgrading OFBiz will have to shut down their entire system in order to update past such a revision. So no, I don't think this even comes close to being enough of an improvement to be worth it. -David On Apr 23, 2009, at 4:28 AM, Vikas Mayur wrote: Hi, I would like to propose change in name of the following entities in Portal. This would also result in changing the name of few keys. PortalPortlet --> Portlet (since this is just about a portlet) PortletPortletCategory --> PortletCategoryMember (as in ProductCategoryMember) IMO, they are more logical and clear names. I will open a jira issues if no body see any objections. Vikas
Re: Codes
Here is a patch which does exactly this, and appears to work with just a little testing. I'm just not sure of the total impact it will cause. On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote: Well there is an option which might be viable. We could simply wrap all values in the uiLabelMap using StringUtil.wrapString(). This will allow HTML characters in the UI labels again and shouldn't be too much of a security risk, as only developers have access to these strings. Thoughts? Andrew On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote: I agree. We should look into the widget code and the label manager code to get these issues fixed properly. -Adrian Scott Gray wrote: That's probably something we can fix in the widget code isn't it? If the title attribute is missing then use the field name otherwise render whatever is specified in the title even if it is just an empty string. Regards Scott HotWax Media http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote: I think it is related to the situation where you want to specify an empty content for the "title" attribute in form widgets. if title element is missing or is set to title="" then the widgets render it with the name of the field or simialr. Jacopo On Apr 23, 2009, at 10:43 AM, Scott Gray wrote: I can't remember the reason for adding the CommonEmptyHeader label but I'm wondering if we should consider removing it and find another solution to whatever problem it solved? Regards Scott HotWax Media http://www.hotwaxmedia.com On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote: Hi Andrew, From: "Andrew Zeneski" mailto:andrew.zene...@hotwaxmedia.com >> I think this is due to the new HTML security, but now we have these " " codes floating all over the place. I'm not sure what the best solution for this is, but I thought I would check in a change like this: This is not as simple. I agree it's a quick fix for the issue at hand. But this is due to Labels Manager. If you put a sole space (ie > < ) then if you do some modifications with Labels Manager in this file and then save in the file you will get In order to cope with this I tried to write directly at SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String " " which should be ok. But I guess I would have to change the format passed to UtilXml.writeXmlDocument some lines below since else it write " " and not " " as intended. Not sure it's possible though. And I have no time to look at it right now. So I made the change you proposed at r767845 and r767848 for R9.04 And we will have to deal with that in a complete way since else we will find an even worst trouble later (as soon someone will use Labels Manager to save changes in this file) Jacques I had some zele here (ok not only here ;o) Index: config/CommonUiLabels.xml = = = --- config/CommonUiLabels.xml (revision 767649) +++ config/CommonUiLabels.xml (working copy) @@ -1997,7 +1997,7 @@ 电子邮件 -  + شغال Any thoughts??? Andrew
Re: Codes
FYI the patch is here, not in the email... https://issues.apache.org/jira/browse/OFBIZ-2349 Andrew On Apr 23, 2009, at 2:12 PM, Andrew Zeneski wrote: Here is a patch which does exactly this, and appears to work with just a little testing. I'm just not sure of the total impact it will cause. On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote: Well there is an option which might be viable. We could simply wrap all values in the uiLabelMap using StringUtil.wrapString(). This will allow HTML characters in the UI labels again and shouldn't be too much of a security risk, as only developers have access to these strings. Thoughts? Andrew On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote: I agree. We should look into the widget code and the label manager code to get these issues fixed properly. -Adrian Scott Gray wrote: That's probably something we can fix in the widget code isn't it? If the title attribute is missing then use the field name otherwise render whatever is specified in the title even if it is just an empty string. Regards Scott HotWax Media http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote: I think it is related to the situation where you want to specify an empty content for the "title" attribute in form widgets. if title element is missing or is set to title="" then the widgets render it with the name of the field or simialr. Jacopo On Apr 23, 2009, at 10:43 AM, Scott Gray wrote: I can't remember the reason for adding the CommonEmptyHeader label but I'm wondering if we should consider removing it and find another solution to whatever problem it solved? Regards Scott HotWax Media http://www.hotwaxmedia.com On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote: Hi Andrew, From: "Andrew Zeneski" mailto:andrew.zene...@hotwaxmedia.com >> I think this is due to the new HTML security, but now we have these " " codes floating all over the place. I'm not sure what the best solution for this is, but I thought I would check in a change like this: This is not as simple. I agree it's a quick fix for the issue at hand. But this is due to Labels Manager. If you put a sole space (ie > < ) then if you do some modifications with Labels Manager in this file and then save in the file you will get In order to cope with this I tried to write directly at SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String " " which should be ok. But I guess I would have to change the format passed to UtilXml.writeXmlDocument some lines below since else it write " " and not " " as intended. Not sure it's possible though. And I have no time to look at it right now. So I made the change you proposed at r767845 and r767848 for R9.04 And we will have to deal with that in a complete way since else we will find an even worst trouble later (as soon someone will use Labels Manager to save changes in this file) Jacques I had some zele here (ok not only here ;o) Index: config/CommonUiLabels.xml = = = = === --- config/CommonUiLabels.xml (revision 767649) +++ config/CommonUiLabels.xml (working copy) @@ -1997,7 +1997,7 @@ 电子邮件 -  + شغال Any thoughts??? Andrew
Re: Codes
Fair enough, then in this case this specific field CommonEmptyHeader should be just a single space. The label manager should define its own special label which is not used anywhere else. Andrew On Apr 23, 2009, at 2:42 PM, David E Jones wrote: Yes, one of the "guidelines" (or maybe a better term is best practice) is to not have HTML in translation labels. There are a few reasons for this that have come up over time: 1. ability to use labels in non-webapp contexts 2. be able to externally format/style the labels, perhaps differently in different places 3. avoid HTML in labels interfering with other HTML/CSS in the page Anyway, there was an effort a while back to remove HTML from the labels for some of these reasons, and when doing the output encoding it seemed best to encode all characters from labels to encourage this practice. -David On Apr 23, 2009, at 12:28 PM, Adrian Crum wrote: Why would we want to put HTML in the UI labels? -Adrian Andrew Zeneski wrote: Here is a patch which does exactly this, and appears to work with just a little testing. I'm just not sure of the total impact it will cause. On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote: Well there is an option which might be viable. We could simply wrap all values in the uiLabelMap using StringUtil.wrapString(). This will allow HTML characters in the UI labels again and shouldn't be too much of a security risk, as only developers have access to these strings. Thoughts? Andrew On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote: I agree. We should look into the widget code and the label manager code to get these issues fixed properly. -Adrian Scott Gray wrote: That's probably something we can fix in the widget code isn't it? If the title attribute is missing then use the field name otherwise render whatever is specified in the title even if it is just an empty string. Regards Scott HotWax Media http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote: I think it is related to the situation where you want to specify an empty content for the "title" attribute in form widgets. if title element is missing or is set to title="" then the widgets render it with the name of the field or simialr. Jacopo On Apr 23, 2009, at 10:43 AM, Scott Gray wrote: I can't remember the reason for adding the CommonEmptyHeader label but I'm wondering if we should consider removing it and find another solution to whatever problem it solved? Regards Scott HotWax Media http://www.hotwaxmedia.com On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote: Hi Andrew, From: "Andrew Zeneski" mailto:andrew.zene...@hotwaxmedia.com >> I think this is due to the new HTML security, but now we have these " " codes floating all over the place. I'm not sure what the best solution for this is, but I thought I would check in a change like this: This is not as simple. I agree it's a quick fix for the issue at hand. But this is due to Labels Manager. If you put a sole space (ie > < ) then if you do some modifications with Labels Manager in this file and then save in the file you will get In order to cope with this I tried to write directly at SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String " " which should be ok. But I guess I would have to change the format passed to UtilXml.writeXmlDocument some lines below since else it write " " and not " " as intended. Not sure it's possible though. And I have no time to look at it right now. So I made the change you proposed at r767845 and r767848 for R9.04 And we will have to deal with that in a complete way since else we will find an even worst trouble later (as soon someone will use Labels Manager to save changes in this file) Jacques I had some zele here (ok not only here ;o) Index: config/CommonUiLabels.xml = = = = = = = --- config/CommonUiLabels.xml (revision 767649) +++ config/CommonUiLabels.xml (working copy) @@ -1997,7 +1997,7 @@ 电子邮件 -  + شغال Any thoughts??? Andrew
Re: svn commit: r769991 - /ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/test/AuthorizationTests.java
Thanks Adrian,
I had actually changed SecurityConfigurationException to extend
GeneralRuntimeException instead of GeneralException, but that didn't
get checked in.
Andrew
On Apr 29, 2009, at 7:18 PM, adri...@apache.org wrote:
Author: adrianc
Date: Wed Apr 29 23:18:24 2009
New Revision: 769991
URL: http://svn.apache.org/viewvc?rev=769991&view=rev
Log:
Fixed a problem with the new auth code that was preventing
compilation.
Modified:
ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/
test/AuthorizationTests.java
Modified: ofbiz/trunk/applications/securityext/src/org/ofbiz/
securityext/test/AuthorizationTests.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/test/AuthorizationTests.java?rev=769991&r1=769990&r2=769991&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/
test/AuthorizationTests.java (original)
+++ ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/
test/AuthorizationTests.java Wed Apr 29 23:18:24 2009
@@ -2,6 +2,7 @@
import org.ofbiz.base.util.Debug;
import org.ofbiz.entity.GenericDelegator;
+import org.ofbiz.security.SecurityConfigurationException;
import org.ofbiz.security.authz.Authorization;
import org.ofbiz.security.authz.AuthorizationFactory;
import org.ofbiz.service.testtools.OFBizTestCase;
@@ -12,7 +13,7 @@
protected GenericDelegator delegator;
protected Authorization security;
-public AuthorizationTests(String name) {
+public AuthorizationTests(String name) throws
SecurityConfigurationException {
super(name);
delegator = GenericDelegator.getGenericDelegator("default");
security = AuthorizationFactory.getInstance(delegator);
Re: svn commit: r769991 - /ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/test/AuthorizationTests.java
What a wonderful idea... ;) Yeah of course I do that, in this case I
just didn't check in the changes to the exception class. I have the
old security deprecated locally and decided last minute to wait to
check that in to prevent build warnings for now.
Andrew
On Apr 30, 2009, at 1:40 AM, Adrian Crum wrote:
No problem. One thing I do is run ant clean then ant build before
committing changes - just to make sure there are no problems.
-Adrian
--- On Wed, 4/29/09, Andrew Zeneski
wrote:
From: Andrew Zeneski
Subject: Re: svn commit: r769991 - /ofbiz/trunk/applications/
securityext/src/org/ofbiz/securityext/test/AuthorizationTests.java
To: dev@ofbiz.apache.org
Date: Wednesday, April 29, 2009, 6:51 PM
Thanks Adrian,
I had actually changed SecurityConfigurationException to
extend GeneralRuntimeException instead of GeneralException,
but that didn't get checked in.
Andrew
On Apr 29, 2009, at 7:18 PM, adri...@apache.org wrote:
Author: adrianc
Date: Wed Apr 29 23:18:24 2009
New Revision: 769991
URL:
http://svn.apache.org/viewvc?rev=769991&view=rev
Log:
Fixed a problem with the new auth code that was
preventing compilation.
Modified:
ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/test/
AuthorizationTests.java
Modified:
ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/test/
AuthorizationTests.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/test/AuthorizationTests.java?rev=769991&r1=769990&r2=769991&view=diff
=
=
=
=
=
=
=
=
=
=
---
ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/test/
AuthorizationTests.java
(original)
+++
ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/test/
AuthorizationTests.java
Wed Apr 29 23:18:24 2009
@@ -2,6 +2,7 @@
import org.ofbiz.base.util.Debug;
import org.ofbiz.entity.GenericDelegator;
+import
org.ofbiz.security.SecurityConfigurationException;
import org.ofbiz.security.authz.Authorization;
import org.ofbiz.security.authz.AuthorizationFactory;
import org.ofbiz.service.testtools.OFBizTestCase;
@@ -12,7 +13,7 @@
protected GenericDelegator delegator;
protected Authorization security;
-public AuthorizationTests(String name) {
+public AuthorizationTests(String name) throws
SecurityConfigurationException {
super(name);
delegator =
GenericDelegator.getGenericDelegator("default");
security =
AuthorizationFactory.getInstance(delegator);
Re: Adding description field(s) to the UserLogin entity
displayName is a common field used in LDAP systems. Which is really the only reason I suggested it. Usually its the first/last name together but its totally arbitrary. On Apr 30, 2009, at 1:55 AM, awdesh parihar wrote: Hi +1 for name suggested by jacques , we can also go we displayUserName. -- -- Awdesh Parihar
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Inline... On Apr 30, 2009, at 12:11 PM, David E Jones wrote: What is the point of changing all of the security data like this? In other words, is there some reason that the new security stuff can't use the same permissions syntax/convention as the older security stuff? Looks like you probably missed the big design document which explains everything: http://docs.ofbiz.org/x/-B0 http://docs.ofbiz.org/x/JR4 The thing to keep in mind is that not only will there be a big effort to make all of these changes in OFBiz, but everyone with production data will have to perform a big non-backward-compatible database migration that will require system downtime. Yes, it will be a big effort, but it is something I plan to tackle as quickly as possible. As for non-backward-compatible database changes, I totally disagree. As long as the new seed data is loaded, nothing else is required (except some minor DB schema changes, all adds, no deletes) I was very careful when designing this to avoid this completely. There is no reason why old permission data and new permission data cannot live together in the database. It will hurt nothing. Also, it should be fairly easy to write a simple migration script to remove the old permissions; but that could get tricky when there are custom applications or code which doesn't get migrated in this effort. It is certainly okay to require that if there is a good reason for it, but I guess that's what I'm not seeing here... the benefits we all get from the new format... Instead of me explaining this over and over (which is what I figured would happen) I put everything together in a document in confluence and linked that to all the JIRA issues. My guess is after you read that doc, you will completely understand the importance of the permission format changes which is really what prompted the entire effort. I'd be happy to discuss additional changes as well (which aren't yet documented) like adding support to check multiple permissions at once, returning a Map of results from that permission check. So, if you or anyone else has a wish list for security, let me know so I can get it all incorporated at the same time. Andrew
Re: Adding description field(s) to the UserLogin entity
Our Crowd server uses displayName (as well as sn, givenName and mail) but that is probably because it is backed by LDAP. Display name gets auto populated with First/Last name, but is editable. userName sounds too much like a string to use for login, where displayName would mean the name to display in the system. If we add this field, we should edit createPersonAndUserLogin server to set the value to First/Last if its empty as well. Then use this field in the header instead of the party fields. Andrew On Apr 30, 2009, at 3:20 AM, Jacques Le Roux wrote: That seems a good reason, what is used in Crowd ? I suggested userName because it's related to userLogin. What about displayUserName ? Jacques From: "Adrian Crum" displayName is used in LDAP? Sweet! In that case... +1 for displayName -Adrian --- On Wed, 4/29/09, Andrew Zeneski wrote: From: Andrew Zeneski Subject: Re: Adding description field(s) to the UserLogin entity To: dev@ofbiz.apache.org Date: Wednesday, April 29, 2009, 10:59 PM displayName is a common field used in LDAP systems. Which is really the only reason I suggested it. Usually its the first/last name together but its totally arbitrary. On Apr 30, 2009, at 1:55 AM, awdesh parihar wrote: > Hi > > +1 for name suggested by jacques , we can also go we displayUserName. > > Awdesh Parihar
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
That sounds cool. I'm not sure what that would really look like, but nevertheless sounds really cool! :) If you need anything from me let me know... Andrew On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote: Andrew Zeneski wrote: I'd be happy to discuss additional changes as well (which aren't yet documented) like adding support to check multiple permissions at once, returning a Map of results from that permission check. So, if you or anyone else has a wish list for security, let me know so I can get it all incorporated at the same time. Btw, I'm working on adding an extension to the UEL that will allow permission expressions. -Adrian
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
No problem, I thought I posted this to the dev list last week, I wonder where I sent it... On Apr 30, 2009, at 2:28 PM, Jacques Le Roux wrote: From: "Andrew Zeneski" Looks like you probably missed the big design document which explains everything: http://docs.ofbiz.org/x/-B0 http://docs.ofbiz.org/x/JR4 Great stuff, thanks Andrew! Jacques
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Not really, I just implemented what we were talking about offline, its called findMatchingPermissions(). So, now you can check "(read|update| delete):party:1" and it will return you a map containing : read:party:1 = (true|false) update:party:1 = (true|false) delete:party:1 = (true|false) This will only work for the base permissions (access, create, read, update, delete) but it should be helpful. On Apr 30, 2009, at 2:15 PM, Adrian Crum wrote: I'm even hesitant about making this permission extension. I would rather see the security component handle permission expressions, but that would require a lot of coding.
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
I think this is a great idea and would be very useful. Could you
create a JIRA issue for this and relate it to OFBIZ-2380?
Andrew
On Apr 30, 2009, at 1:07 PM, Jacopo Cappellato wrote:
On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
... I'd be happy to discuss additional changes as well (which
aren't yet documented) like adding support to check multiple
permissions at once, returning a Map of results from that
permission check. So, if you or anyone else has a wish list for
security, let me know so I can get it all incorporated at the same
time.
Andrew
this is probably off topic here, but an enhancement I would like to
see in the form widgets is the ability for the widget model/renderer
to automatically select the proper field type according to the
permissions of the user: this is something that can be already done
using some scriptlets and the use-when attributes but it is pretty
complex.
I don't have a clear idea at the moment but the first options that I
can think of are:
1) a new field type "display-update": it will be "display" if the
user has view permissions; it will be "update" if the user has write
permissions
2) add, a required-permission attribute to the field element: this
will act as the use-when permission; or maybe adding something like
use-when="${ofbiz:hasPermission(UPDATE)}"
3) submit buttons will be disabled if the user doesn't have proper
permissions
4) base/default permissions could be set as an attribute in the form
element or derived from the service (if auto-fields is used)
Just my two cents
Jacopo
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
I'm trying to come up with a use case where this sort of logic would be applicable, but I just cannot think of any. I can think of cases where we will conditionally want to check a single permission but OR/ AND permissions together for a UI element? When displaying a list of items, I might add a link to an update form, in which I would only show the link if update permission available. Same with delete, but I wouldn't check these in the same place, rather with each link. Also, I might use for read only users instead of text boxes (I really like Jacopo's use-when idea). But when would I really ever want to check them in an AND/OR fashion? Keeping in mind now, that the permission system handles granularity, as long as we are intelligent when defining permissions I believe a single permissions should be able to handle most cases. With the exception of UIs where we would want to display different things based on a different base permission, even then a single call using the new findMatchingPermissions() would totally do the trick. Andrew On Apr 30, 2009, at 7:43 PM, Adrian Crum wrote: I like that idea. Less chance that an unintended conversion would occur. -Adrian Scott Gray wrote: FYI and I only realized this the other day but beanshell supports exactly this type of feature where you can specify things @and, @or and etc. for use in xml files http://www.beanshell.org/manual/syntax.html#Document_Friendly_Entities I wonder if we do this it might be worth following the same convention. Regards Scott HotWax Media http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/> On 1/05/2009, at 5:34 AM, Jacopo Cappellato wrote: Adrian, this is really interesting. However I think it is time to start thinking to define our own xml friendly keywords for && and || operators; I would like to express that statement with something like this: Jacopo On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote: or something like that. I'm still working out the details. -Adrian Andrew Zeneski wrote: That sounds cool. I'm not sure what that would really look like, but nevertheless sounds really cool! :) If you need anything from me let me know... Andrew On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote: Andrew Zeneski wrote: I'd be happy to discuss additional changes as well (which aren't yet documented) like adding support to check multiple permissions at once, returning a Map of results from that permission check. So, if you or anyone else has a wish list for security, let me know so I can get it all incorporated at the same time. Btw, I'm working on adding an extension to the UEL that will allow permission expressions. -Adrian
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Adrian, I will start a new thread to discuss this, but before I do I want to make sure there isn't something I neglected to account for. Could you please provide an example of such a service which uses SECA permission services? Andrew On May 1, 2009, at 12:04 PM, Adrian Crum wrote: Andrew, I thought we were getting away from using the element and using the element instead. If this type of change is made in other components, it will break a lot of code - because some components use permission service SECAs. -Adrian j...@apache.org wrote: Author: jaz Date: Thu Apr 30 06:23:18 2009 New Revision: 770084 URL: http://svn.apache.org/viewvc?rev=770084&view=rev Log: Refactored Example Application to use new security mechanics - JIRA OFBIZ-2392 ... Modified: ofbiz/trunk/framework/example/servicedef/services.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/servicedef/services.xml?rev=770084&r1=770083&r2=770084&view=diff = = = = = = = = = = --- ofbiz/trunk/framework/example/servicedef/services.xml (original) +++ ofbiz/trunk/framework/example/servicedef/services.xml Thu Apr 30 06:23:18 2009 @@ -27,29 +27,37 @@ engine="entity-auto" invoke="create" auth="true"> Create a Example -name="exampleGenericPermission" main-action="CREATE"/> + + + include="pk" mode="OUT" optional="false"/> - +> engine="entity-auto" invoke="update" auth="true"> Update a Example -name="exampleGenericPermission" main-action="UPDATE"/> + + + optional="false"/> engine="entity-auto" invoke="delete" auth="true"> Delete a Example -name="exampleGenericPermission" main-action="DELETE"/> + + + name="ExampleStatus" engine="simple" location="component://example/script/org/ofbiz/example/ example/ExampleServices.xml" invoke="createExampleStatus" auth="true"> Create a ExampleStatus -name="exampleGenericPermission" main-action="CREATE"/> + + + @@ -58,7 +66,9 @@ name="ExampleItem" engine="entity-auto" invoke="create" auth="true"> Create a ExampleItem -name="exampleGenericPermission" main-action="CREATE"/> + + + @@ -66,60 +76,78 @@ name="ExampleItem" engine="entity-auto" invoke="update" auth="true"> Update a ExampleItem -name="exampleGenericPermission" main-action="UPDATE"/> + + + name="ExampleItem" engine="entity-auto" invoke="delete" auth="true"> Delete a ExampleItem -name="exampleGenericPermission" main-action="DELETE"/> + + + name="ExampleFeature" engine="entity-auto" invoke="create" auth="true"> Create a ExampleFeature -name="exampleGenericPermission" main-action="CREATE"/> + + + name="ExampleFeature" engine="entity-auto" invoke="update" auth="true"> Update a ExampleFeature -name="exampleGenericPermission" main-action="UPDATE"/> + + + name="ExampleFeature" engine="entity-auto" invoke="delete" auth="true"> Delete a ExampleFeature -name="exampleGenericPermission" main-action="DELETE"/> + + + name="ExampleFeatureAppl" engine="entity-auto" invoke="create" auth="true"> Create a ExampleFeatureAppl -name="exampleGenericPermission" main-action="CREATE"/> + + + name="ExampleFeatureAppl" engine="entity-auto" invoke="update" auth="true"> Update a ExampleFeatureAppl -name="exampleGenericPermission" main-action="UPDATE"/> + + + name="ExampleFeatureAppl" engine="entity-auto" invoke="delete" auth="true"> Delete a ExampleFeatureAppl -name="exampleGenericPermission" main-action="DELETE"/> + + + +
Authz API Discussion (was re: svn commit: r770084)
I'd like to move the discussion of the new Authz security implementation to this thread. To start off the discussion I will briefly describe what I would like to propose as the NEW best practices. 1. Single point of contact for ALL security checks, instead of having security embedded in functionality, or tied to services directly, the API should be the governor of all security. This means no more writing security logic in the functionality, and no more permission services attached directly to functionality (services or ecas). This is a bad design IMHO because it spreads the permission logic around in multiple places and makes it impossible to get the same results when checking permissions from different framework tools. -- We want to be consistent, and be able to obtain the same information from the UI or screen/form as we would get from a service call. -- Main point of contact is the Authorization interface. 2. Permission services become Dynamic Access (DA). Now instead of having permission services attached to services, we have Dynamic Access implementations which can be a compiled Java object, a Groovy script or a Service. My personal preference here is the Groovy script, but the API current supports all three. This DA logic is attached to a permission instead of a service. -- This allows for extending or changing the permission logic for a specific implementation/customization/application much easier. Since the DAs are all data driven, changing the seed data you can change the logic which is used. This means you no longer have to customize the services or logic in OFBiz to change the way authorization is handled for your company (or client); one less thing to worry about when merging customizations with the open source project. -- for groovy use "component://path/to/script.groovy" in the dynamicAccess field on SecurityPermission. -- for services use "service:serviceName" in the dynamicAccess field on SecurityPermission -- for objects use "org.ofbiz.path.to.Object (which implements DynamicAccess)" in the dynamicAccess field on SecurityPermission 3. Avoid having to check multiple permissions, for example PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission format which embeds all permissions which will be accepted: Example: update:party:contact:1 - Update the contact information for party 1 This will allow anyone who has: "update" or "update:party" or "update:party:contact" or is granted record level access by the DA logic. 4. Define permission for users, not admins. Instead of looking for a static permission, set the permission to be checked at the most granular level. When doing so, admin users will always have permission and the API will handle user access using DA logic. -- see: http://docs.ofbiz.org/x/JR4 That's enough to get started, http://docs.ofbiz.org/x/-B0 contains a lot more details; interested parties are encouraged to read it through. Andrew
PartyRelationship
The PartyRelationship entity always confuses me, and some of the demo data makes it even more confusing. I see it going many ways. My understanding of it is: "partyIdTo" in the role of "roleTypeIdTo" is a "partyRelationshipTypeId" of "partyIdFrom" in the role of "roleTypeIdFrom" In the case where we have a group, say Company and a user "100" who is an employee: "100" in the role of "EMPLOYEE" is a "EMPLOYMENT" of "Company" in the role of "ORGANIZATION_ROLE" we could also say: "100" in the role of "EMPLOYEE" is a "GROUP_ROLLUP" of "Company" in the role of "ORGANIZATION_ROLE" What about a prospective contact association? Contact's ID is 200. I would say this: "200" in the role of "PROSPECT" is a "CONTACT_REL" of "100" in the role of "_NA_" In both of these cases, the MEMBER is the TO and the CONTAINER is the FROM. Is this everyone else's understanding as well?? Andrew
Re: Authz API Discussion (was re: svn commit: r770084)
After reviewing the Asset Maintenance component's method of overriding security, I understand the concern from Adrian in the other thread. This is something I left off the email below so I thought I would amend it now. While this is a really creative workaround for the limitations in the current security implementation, it is by no means an ideal solution. It is even more logic spread out in even more places making understanding and customizing authorization even more cumbersome. For these exact situations, the auto-grant functionality was implemented. So, instead of using ECAs to override permissions, you would define seed data (in the Asset Maint component, SFA, etc) which define which permissions are granted when a user is granted a specific application permission. There is a Use Case defined in the document (http://docs.ofbiz.org/x/- B0) which explains how this would work for the SFA application. Just for the record, nothing will break. The two frameworks can live side by side during the migration process. It is my plan to knock this out as quickly as possible, one application at a time. Also, I believe HWM is going to help by providing some resources to assist in the effort. Andrew On May 1, 2009, at 1:36 PM, Andrew Zeneski wrote: I'd like to move the discussion of the new Authz security implementation to this thread. To start off the discussion I will briefly describe what I would like to propose as the NEW best practices. 1. Single point of contact for ALL security checks, instead of having security embedded in functionality, or tied to services directly, the API should be the governor of all security. This means no more writing security logic in the functionality, and no more permission services attached directly to functionality (services or ecas). This is a bad design IMHO because it spreads the permission logic around in multiple places and makes it impossible to get the same results when checking permissions from different framework tools. -- We want to be consistent, and be able to obtain the same information from the UI or screen/form as we would get from a service call. -- Main point of contact is the Authorization interface. 2. Permission services become Dynamic Access (DA). Now instead of having permission services attached to services, we have Dynamic Access implementations which can be a compiled Java object, a Groovy script or a Service. My personal preference here is the Groovy script, but the API current supports all three. This DA logic is attached to a permission instead of a service. -- This allows for extending or changing the permission logic for a specific implementation/customization/application much easier. Since the DAs are all data driven, changing the seed data you can change the logic which is used. This means you no longer have to customize the services or logic in OFBiz to change the way authorization is handled for your company (or client); one less thing to worry about when merging customizations with the open source project. -- for groovy use "component://path/to/script.groovy" in the dynamicAccess field on SecurityPermission. -- for services use "service:serviceName" in the dynamicAccess field on SecurityPermission -- for objects use "org.ofbiz.path.to.Object (which implements DynamicAccess)" in the dynamicAccess field on SecurityPermission 3. Avoid having to check multiple permissions, for example PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission format which embeds all permissions which will be accepted: Example: update:party:contact:1 - Update the contact information for party 1 This will allow anyone who has: "update" or "update:party" or "update:party:contact" or is granted record level access by the DA logic. 4. Define permission for users, not admins. Instead of looking for a static permission, set the permission to be checked at the most granular level. When doing so, admin users will always have permission and the API will handle user access using DA logic. -- see: http://docs.ofbiz.org/x/JR4 That's enough to get started, http://docs.ofbiz.org/x/-B0 contains a lot more details; interested parties are encouraged to read it through. Andrew
Re: svn commit: r770771 - in /ofbiz/trunk: applications/securityext/src/org/ofbiz/securityext/test/ framework/security/src/org/ofbiz/security/authz/ framework/webapp/src/org/ofbiz/webapp/control/
Yeah I'm game for a more definite fix. But what about app server threads? Andrew On May 1, 2009, at 2:42 PM, Adam Heath wrote: j...@apache.org wrote: Author: jaz Date: Fri May 1 17:47:52 2009 New Revision: 770771 URL: http://svn.apache.org/viewvc?rev=770771&view=rev Log: Often thread pools do not clear ThreadLocal, implemented a workaround to handle this Actually, never, until the Thread is shutdown. ThreadLocal is just for storing stuff against a thread-type key. What you want is a PoolThreadLocal, which doesn't exist. I guess I could add code to support the same thing that webslinger does for this case. It would require modifying ControlServlet, JobPoller, and any other pool-like container class, to add a hook to run an AtExit list of hooks. Then, add a utility class that allows for singleton per-thread calls, and at-exit calls when the pool returns the thread for further processing. If this sounds confusing, it's that it's difficult for me to explain, and would just be easier if I add the feature(or otherwise show the code).
ThreadLocal (was re: svn commit: r770771)
Adam, Another option which might be better/easier/less intrusive (or very similar) is to create an single place for storing thread local variables. Like an OFBizThreadLocal class, which extends ThreadLocal. Keep all the variables inside this class, then just tie in ContextFilter (after the final chain.doFilter() call) and in the JobInvoker class calls to OFBizThreadLocal.clear(). What do you think about that? Andrew On May 1, 2009, at 3:00 PM, andrew.zene...@hotwaxmedia.com wrote: Yeah I'm game for a more definite fix. But what about app server threads? Andrew On May 1, 2009, at 2:42 PM, Adam Heath wrote: j...@apache.org wrote: Author: jaz Date: Fri May 1 17:47:52 2009 New Revision: 770771 URL: http://svn.apache.org/viewvc?rev=770771&view=rev Log: Often thread pools do not clear ThreadLocal, implemented a workaround to handle this Actually, never, until the Thread is shutdown. ThreadLocal is just for storing stuff against a thread-type key. What you want is a PoolThreadLocal, which doesn't exist. I guess I could add code to support the same thing that webslinger does for this case. It would require modifying ControlServlet, JobPoller, and any other pool-like container class, to add a hook to run an AtExit list of hooks. Then, add a utility class that allows for singleton per-thread calls, and at-exit calls when the pool returns the thread for further processing. If this sounds confusing, it's that it's difficult for me to explain, and would just be easier if I add the feature(or otherwise show the code).
Re: PartyRelationship
Yeah, cool. My main concern was to make sure I (and anyone else for that matter) understands the definition of the TOs vs FROMs. :) On May 1, 2009, at 4:44 PM, Adrian Crum wrote: --- On Fri, 5/1/09, Andrew Zeneski wrote: we could also say: "100" in the role of "EMPLOYEE" is a "GROUP_ROLLUP" of "Company" in the role of "ORGANIZATION_ROLE" or "100 in the role of "SALES_REP" is a "EMPLOYEE" of "Company" in the role of "EMPLOYER" More than likely the employee will also have the EMPLOYEE role, I'm just illustrating another way of looking at it. -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Don't worry, I expected some level of resistance to a change of this magnitude, plus this requires a very different way of thinking so I planned on having to explain it, I tried to cover everything in the document, but that's impossible to do :) This is VERY similar to the existing security implementation, and very similar to other security APIs out there (JSecurity, Spring Security, etc). The slight differences are: Easier to understand and follow. Reading the new permission string format, you can see what is being checked. Nothing is hidden. The logic used to determine granular access control it defined on the permission itself. No more guessing where permission logic is located. It is much easier to extend, create seed data which overwrites the default permission logic references and use your own custom logic to determine access. No need to override service definitions or patch code (well once the migration is complete) or comment out ECAs. So, now my questions for you are: What is missing? What does this new API NOT do, which you are looking for? Andrew On May 1, 2009, at 4:37 PM, Adrian Crum wrote: I read the Auto-Grant section. The question is, where is the seed data shown in your code example located? If it's it the SFA component, then the permissions are still spread around. All that has changed is instead of having permission-modifying SECAs in components, you have permission-modifying seed data in components. How was anything "centralized?" I don't mean to pour cold water on your enthusiasm, it's just that I don't see where anything is being added or improved. It looks basically the same, only slightly different. -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
On May 1, 2009, at 4:23 PM, Adrian Crum wrote:
--- On Fri, 5/1/09, Andrew Zeneski
wrote:
From: Andrew Zeneski
Subject: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 10:36 AM
1. Single point of contact for ALL security checks, instead
of having security embedded in functionality, or tied to
services directly, the API should be the governor of all
security. This means no more writing security logic in the
functionality, and no more permission services attached
directly to functionality (services or ecas). This is a bad
design IMHO because it spreads the permission logic around
in multiple places and makes it impossible to get the same
results when checking permissions from different framework
tools.
I don't understand what this means. Looking at the changes you made
in the Example component, you still have permissions tied to the
service definitions. Then you have permissions being checked in the
screen widgets. From my perspective, nothing changed except the
format of the permission string. Where is the "single point of
contact" in the Example component?
What changed is that now the permission logic is NOT tied directly to
the service itself. The logic is tied to the permission. So ANY call
to authz.hasPermission() the EXACT same code runs that checks the
permission. That is the single point of contact, the hasPermission()
method.
The checks in the screen definition runs the same code as the checks
in service definition. So now one advantage is, the update or delete
button which is displayed in the UI if the user has permission will
display (even if they do not have the static permission associated
with their account) if the user can edit that specific item. It won't
display for other items which the user cannot modify.
3. Avoid having to check multiple permissions, for example
PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new
permission format which embeds all permissions which will be
accepted:
I don't see that being done explicitly in our current code. The
OFBizSecurity class does that automatically. Any permission check is
done with the ADMIN permission first, then the requested permission.
Okay, so that was a bad example. How about CATALOG_UPDATE or
CATALOG_ROLE_UPDATE instead as an example. Instead a simple permission
defined as update:catalog:${catalogId} would take care of both of
these. If the user has the static 'update:catalog' permission it would
be granted (like a catalog admin might have), otherwise it would run
the DA logic to determine if the user has permission to update that
specific catalog.
One single permission, can handle most if not all cases when defined
properly.
4. Define permission for users, not admins. Instead of
looking for a static permission, set the permission to be
checked at the most granular level. When doing so, admin
users will always have permission and the API will handle
user access using DA logic.
I disagree. I might want my application to behave differently if an
admin is using it. Without an admin permission (or attribute), how
will I know if a user is in an admin role?
Then we will create an 'admin' base permission. I didn't see the need
for it, b/c I can't think of anything in which I would say "don't show
this to people who can access/create/read/update/delete; only show it
to an admin". I have nothing against this, just couldn't think of any
really useful cases. Do you have something specific in mind?
Andrew
Re: Authz API Discussion (was re: svn commit: r770084)
Adrian,
I must be missing something. Still using the Example component as an
example: the service definition called a service permission, which
called a script, which ultimately called Security.hasPermission.
Your modification has the service definition use the permissions> which ultimately calls authz.hasPermission(). So, both
methods end up calling a single hasPermission() method. What changed?
The only difference I see is that the permission string moved from a
script to the service definition. Is that the desired benefit?
It is indeed the designed benefit. Previously, we had this:
1. A service with a permission service attached. The permission
service checked static permission, and possibly (not in the case of
the example component, but honestly this component doesn't utilize the
full potential of the new code) processed other logic which would
determine of the user had the ability to perform that function.
2. A screen definition which checked permissions, okay again the
example component doesn't utilize all the possibilities, but let's say
we wanted to add a delete button to the screen to delete the example.
Using the old method you would then call the has-permission screen
operator and check for a static permission probably something like
EXAMPLE_DELETE.
Now, let's say we want to allow anyone to create examples, only the
person who created the example and any admin can update or delete it.
Using what we had in the old model, the permission service logic would
need to be adjusted to grant permission to the owner of the example.
However, the screen operator will still only pickup the static
EXAMPLE_DELETE permission. We don't want to give everyone delete
access, we only want them to delete the examples they created. So,
only admins or users with EXAMPLE_DELETE would see the button.
The new authz implementation handles all of this for us. First we
define the permissions, access:example, update:example and
delete:example as seed data. These are also attached to the example
admin user's security group.
We will give all users access:example permission so they can access
the application, but only give admins the update and delete permissions.
Next we define the Dynamic Access logic. Very little code need, check
the example from the exampleId which is passed in the
permissionContext and part of the permission string (which we will
define in a moment) and if the owner is the userId return true,
otherwise return false. This can be groovy or a simple method if
desired. We then register this logic with the permissions in the seed
data file. The same logic can be attached to both update:example as
well as delete:example.
Now we will configure the services to include permissions. The
createExample will have no permission or set it to access:example to
make sure only users who can access the app can create (I have other
more complex ideas for this, but this is a simple example). The
updateExample service should be set with "update:example:${exampleId}"
as the permission, the deleteExample service set with "delete:example:$
{exampleId}" permission.
Finally, we configure the screen definition and add the delete button
(or update button whatever the case may be). But we do a permission
check here as well for "delete:example:${exampleId}" (note: exampleId
should be in the screen's context) to restrict the display of the
button.
Now, using the new API the button is displayed under two conditions:
1. the user is an admin and has delete:example permission
2. the user is the owner of the example
The exact same logic is used by the service engine when submitting the
request, so you can be sure that if the button was displayed then
permission will be granted when submitting the form.
Maybe later you want to change how this works. Maybe being the owner
is not enough, you must the be owner and have been active in the last
5 days. So, you simply edit the logic in the groovy (or simple method)
script and clear the cache. The new logic kicks in, effective in all
places which check that permission.
This is what I mean by 'centralized'. Instead of having security split
up between the Security API and the Service Engine Permission API,
everything is moved and centered around the permission.
Andrew
Re: svn commit: r770771 - in /ofbiz/trunk: applications/securityext/src/org/ofbiz/securityext/test/ framework/security/src/org/ofbiz/security/authz/ framework/webapp/src/org/ofbiz/webapp/control/
Yeah, I've always wanted to change the service engine to use that... On May 1, 2009, at 4:52 PM, Adam Heath wrote: andrew.zene...@hotwaxmedia.com wrote: Yeah I'm game for a more definite fix. But what about app server threads? At some point, the app server will call into ofbiz code. This code, in all likely hood, is restricted to a few select places(ie, like the ControlServlet is run by a jetty or catalina container). This code is what needs to be modified to run the post-thread cleanup. Any other code that actually *does* maintain it's own thread pool would also be modified with this hook. Have you looked at the Executor framework?
Re: Authz API Discussion (was re: svn commit: r770084)
I think everyone needs to step back just a bit. Yes, some code was written, but nothing that drastically changes anything. Actually, I paid very close attention to make sure that this could sit on the side lines so it could be evaluated. Very little effort has been put into the real work of migrating the applications, but that is going to change soon... So, instead of discussing what should or should not have been done, look at the fact that this entire effort is sitting in the community's lap right this minute. But instead of reviewing what is there, pointing out weaknesses offering suggestions or anything constructive at all, the discussion is solely around whether or not code should have been implemented or not. Let's face it, these documents have been in front of you for over a week, and there was not a single objection or concern raised until today. I have only a limited amount of free time, and if I am going to following this effort through to the end, it needs to have a steady progression. So to be frank, get over it. Code is being worked on actively for this effort, and I am expecting more involvement as soon as the API is finalized. That said, if you do have something to add, wish to see or just want to be involved, now is the time to be proactive! Otherwise the effort will push forward with the people who are indeed interested in improving security in OFBiz. Andrew On May 1, 2009, at 8:38 PM, Adrian Crum wrote: --- On Fri, 5/1/09, Scott Gray wrote: Some of these questions in the discussions so far give me the feeling that the write up Andrew put in confluence hasn't been read, is that the case? Anyway I'm a +1 for the new auth framework, I think it give us more power AND simplicity. Will it need improvement over time? of course it will but I think it's a much better base to work from. I don't know if you were around at the time, but I was. One of the "weaknesses" Andrew is trying to fix with this latest effort is the permissions services - another design he introduced a couple years ago. Everyone went along with it and re-wrote code to use service permissions. (I spent several weekends just converting the accounting component over to the new security implementation). Now we're being told "Oops, that design is limited, let me try again." Why would anyone have any objection to opening this up to the community before we start writing code? Maybe there are others who see weaknesses in the new design. Give them a chance to offer input. -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
In the past, what 8 years that I have been working on OFBiz, not once have I had the masochistic urge to work on something which did not already have some sort of design. Never will you fine me wishing to refactor something without having the requirements already known. So, you will never find me coming to the table empty handed, and that is exactly what this sort of "request" is asking. Nor, do I want to review and discuss with someone an idea until they have their thoughts put together. So, what you can expect from me now, in the past and in the future is exactly your first statement. "Here is my design, what do you think..." On May 1, 2009, at 10:56 PM, Adrian Crum wrote: It's not the same! There is a big difference between "Here's my design, what do you think?" and "I'm interested in refactoring the security framework. Could you help me with the design?" -Adrian --- On Fri, 5/1/09, Scott Gray wrote: From: Scott Gray Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 7:49 PM It's exactly the same in fact, we have a design proposed by somebody let's start discussing it. Tear pieces out, replace some, improve others, whatever at least we have a starting point. Regards Scott On 2/05/2009, at 2:37 PM, Adrian Crum wrote: How about we start over and collaborate on a design? Is that so much different? -Adrian --- On Fri, 5/1/09, Scott Gray wrote: From: Scott Gray Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 7:30 PM This discussion is going no where fast, how about we back track to Andrew's last email and start actually discussing the design. Nothing is being foisted on anybody. Regards Scott On 2/05/2009, at 2:19 PM, Adrian Crum wrote: --- On Fri, 5/1/09, Anil Patel wrote: This is one of the big reasons what I love and hate community driven software. I don't see how what Andrew did is bad. Even though it was personal communication but I know Andrew only started after Adrian and Jacques showed interest by commenting on the page. The only interest I showed was that I agreed that OFBiz security could use improvement, and I suggested he use a third party library. I did not endorse or approve of his design. Andrew has been actively explaining his idea all this time. As I demonstrated in another reply, no he did not. Only a few days went by between introducing the idea and committing code. The work done till date is not blocking anybody, old security system is still in place. New system is implemented in example component so its lot easy for him to explain and people to understand. What if the new work is a bad design? How will we know that until everyone has had time to evaluate it? People have different ways of working in community, Joe is committer still all the time he creates Jira issue and uploads his patch and most of time its somebody else who does commits, but that's his way of working. If we don't do what Joe does then why should Andrew do what Adrian does. As far as I know, Joe submits patches for things he doesn't have commit rights to. I don't see any reason why we should start over. Do you see a reason why we shouldn't? Will the project suffer immensely if we pause and wait for others to comment? Is there some catastrophe looming that requires us to rush this through? All the time we talk about making things easy so people will contribute, Why do you want to resist a seasoned contributer for working. I'll rather have expect community will support. All the time he has been asking people to tell him suggestions, wish list etc. Why not support him and get more out of him instead. If we can't invite the community to participate - as I suggested - then that only proves what I suspect - that this is a design that is being foisted on the community. -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
What is your list of requirements Adrian?? On May 1, 2009, at 11:12 PM, Adrian Crum wrote: That's exactly what I'm suggesting. In the end we will have a much better implementation - one that will address everyone's issues and incorporate everyone's solutions. It will be more productive because we will work out problems on the drawing board, not in deployment bugs. -Adrian --- On Fri, 5/1/09, Scott Gray wrote: From: Scott Gray Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 8:06 PM So what are you suggesting, scrap the design and start from scratch? I don't see how that would be more productive than working from a proposal which is exactly what the design can be treated as. Regards Scott On 2/05/2009, at 2:56 PM, Adrian Crum wrote: It's not the same! There is a big difference between "Here's my design, what do you think?" and "I'm interested in refactoring the security framework. Could you help me with the design?" -Adrian --- On Fri, 5/1/09, Scott Gray wrote: From: Scott Gray Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 7:49 PM It's exactly the same in fact, we have a design proposed by somebody let's start discussing it. Tear pieces out, replace some, improve others, whatever at least we have a starting point. Regards Scott On 2/05/2009, at 2:37 PM, Adrian Crum wrote: How about we start over and collaborate on a design? Is that so much different? -Adrian --- On Fri, 5/1/09, Scott Gray wrote: From: Scott Gray Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 7:30 PM This discussion is going no where fast, how about we back track to Andrew's last email and start actually discussing the design. Nothing is being foisted on anybody. Regards Scott On 2/05/2009, at 2:19 PM, Adrian Crum wrote: --- On Fri, 5/1/09, Anil Patel wrote: This is one of the big reasons what I love and hate community driven software. I don't see how what Andrew did is bad. Even though it was personal communication but I know Andrew only started after Adrian and Jacques showed interest by commenting on the page. The only interest I showed was that I agreed that OFBiz security could use improvement, and I suggested he use a third party library. I did not endorse or approve of his design. Andrew has been actively explaining his idea all this time. As I demonstrated in another reply, no he did not. Only a few days went by between introducing the idea and committing code. The work done till date is not blocking anybody, old security system is still in place. New system is implemented in example component so its lot easy for him to explain and people to understand. What if the new work is a bad design? How will we know that until everyone has had time to evaluate it? People have different ways of working in community, Joe is committer still all the time he creates Jira issue and uploads his patch and most of time its somebody else who does commits, but that's his way of working. If we don't do what Joe does then why should Andrew do what Adrian does. As far as I know, Joe submits patches for things he doesn't have commit rights to. I don't see any reason why we should start over. Do you see a reason why we shouldn't? Will the project suffer immensely if we pause and wait for others to comment? Is there some catastrophe looming that requires us to rush this through? All the time we talk about making things easy so people will contribute, Why do you want to resist a seasoned contributer for working. I'll rather have expect community will support. All the time he has been asking people to tell him suggestions, wish list etc. Why not support him and get more out of him instead. If we can't invite the community to participate - as I suggested - then that only proves what I suspect - that this is a design that is being foisted on the community. -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Adrian, Thank you very much for your comments. Minor point, you misread what I said. I said "NOT ONCE have I had the masochistic urge to work on something which did not already have some sort of design"... meaning everything has had some sort of design even if its some sticky notes on my wall, or a drawing on the whiteboard describing a ContentMapFacade, or a full blown document like I put together in this case. Also, it is my experience that a prototype of some sort is often a good way to prove the concept and something I am often asked to provide. While I have nothing against working as in a community, hell isn't that why OFBiz is here? This is my way of working with the community, what you will see are proposals and prototypes like what you have right now. I have NEVER implied that my designs or implementations were ever superior, however I don't see any other proposals on the table right now. If was trying to avoid discussing and collaborating, you would hear nothing about it from me except for a some commits and more than half the applications would be finished already... Now that everyone has expressed themselves, I think we can move on to business. What we have in front of us today is a proposal and prototype of a new security enhancement which is really based several things. We have an API which can be implemented for various different methods of authorization. The design was careful to not require anything specific to the internal security functionality. I do plan to implement a Crowd version of this as well, which would end up being a hybrid LDAP via Crowd/OFBiz combination. A pure LDAP implementation can be developed as well, which is one thing I was certain you would be interested in. The designs are really very similar to those we discussed 2 years ago when the PermissionService stuff was implemented. For some reason however I let others influence my decision at that time and let it go. There was some discussion about more granular permissions for forums and I would personally like to implement much more granular permissions in Project Manager and SFA applications. Which is were this entire effort branched from. I find it frustrating that authorization is handled in so many different places and looking at it now, to me it looks like a total mess. I will want to customize the access control for the applications we use internally, no I need to. I don't want to patch or extend service definitions b/c that makes upgrading all that much more complicated. Finally, I want one single API which I can use throughout the system to check permission. I wrote a security prototype using JSecurity and Hibernate to get a feel for some other tools. Even considered integrating JSecurity into OFBiz. However, the major limitation to that API is that all permissions are loaded for a user when they authenticate. So, if we were to write custom logic to handle very granular permissions we could end up with millions or billions of permissions loaded into memory. This didn't seem scalable. I spent about a week writing down thoughts about what an ideal authorization scheme would look like. I compared that to what we have and came up with the designs that were posted last Friday. Last weekend, a received a few comments regarding the designs posted in Confluence and on Monday when I heard nothing more decided to start working on implementing the API. Only took a few hours, but after another day or so of testing I was then able to check it in for comments. The main points in this design is that is brings about a new permission format which provides a simple way to create very granular permissions. This is actually the main draw, the whole API is based around the permission format. Next, the pains in keeping up with permission>, the various different things which need to be called. The PermissionService implementation never became the "center". It was always still tied with the Security object, so now I think its time to address it completely and really centralize authorization. Now that there is proposal and a prototype, I would like to know if there are any requirements I did not account for. Like the findMatchingPermissions() idea was fantastic, and that is now part of the API and document. Let's review what we have and see what can make it better, but let's do it quickly... Andrew p.s. The one thing I don't care about is the fact that this is big and will require a lot of work, one of the reasons I am trying to move quickly on this is so that *I* have enough time to complete it. I'm not expecting everyone to jump in and help, and I don't want to leave it half done. On May 2, 2009, at 12:35 AM, Adrian Crum wrote: Understood. I remember sitting next to you at the developer's conference, and watching you work. I experienced firsthand your "masochistic urge to work o
Re: Authz API Discussion (was re: svn commit: r770084)
Jacques, Honestly, in my initial plan I only had 4 permissions create,read,update and delete. Then after thinking about it, access seemed to be a nice extra permission to limit access to applications. Read is nothing more than what view is today, the only reason for using the name "read" instead of "view" is because we can call them CRUD permissions or ACRUD permissions if we keep access. So, access was added only for granting access to the application. In most cases this is the only permission a user would need to access an app. Let's use Project Manger as an example for this: access:project would be the permission required to access the application. All users of the app would have this permission. The create:project permission would be given to a administrator, so new projects could be created same with create:project:task. However, create:project:task would have some dynamic access logic associated which would allow users to create tasks as long as they were associated with a project in certain role(s). The read:project permission could be used to restrict viewing details of a project, task, etc. This is just how I have been thinking of it, read could also be used in replace of access, I just thought it would be more flexible to have the extra permission. Mainly because I believe that most users only need a permission to access the application, the other permissions would be handled in a dynamic way based on how the user is associated in the application. Does this make any sense? Let me know if I am just confusing you more and I'll try again. Andrew On May 2, 2009, at 1:25 PM, Jacques Le Roux wrote: From: "Andrew Zeneski" ...snip... The new authz implementation handles all of this for us. First we define the permissions, access:example, update:example and delete:example as seed data. These are also attached to the example admin user's security group. We will give all users access:example permission so they can access the application, but only give admins the update and delete permissions. ...snip... Andrew, I'm stil thinking at my question about read and access differences. Why are you using access above, and in which cases read would be used ? I have the feeling that we don't need access (or read maybe) Here is a link to your answer http://docs.ofbiz.org/display/~jaz/ OFBiz+Security+Refactor#comment-7705 and the difference it's still not totally clear to me. Is *read for services* and *access for UI only* ? Jacques PS : Ha, I did not had a look at the example component yet, I better understand now, acces looks like the old OFBTOOLS... But could you please explain more how read will be used ?
Re: Authz API Discussion (was re: svn commit: r770084)
Are you saying that we attach some logic to the authorization API which returns an EntityCondition object to limit the data returned in queries? This goes well with the idea I had to add an EntityUtil.filterByPermission() method. However, I don't think this is something which would replace scripts (or services) for permissions, but would be something along with it to make queries more secure. If we can come up with a generic way to implement this (or maybe only somewhat generic) I think it would be really useful. So far here are the list of other things which have been discussed and all work well with the current proposal: 1. SimpleRoleCheckDa - A simple role check dynamic access class. This would include some new tables to associate table name and role type IDs for simple role based checking. You would associate the table (i.e. ContentRole) with the permission as well as valid roles (ADMIN, OWNER, etc). The simple class can be attach to any permission which only requires very simple role based checks. 2. EntityUtil.filterByPermission() - A new method which (like filterByDate) takes a list of GenericValue objects and removes the ones which the user does not have permission to perform the operation on. The permission string would be passed and parsed using the value for the entity. Nice way to pull out data a user should not see, but limited as it will not work with the ELI. 3. Associate EntityCondition with permissions (correct me if I am wrong here) to have a unified way of limiting data in queries. If this is possible, the filterByPermission might not be necessary. Andrew On May 2, 2009, at 8:02 AM, Scott Gray wrote: One thing that came to mind during our "discussion" today and I'm not sure how feasible it is but I'll throw it out there anyway: Most record based permission checks come to down querying the database for related records to check various roles and whatnot right? So what if instead of querying the database independently we provided some sort of security wrapped delegator to the applications that intercepts database queries and automatically appends the required entity expressions to the query. If it is a findOne/getRelatedOne query and no result is returned then you throw some sort of authorization exception because obviously the user didn't fit the criteria of someone able to view the record. If it's a findList/getRelated then only the permissible records would be returned. So instead of writing scripts for permissions we would write some sort of entity expression. Just a thought. Regards Scott On 2/05/2009, at 1:30 PM, Andrew Zeneski wrote: I think everyone needs to step back just a bit. Yes, some code was written, but nothing that drastically changes anything. Actually, I paid very close attention to make sure that this could sit on the side lines so it could be evaluated. Very little effort has been put into the real work of migrating the applications, but that is going to change soon... So, instead of discussing what should or should not have been done, look at the fact that this entire effort is sitting in the community's lap right this minute. But instead of reviewing what is there, pointing out weaknesses offering suggestions or anything constructive at all, the discussion is solely around whether or not code should have been implemented or not. Let's face it, these documents have been in front of you for over a week, and there was not a single objection or concern raised until today. I have only a limited amount of free time, and if I am going to following this effort through to the end, it needs to have a steady progression. So to be frank, get over it. Code is being worked on actively for this effort, and I am expecting more involvement as soon as the API is finalized. That said, if you do have something to add, wish to see or just want to be involved, now is the time to be proactive! Otherwise the effort will push forward with the people who are indeed interested in improving security in OFBiz. Andrew On May 1, 2009, at 8:38 PM, Adrian Crum wrote: --- On Fri, 5/1/09, Scott Gray wrote: Some of these questions in the discussions so far give me the feeling that the write up Andrew put in confluence hasn't been read, is that the case? Anyway I'm a +1 for the new auth framework, I think it give us more power AND simplicity. Will it need improvement over time? of course it will but I think it's a much better base to work from. I don't know if you were around at the time, but I was. One of the "weaknesses" Andrew is trying to fix with this latest effort is the permissions services - another design he introduced a couple years ago. Everyone went along with it and re-wrote code to use service permissions. (I spent several weekends just converting the accounting
Re: Authz API Discussion (was re: svn commit: r770084)
e patch here (note that this can also be produced with a "svn diff -r 770083:r770408 > AuthzExampleComponentSupport.patch" from the ofbiz/framework/exmaple directory): https://issues.apache.org/jira/browse/OFBIZ-2383 For other components let's not be too hasty. I won't get into a commit war over the example component, but for the rest I'll gladly do so since I think these changes have a negative ROI and this whole thing has turned into a big old chest-thumping mess. That being the case, sorry for joining in and thumping my own chest. Hopefully we can discuss some security objectives and common cases we want to support, and then evaluate this new proposed approach against them and/or establish a new approach based on this. There definitely ARE areas where it is currently cumbersome to implement specific security related requirements. -David On May 1, 2009, at 10:00 PM, Andrew Zeneski wrote: In the past, what 8 years that I have been working on OFBiz, not once have I had the masochistic urge to work on something which did not already have some sort of design. Never will you fine me wishing to refactor something without having the requirements already known. So, you will never find me coming to the table empty handed, and that is exactly what this sort of "request" is asking. Nor, do I want to review and discuss with someone an idea until they have their thoughts put together. So, what you can expect from me now, in the past and in the future is exactly your first statement. "Here is my design, what do you think..." On May 1, 2009, at 10:56 PM, Adrian Crum wrote: It's not the same! There is a big difference between "Here's my design, what do you think?" and "I'm interested in refactoring the security framework. Could you help me with the design?" -Adrian --- On Fri, 5/1/09, Scott Gray wrote: From: Scott Gray Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 7:49 PM It's exactly the same in fact, we have a design proposed by somebody let's start discussing it. Tear pieces out, replace some, improve others, whatever at least we have a starting point. Regards Scott On 2/05/2009, at 2:37 PM, Adrian Crum wrote: How about we start over and collaborate on a design? Is that so much different? -Adrian --- On Fri, 5/1/09, Scott Gray wrote: From: Scott Gray Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 7:30 PM This discussion is going no where fast, how about we back track to Andrew's last email and start actually discussing the design. Nothing is being foisted on anybody. Regards Scott On 2/05/2009, at 2:19 PM, Adrian Crum wrote: --- On Fri, 5/1/09, Anil Patel wrote: This is one of the big reasons what I love and hate community driven software. I don't see how what Andrew did is bad. Even though it was personal communication but I know Andrew only started after Adrian and Jacques showed interest by commenting on the page. The only interest I showed was that I agreed that OFBiz security could use improvement, and I suggested he use a third party library. I did not endorse or approve of his design. Andrew has been actively explaining his idea all this time. As I demonstrated in another reply, no he did not. Only a few days went by between introducing the idea and committing code. The work done till date is not blocking anybody, old security system is still in place. New system is implemented in example component so its lot easy for him to explain and people to understand. What if the new work is a bad design? How will we know that until everyone has had time to evaluate it? People have different ways of working in community, Joe is committer still all the time he creates Jira issue and uploads his patch and most of time its somebody else who does commits, but that's his way of working. If we don't do what Joe does then why should Andrew do what Adrian does. As far as I know, Joe submits patches for things he doesn't have commit rights to. I don't see any reason why we should start over. Do you see a reason why we shouldn't? Will the project suffer immensely if we pause and wait for others to comment? Is there some catastrophe looming that requires us to rush this through? All the time we talk about making things easy so people will contribute, Why do you want to resist a seasoned contributer for working. I'll rather have expect community will support. All the time he has been asking people to tell him suggestions, wish list etc. Why not support him and get more out of him instead. If we can't invite the community to participate - as I suggested - then that only proves what I suspect - that this is a design that is being foisted on the community. -Adrian
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Just for clarification, my proposal did include a new way to write
permissions using groovy, but it also supports permissions as services
ad well as a new interface to implement very common permission
checking routines for re-usability.
This was only one part of the proposal, the main focus is on not
attaching the logic directly to the service instead it is attached to
a verbose permission. The reason for this is to make customization of
the permission logic easy to maintain, and not require modifying the
actual application.
The point is, the groovy part you keep referring to is just a minor
extra and not the focus of the framework.
Andrew
On May 3, 2009, at 1:38 PM, David E Jones
wrote:
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
--- On Sat, 5/2/09, David E Jones
wrote:
My personal opinion on this is that the design has only
subjective improvements and most of it is a big step
backwards (easier but less flexible, for the services versus
direct permission part anyway, and we decided long ago that
flexibility was better than ease in this case; and yes there
is a creative way to invoke code attached to permissions,
but that is a bit inflexible IMO since much permission logic
involved multiple permissions... it's the artifact we
want the code attached to not the permission itself)
I've been thinking about that aspect of it. If I understand
correctly, here are two of the issues being addressed by the new
security:
1. Permission checking is being done in scripts, so a programmer is
required to change the permission checking logic. An ordinary
systems administrator with no knowledge of mini-language would not
be able to change how permissions are checked. The new permission
string is supposed to make changes to permission checking easier
for the non-programmer administrators.
2. Permission checking isn't consistent. Two similar branches of
logic will check permissions in two different ways: one will check
a permission string, and another will run a script. This is common
in the UI versus the services called by the UI. A simple "has
permission" check is done in the UI, and then the service invoked
runs a script to check permissions.
I agree with you that substituting the permission service with a
permission string is too inflexible.
One of the ideas I've been toying with is the idea of a permission
expression. I started writing some code for that and was going to
put it in Jira, but I decided to put it on the shelf until the dust
settles from this thread.
Let's say we took Andrew's new permission string and gave it more
oomph - where it could contain functions and such. (The expression
language would be simple enough for common administrators to
understand.) That could eliminate many of the permission checking
scripts. In effect, the permission string becomes a mini-script.
This mini-script could be used anywhere a permission string is
being used now.
One of the problems I have with what has been proposed so far is
that the permission string can be ambiguous when it comes to
inserting parameters. For example, "update:example:${exampleId}" -
what does that mean? There's no way to tell by looking at it. It
would be preferable to have something like "update:example +
relatedTo(exampleId)". That permission tells me something - it
requires update:example permission and the user must be related to
exampleId in some way.
I think permission expressions would solve both of the issues above.
Part of the point (if I remember right) of putting permission logic
into little services was to help keep it consistent when that
service is called in multiple places, especially in the input
processing service and the output generating screen.
If we have cases where a direct permission check is done on the
screen and a permission service is used for the input processing
service, then we should really change the screen to also call that
same service.
I guess the real trick with all of this is to make any easy way to
do dynamic permissions. So far we have these approaches on the table
(sorry if I missed any others...):
1. the current recommended practice of writing a service to perform
permission logic (service can be implemented in simple-method, java,
groovy, etc; normally the easiest way to write and maintain (and in
the future to create tools to help write and maintain) is a simple-
method XML snippet)
2. Andrew's new pattern of attaching a groovy script to certain
permission strings to override the normal behavior of that string
3. Adrian's idea to create some new expression (possibly extend what
Andrew has done) and add functions to the permission string itself
(which might eventually have boolean logic and other things, and be
a little expression language of its own)
Does that sound about right?
When comparing these the big question for me is what will be easiest
for u
Re: Authz API Discussion (was re: svn commit: r770084)
Inline... Please don't revert the rest of the code. The point is that this needs time to mature, so it should stay in there but not become the default... not YET anyway. I will leave the what was implemented alone for the time being. Also, please don't be personally offended by this. Just because there are comments and feedback doesn't mean something has no merit, it just means that some adjustments to it might be able to improve it. That's what collaboration is all about, and I guess if you'd rather not do it than have other people comments on it and make changes to it then collaboration will be difficult. I am not offended by any comments or feedback, I was only offended by your actions. Reverting the example was nothing more than a power move by you. You can argue this if you wish, but the fact is nothing else except for an example was effected, and there has been no discussion by anyone to revert anything yet. If you did feel that it was problematic, it should have been brought up if not to the community then at least to me personally. Just to clear that up... are you saying you would rather not do any of this than make some changes and refinements to it based on feedback? I hope that's not the case. My intent with this, as I explained in my email, is to make a compromise and allow development and improvement on this to continue without impact on other parts of the project until it is more ready for that. Your assumptions (as assumptions often are) completely wrong. Even though say now you hope this isn't the case, you have publicly accused me of this in your Notes On Security Changes document. What have I been doing for the past week? It surely wasn't moving ahead and checking in changes to all the applications to use a new authorization pattern. What I have been doing is acquiring additional needs/ requirements comparing them to what I have planned and trying to discuss with the community these changes. Refining the API and including the requirements which I have gathered. You keep claiming that this new pattern is less flexible. While that may (but I don't agree) be true to a certain extent, is it also far MORE flexible when it comes to creating custom implementations for vertical, custom or customized applications. Andrew
Domain Based Security ( was re: Authz...)
What you are describing here is very similar to the process-based authorization system which I proposed, the main differences is in my proposal everything is defined in a process [permission] string where this is based on artifacts. I think I need to understand this more, as I don't really see yet how it would work. You mention there is no permission-checking code, but you also mention that if the user has a specific permission then the screen is displayed. This is the confusing part to me right now. How does the "domain" know if a user has permission if there is no permission checking code? How does is the access control logic handled in this system? Could you explain how to accomplish this example using this pattern: Display a list of example records, for the records the user can update display the update button, for the records the user can delete show the delete button. For the records which the user does not have these permissions don't display the button. When delete is pressed, we need to make sure the user really does have access to delete this record, how can we verify this? My followup question will be, how do I customize the access logic for a specific client so that I can maintain my own logic in a private component and avoid problems when updating applications? For me these are the most important requirements (very granular control and ease of customizing without modifying files in the application). Andrew On May 3, 2009, at 12:57 PM, Adrian Crum wrote: Take your comment - "it's the artifact we want the code attached to not the permission itself" - and combine that with Scott's suggestion to have a security-aware delegator, and you have a solution I proposed years ago: a domain-driven security system. In a domain-driven security system, each OFBiz artifact is responsible for handling security for itself. There is no explicit permission-checking code. Each OFBiz artifact identifies itself in a security domain. When a user tries to use that artifact, it checks the user's permissions against its own position in the domain. Using the Example component's EditExample screen as an example, here is what a security domain might look like: framework example screen EditExample (screen) EditExample (form) Permissions are hierarchical - each artifact inherits permissions from the artifact above it. This is very similar to what Andrew is trying to achieve, but it's different because the artifacts themselves control the security - there is no call to a permission service with a permission string. Here's what it might look like in ExampleScreens.xml: ... Notice there are no explicit permission checks. Instead, each artifact has identified itself in the security domain. When the widget is run, each artifact checks the user's permissions against its own security domain. So, the EditExample screen would look for the framework:example:screen:EditExample" permissions and handle itself accordingly. (Andrew - this is why I suggested having permission checking code return all permissions for a context.) If a user has the access:framework:example:screen:EditExample permission, the screen will display. Let's take a look at what happens in the form widget. Here is what ExampleForms would look like: title="" default-map-name="example"> ... Again, when the widget is run, each artifact checks the user's permissions against its own security domain. So, the EditExample form would look for the framework:example:screen:EditExample:EditExample" permissions and handle itself accordingly. Let's say the user doesn't have any permissions for that context. Keep in mind permissions are hierarchical - so the form widget would work its way up the hierarchy to find permissions. If a user has the access:framework:example:screen:EditExample permission, the form will display plain text with no input fields. If the user has the update:framework:example:screen:EditExample permission, the form will provide input fields. Form fields could identify themselves in the security domain as well - so only the fields the user is permitted to access will appear. Service definitions and entities could identify themselves in the security domain in a similar way, and have similar permissions checking logic. Some examples: framework example service updateExample framework example entity Example The nice thing about this approach is that you could leverage the artifact gathering code to display the security domain as a tree - with permission checkboxes next to each "leaf." That would enable any administrator to manage user security easily. -Adrian
Re: Domain Based Security ( was re: Authz...)
Because no matter how we design security for the default implementation in OFBiz there will always be some industry, or business requirement that is not covered, there is no way we can plan for every possible scenario. Thus, we need to make sure there are simple ways to modify the default behavior without having to intrude into the low level functionality. This is one of the key issues I have been trying to solve. On May 3, 2009, at 7:26 PM, Adrian Crum wrote: My followup question will be, how do I customize the access logic for a specific client so that I can maintain my own logic in a private component and avoid problems when updating applications? Why would you want to do that? I can't think of a reason why a security system would need to be changed.
Re: Domain Based Security ( was re: Authz...)
Okay, so it seems that Adrian and I have a very similar idea. The only major difference I see is one is artifact based and the other is process based. In the artifact based system, each artifact needs to register itself, and somehow the framework needs to know how to process access control for each artifact. Each artifact still has permissions, so it will check to see if the user has specific permission(s) for the artifact. Access control logic is still required, and the system will need to know how to process this for each artifact. I'm not clear yet what that would look like, but so far it doesn't sound much different. In the process based system, instead of registering artifacts, the developer registers process based strings with the system (in the designs this is handled by seed data). Logic is attached to each process string (or parent process string when parent/child share the same logic). Authorization is handled per process by checking to see if the user has "permission" to perform that process. Processes are hierarchical (it appears the domain based system is as well) where a user with access to the higher level of the hierarchy has implied access to all the lower levels. The question I believe now is, which is better? I personally think in terms of processes which is why what I proposed was all process based. However, artifact based may be more granular, but possibly too granular. If I understand this right, artifact based we could potentially have different access requirements for every single form/ screen/service/entity/etc; where in a process based system the developer would define the processes as part of the application and these processes could be shared across common artifacts (forms can share with screens that share with services, etc). Does this sound like a fair assessment? Andrew On May 3, 2009, at 10:22 PM, Adrian Crum wrote: Understood. If there is any interest in the design, and we start to flesh it out, I'm sure those scenarios could be presented and addressed. -Adrian --- On Sun, 5/3/09, Andrew Zeneski wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org Date: Sunday, May 3, 2009, 7:11 PM Because no matter how we design security for the default implementation in OFBiz there will always be some industry, or business requirement that is not covered, there is no way we can plan for every possible scenario. Thus, we need to make sure there are simple ways to modify the default behavior without having to intrude into the low level functionality. This is one of the key issues I have been trying to solve. On May 3, 2009, at 7:26 PM, Adrian Crum wrote: My followup question will be, how do I customize the access logic for a specific client so that I can maintain my own logic in a private component and avoid problems when updating applications? Why would you want to do that? I can't think of a reason why a security system would need to be changed.
Re: Domain Based Security ( was re: Authz...)
I like to think of it more as process-driven permission vs artifact driven permissions, because the "permission string" is defined to match a specific process. Other than that I think we finally agreed on something.. Ha! :) On May 4, 2009, at 1:55 AM, Adrian Crum wrote: --- On Sun, 5/3/09, Andrew Zeneski wrote: The question I believe now is, which is better? I personally think in terms of processes which is why what I proposed was all process based. However, artifact based may be more granular, but possibly too granular. If I understand this right, artifact based we could potentially have different access requirements for every single form/screen/service/entity/etc; where in a process based system the developer would define the processes as part of the application and these processes could be shared across common artifacts (forms can share with screens that share with services, etc). Does this sound like a fair assessment? Yes it is. It boils down to permission-driven permissions, versus artifact-driven permissions. -Adrian
Re: Domain Based Security ( was re: Authz...)
No you misunderstood me. I was referring to us agreeing in a previous email that "it was a fair assessment". Hence the smiley. I think your comparison here is correct. In the process driven model, the logic is attached to the process, and the process is attached to various artifacts. The "gatekeeper" indeed is the central holder of information. However, I do believe your analogy is slightly off. Its more like "Adrian wishes to start car X" the gatekeeper takes the information from Adrian's "key" and says "Ok" or "Not Ok". The process is "start car X", the credentials are the "ignition key". Andrew On May 4, 2009, at 2:35 AM, Adrian Crum wrote: I don't see us agreeing on anything. I'm saying each artifact is responsible for its own security. You're saying security is defined by a process. If you were to view a collection of artifacts - each responsible for its own security - defining some kind of process-driven security, then that might be true. Applying your process-driven security design to the picture analogy (from what I have gathered so far from your design), it would be like there is a gatekeeper at the entrance to the picture. The gatekeeper says "Adrian intends to start the car, does he have permission to do that?" The car has no say in the matter. The gatekeeper controls everything. The inherent limitation to that design is, the gatekeeper has to account for every motive I might have in interacting with every artifact in the picture. That gatekeeper has a lot on its hands! I think it is simpler to have each artifact decide for itself what Adrian can or cannot do with it. I believe that was what David was trying to express when he said "it's the artifact we want the code attached to not the permission itself." -Adrian --- On Sun, 5/3/09, Andrew Zeneski wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org Date: Sunday, May 3, 2009, 11:00 PM I like to think of it more as process-driven permission vs artifact driven permissions, because the "permission string" is defined to match a specific process. Other than that I think we finally agreed on something.. Ha! :) On May 4, 2009, at 1:55 AM, Adrian Crum wrote: --- On Sun, 5/3/09, Andrew Zeneski wrote: The question I believe now is, which is better? I personally think in terms of processes which is why what I proposed was all process based. However, artifact based may be more granular, but possibly too granular. If I understand this right, artifact based we could potentially have different access requirements for every single form/screen/service/entity/etc; where in a process based system the developer would define the processes as part of the application and these processes could be shared across common artifacts (forms can share with screens that share with services, etc). Does this sound like a fair assessment? Yes it is. It boils down to permission-driven permissions, versus artifact-driven permissions. -Adrian
Re: Brainstorming: Security Requirements/Scenarios
The list you have here seems to imply we have decided on an artifact based security system, that is not the case. So far there are two different styles being discussed one is artifact based where the other is process based. Andrew On May 4, 2009, at 1:28 PM, David E Jones wrote: This thread is specifically for discussing security requirements and security use scenarios to drive OFBiz security functionality going forward. Please keep other discussion in another thread. These things tend to fall into two categories: functionality access and record-level access, or a combination of both. That is a high level generalization so just warning you that what I list below may be limited by my own blindness since I usually think in terms of those two things for security configuration. In other words, that's the point of this brainstorming thread. To get things started, here are a few I can think of and have heard from others, these are in no particular order: 1. User X can use Artifact Y for anything that artifacts supports and on any data (where "artifact" is a screen, web page, part of a screen or page, service, general logic, etc) 2. User X can use Artifact Y only for records determined by Constraint Z 3. User X can use any artifact for records determined by Constraint Z 4. Artifact Y can be used by any user for any purpose it supports 5. Artifact Y can be used by any user for only for records determined by Constraint Z 6. User X can use any artifact for any record (ie superuser) Okay, you can see that my initial pass at this is sort of an enumeration of combinations effort. If you can think of other general scenarios, please share! Also, please feel free to share specific requirements that are not in such generic terms (we can worry about putting them in more generic terms like this later). Thank You! -David
Re: Domain Based Security ( was re: Authz...)
I believe that no matter which method is used (process or artifact) both would require similar access control logic to be implemented. I'm not sure how this would look in the artifact system (Adrian can comment on that), but in the process driven system there would be two options. 1. For simple checking a record against a role table (take ContentRole as an example for this discussion; note that content may or may not be considered a simple check, that has yet to be discussed/designed) you could define the process of update:content:data to use a common RoleCheckingDa extension and set the allowed role type values. This would remove the need for extra logic which would need to be implemented in simple circumstances. 2. Custom DA logic would be attached; in the case of the update:party:contact process, logic would be written to check first the owner of the party vs the user attempting to run the process, followed by checking to see if the user is an admin/owner of a group which the party to update is a member of. So to better answer your question, regardless of the type of system used, this sort of access control would be available and part of the application design. Based on what I have read so far, the artifact driven model would require this logic to be implemented in multiple places assuming you want the same control in multiple artifacts. Where as in a process driven architecture you would connect this logic to the process and then associate/check that process with multiple artifacts. Andrew On May 4, 2009, at 2:39 PM, Al Byers wrote: Am I correct in thinking that artifact driven approach naturally integrates the concept of allowing inherited permission checking by roles, but in the process-driven approach we would have to use something like the RoleCheckingDa API extension? So if I want to give an administrator access to all records in their district schools, but not to all records in the state, I would just have to attach that person (or their role?) to the district and it would all be handled, but in the process-driven case I would have to make a call to perform that check? -Al On Mon, May 4, 2009 at 12:35 AM, Adrian Crum wrote: I don't see us agreeing on anything. I'm saying each artifact is responsible for its own security. You're saying security is defined by a process. If you were to view a collection of artifacts - each responsible for its own security - defining some kind of process-driven security, then that might be true. Applying your process-driven security design to the picture analogy (from what I have gathered so far from your design), it would be like there is a gatekeeper at the entrance to the picture. The gatekeeper says "Adrian intends to start the car, does he have permission to do that?" The car has no say in the matter. The gatekeeper controls everything. The inherent limitation to that design is, the gatekeeper has to account for every motive I might have in interacting with every artifact in the picture. That gatekeeper has a lot on its hands! I think it is simpler to have each artifact decide for itself what Adrian can or cannot do with it. I believe that was what David was trying to express when he said "it's the artifact we want the code attached to not the permission itself." -Adrian --- On Sun, 5/3/09, Andrew Zeneski wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org Date: Sunday, May 3, 2009, 11:00 PM I like to think of it more as process-driven permission vs artifact driven permissions, because the "permission string" is defined to match a specific process. Other than that I think we finally agreed on something.. Ha! :) On May 4, 2009, at 1:55 AM, Adrian Crum wrote: --- On Sun, 5/3/09, Andrew Zeneski wrote: The question I believe now is, which is better? I personally think in terms of processes which is why what I proposed was all process based. However, artifact based may be more granular, but possibly too granular. If I understand this right, artifact based we could potentially have different access requirements for every single form/screen/service/entity/etc; where in a process based system the developer would define the processes as part of the application and these processes could be shared across common artifacts (forms can share with screens that share with services, etc). Does this sound like a fair assessment? Yes it is. It boils down to permission-driven permissions, versus artifact-driven permissions. -Adrian
Re: Domain Based Security ( was re: Authz...)
We need to agree on terminology, authentication would refer to confirming a subject is who they say they are (checking user's name/ password combination), where authorization would refer to granting access to something. What we having been discussing is re-designing the way ofbiz handles authorization. Authentication should be a completely different topic all together. On May 4, 2009, at 2:56 PM, Adrian Crum wrote: So, no - the inheritance is not in user roles. However, user role inheritance could be accommodated by the authentication mechanism.
Re: Authz API Discussion (was re: svn commit: r770084)
Jacques, Thanks for your questions. I will address each one inline... Honestly, in my initial plan I only had 4 permissions create,read,update and delete. Then after thinking about it, access seemed to be a nice extra permission to limit access to applications. Read is nothing more than what view is today, the only reason for using the name "read" instead of "view" is because we can call them CRUD permissions or ACRUD permissions if we keep access. Yes I see, we need something like OFBTOOLS was used for. But can't we use simply read for that. It seems to me that access introduce redudancy. What would be the differences between, for instance access:sfa vs read:sfa access:sfa:lead vs read:sfa:lead access:sfa:opportunity vs read:sfa:opportunity etc. access:sfa would mean that the user can simply access the application. Where read:sfa would mean, the user can read anything in the SFA application. A better example of this would be the order manager, where access:order would allow the user to login, but read:order would allow the user to view any order/request/etc in the application. A more granular permission of read:order:orderdetail:1 would limit the user to only reading the specific order without granting permission to the rest of orders/requests/etc. I would not recommend creating granular permissions for access, unless we wanted to limit the access of specific "tabs" or areas in an application. If we wanted to restrict access to leads in sfa, then we might create an access:sfa:lead process/permission which can then be used to restrict access to the leads section of the app. Where as read:sfa:lead would mean the user can view any lead. So, access was added only for granting access to the application. In most cases this is the only permission a user would need to access an app. Let's use Project Manger as an example for this: access:project would be the permission required to access the application. All users of the app would have this permission. The create:project permission would be given to a administrator, so new projects could be created same with create:project:task. However, create:project:task would have some dynamic access logic associated which would allow users to create tasks as long as they were associated with a project in certain role(s). The read:project permission could be used to restrict viewing details of a project, task, etc. But could we not use read:project instead of access:project, and then keep only the CRUD permissions ? What we will be missing if we remove access ? I don't think so. Because read:project would grant the user global read access to all projects. Instead, when displaying a project we might want to attach the process of read:project:1 to the UI, to verify the user is indeed allow to read that project. Where access:project would just simply allow the user to login to the tool. This is just how I have been thinking of it, read could also be used in replace of access, I just thought it would be more flexible to have the extra permission. Mainly because I believe that most users only need a permission to access the application, the other permissions would be handled in a dynamic way based on how the user is associated in the application. Could you please elaborate on the extra permission and why it's needed ? I think I elaborated in the above two comments, so if this is still vague please let me know and I will try to explain it again in a different way. Thanks again for your questions! Andrew
Re: Brainstorming: Security Configuration Patterns
I agree with this. We could add a parentGroupId to the SecurityGroup entity, then a group would inherit all permissions from the parent groups up the tree as well as the permissions associated with that group specifically. Another thing we could do is add a field to SecurityGroupPermission which would tell the system to either include or exclude that permission from the group. Then you could have groups inherit from parents with minor changes (exclude) or minor additions. Andrew On May 5, 2009, at 11:52 AM, Harmeet Bedi wrote: I think an important thing missing is parentId in SecurityGroup. Adding that would give you heirarchy. Groups sort of are roles. Group has association with Subject(UserLogin through UserLoginSecurityGroup), Permission(SecurityGroupPermission), Permission is tied implicitly to action and resource.. Sort of RBAC. Harmeet - Original Message - From: "Ruth Hoffman" To: dev@ofbiz.apache.org Sent: Tuesday, May 5, 2009 11:05:12 AM GMT -05:00 US/Canada Eastern Subject: Re: Brainstorming: Security Configuration Patterns Hi All: One pattern I worked with some time ago is called Role Based Access Control (RBAC). This would be similar to #4 below, where you have a "role" - with permissions associated with that role - defining authorization levels. If you are interested in exploring this further, I'd be happy to elaborate. Ruth David E Jones wrote: This thread is specifically for discussing possible configuration patterns to use in OFBiz going forward. Please keep other discussion in another thread, including the merits of each possibility... let's just brainstorm in this thread. To get things started, here are the patterns that have been discussed recently (in high level terms, we can get into implementation and specific practices later on), these are in no particular order: 1. artifacts responsible for their own security (especially services and screens), and security permissions are referred to directly (ie the actual permissions are configured directly in the XML tags for the artifact) 2. artifacts responsible for their own security, and no direct references are used and instead an indirect security control is referred to; this is basically the permission service model we've been using where a permission service is basically a security policy that refers to permissions, can query/filter/whatever to do record level security, and in customization the permission service can be overridden or its function changed by ECA rules without touching any OOTB code or configuration 3. a hybrid of #1 and #2 where artifacts refer directly to permissions and there is external configuration based on those permissions that can add other qualifying permissions and/or invoke logic to change how that permission is evaluated (ie override the default behavior of requiring the user to have that permission and either add additional constraints or allow alternative constraints even if the user does not have the original permission that triggered it all); this is recursive so that if an alternative permission is configured that permission may also have further alternative permissions; also being recursive if attached logic evaluates other permissions that may have alternative permissions and/or permission logic attached to them; as I understand what Andrew has implemented, this is the pattern he followed 4. artifacts are not responsible for their own security except to specify whether any sort of permission is required or not (ie a require-permission attribute, would be true by default; for example most ecommerce screens would have this set to false); access control would be configured externally so that you can configure access at the most granular level possible (we would go ALL the way here, including: screens, services, forms, form fields, menu items, tree nodes, etc, etc); the access control tools would have patterns and features to facilitate grouping of artifacts, grouping of users (ie just use the current SecurityGroup entity), and support for both functionality access and record-level access Can anyone thing of other patterns? Again, PLEASE do not comment on which one you like better or what you think the advantages or disadvantages are of each in this thread (of course, definitely think about such things and feel free to comment in other threads, I just want this to be a "hat's off" (yes, that is a reference to Six Thinking Hats by Edward de Bono; anyone who hasn't read that should give it a go!) brainstorming session. Thank You! -David
Re: Domain Based Security ( was re: Authz...)
To me this sounds like the security information is being spread out in ever more places, not consolidated. If I need to customize the authorization logic, I would much rather it be centralized and NOT in the artifacts. If it was in the artifacts, much like it is today, then customizing would require modifications to the OOTB artifacts. Which is exactly what we should be avoiding. Andrew On May 5, 2009, at 11:42 AM, Adrian Crum wrote: In the design I proposed, the configuration resides in the artifacts themselves. -Adrian Harmeet Bedi wrote: If goal is to change security without changing code or XML configuration.. the configuration has to reside somewhere. db seemed like a spot. UI would needs to show the artifacts and permission and configure groups on them. I had SecurityPermission entity extended to have SecurityResource(Artifact) and SecurityActionType(e.g. access) If the issue is that should there be no static check and collect resources to seed db, instead to it dynamically it would be fine. It would make things dynamic and configuration friendly while still taking config out of xml. Harmeet - Original Message - From: "Adrian Crum" To: dev@ofbiz.apache.org Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern Subject: Re: Domain Based Security ( was re: Authz...) Harmeet Bedi wrote: Ofbiz has the graph metadata of artifacts but navigating graph to dynamically determine will be expensive. It doesn't have to be. If we end up using the artifact info stuff for some kind of security administration screen, we can set up the artifact gathering code to go only as deep as what is currently being displayed. In other words, the artifact gathering could be more dynamic. As the user navigates farther down the graph, additional parsing is done. This would eliminate the need to graph all artifacts in one step. I agree with David that storing the graph in the database is a bad idea. -Adrian
Re: Domain Based Security ( was re: Authz...)
Adrian, While this is fine when a artifact handles a specific "process" but what about when a screen (for example) like EditExample would be used for different processes? Often the same screen/form is used for create vs update; and even more often a user will have access to create but not update [everything]. Also, an artifact (such as a screen) could contain multiple processes. A list screen for example may also include a delete button. However, with no explicit permission checks, the delete button will display for all users who have access to this artifact. So, you would still need to have explicit permission checks to see if the user has access to the delete button in this artifact. Andrew Permissions are hierarchical - each artifact inherits permissions from the artifact above it. This is very similar to what Andrew is trying to achieve, but it's different because the artifacts themselves control the security - there is no call to a permission service with a permission string. Here's what it might look like in ExampleScreens.xml: ... Notice there are no explicit permission checks. Instead, each artifact has identified itself in the security domain.
Re: Domain Based Security ( was re: Authz...)
I should also note that in the process based system I have been talking about we can easily follow similar patterns Adrian has recommended. Service artifacts are one thing, as they usually only relate to a single process. But in screens and other artifacts we could "register" them with a process: to see if the delete button should be rendered. This is technically no different than doing has-permission checks, just doing so in a different XML format and instead of calling has- permission many times it just gathers all permissions at once and then permission checking is just handled from the screen's context. I never even considered such a thing when I started working on the process based designs because I was taking ease of migration into consideration. Changing from plain permission checks to a more process based permission string was large enough. However, my point is that if we are considering ways to change all the artifacts in OFBiz and how they deal with security it can be done with either of the two proposals. With the process based designs it could just be done at a later time. Andrew On May 5, 2009, at 2:04 PM, Andrew Zeneski wrote: Adrian, While this is fine when a artifact handles a specific "process" but what about when a screen (for example) like EditExample would be used for different processes? Often the same screen/form is used for create vs update; and even more often a user will have access to create but not update [everything]. Also, an artifact (such as a screen) could contain multiple processes. A list screen for example may also include a delete button. However, with no explicit permission checks, the delete button will display for all users who have access to this artifact. So, you would still need to have explicit permission checks to see if the user has access to the delete button in this artifact. Andrew Permissions are hierarchical - each artifact inherits permissions from the artifact above it. This is very similar to what Andrew is trying to achieve, but it's different because the artifacts themselves control the security - there is no call to a permission service with a permission string. Here's what it might look like in ExampleScreens.xml: ... Notice there are no explicit permission checks. Instead, each artifact has identified itself in the security domain.
Re: Brainstorming: Security Configuration Patterns
Actually, SecurityGroup is a group that links permissions (SecurityGroupPermission) which then get associated with UserLogins (UserLoginSecurityGroup). In some systems a Role is a collection of permissions, much like a SecurityGroup in OFBiz. On May 5, 2009, at 2:26 PM, Harmeet Bedi wrote: To me this seemed to be intent from data model. - Group is PartyGroup that can be a collection of party through PartyRelationship. - PartyGroup is a Party. SecurityGroup can apply to Party hence to a PartyGroup - SecurityGroup is not a group of users, it is a role that applies to a Party. On closer inspection that does seem to be the case. It seems that SecurityGroup is really a collection of user logins.. so not a role at all. I see your point.. inserting a SecurityRole entity between Group and Permission would be more flexible. In that case SecurityGroup is really a UserLoginGroup. Harmeet - Original Message - From: "Ruth Hoffman" To: dev@ofbiz.apache.org Sent: Tuesday, May 5, 2009 1:44:34 PM GMT -05:00 US/Canada Eastern Subject: Re: Brainstorming: Security Configuration Patterns Harmeet: Groups within OFBiz are similar to roles but in the RBAC model a "role" is an entity in and of itself. A group or collection of groups (also defined in RBAC as unique entities) may have one or more roles applied to them just as a user might. I think the value of RBAC is in its extensibility. For example, by defining "roles" we can abstract the definition of a permission (the security constraint in this case) away from the assignment of the permission. Just my 2 cents. Ruth I think an important thing missing is parentId in SecurityGroup. Adding that would give you heirarchy. Groups sort of are roles. Group has association with Subject(UserLogin through UserLoginSecurityGroup), Permission(SecurityGroupPermission), Permission is tied implicitly to action and resource.. Sort of RBAC. Harmeet - Original Message - From: "Ruth Hoffman" To: dev@ofbiz.apache.org Sent: Tuesday, May 5, 2009 11:05:12 AM GMT -05:00 US/Canada Eastern Subject: Re: Brainstorming: Security Configuration Patterns Hi All: One pattern I worked with some time ago is called Role Based Access Control (RBAC). This would be similar to #4 below, where you have a "role" - with permissions associated with that role - defining authorization levels. If you are interested in exploring this further, I'd be happy to elaborate. Ruth David E Jones wrote: This thread is specifically for discussing possible configuration patterns to use in OFBiz going forward. Please keep other discussion in another thread, including the merits of each possibility... let's just brainstorm in this thread. To get things started, here are the patterns that have been discussed recently (in high level terms, we can get into implementation and specific practices later on), these are in no particular order: 1. artifacts responsible for their own security (especially services and screens), and security permissions are referred to directly (ie the actual permissions are configured directly in the XML tags for the artifact) 2. artifacts responsible for their own security, and no direct references are used and instead an indirect security control is referred to; this is basically the permission service model we've been using where a permission service is basically a security policy that refers to permissions, can query/filter/whatever to do record level security, and in customization the permission service can be overridden or its function changed by ECA rules without touching any OOTB code or configuration 3. a hybrid of #1 and #2 where artifacts refer directly to permissions and there is external configuration based on those permissions that can add other qualifying permissions and/or invoke logic to change how that permission is evaluated (ie override the default behavior of requiring the user to have that permission and either add additional constraints or allow alternative constraints even if the user does not have the original permission that triggered it all); this is recursive so that if an alternative permission is configured that permission may also have further alternative permissions; also being recursive if attached logic evaluates other permissions that may have alternative permissions and/or permission logic attached to them; as I understand what Andrew has implemented, this is the pattern he followed 4. artifacts are not responsible for their own security except to specify whether any sort of permission is required or not (ie a require-permission attribute, would be true by default; for example most ecommerce screens would have this set to false); access control would be configured externally so that you can configure access at the most granular level possible (we would go ALL the way here, including: screens, services, forms, form fields, menu items, tree nodes, etc, etc); the access control
Re: Domain Based Security ( was re: Authz...)
Well, this is starting to sound exactly like what I proposed, with the exception that in my proposal everything would be tied to a "process" rather than an artifact. The process of "updating a party record" is attached to the artifacts which are involved in the process, then permission logic is attached (by database configuration) to that very same process. To me a process driven model is far more comprehendible to an average application administrator, where an artifact based would be way more technical. An administrator would need to understand all the artifacts in the application in order to configure things properly. Where in a process model, the admin only needs to understand the process involved and the artifacts are associated to the process during development. Defining the processes involved in an application is something which should be done during design. During implementation, all that needs to be addressed is associating the artifacts to the correct process. In my opinion security should be thought of as a business level requirement, putting it on the artifact is too technical. Andrew On May 5, 2009, at 3:59 PM, David E Jones wrote: Exactly, I like this direction a lot better too... ie don't have the permissions in the artifacts but have them all in a separate place that refers back to the artifacts (and other things) as needed. With it outside the artifacts and centralized in database driven configuration, it would be a LOT easier for end-users to have control and configure things in a wide variety of ways, without needing a programmer and without changing any XML, Java, groovy or anything. -David On May 5, 2009, at 11:43 AM, Andrew Zeneski wrote: To me this sounds like the security information is being spread out in ever more places, not consolidated. If I need to customize the authorization logic, I would much rather it be centralized and NOT in the artifacts. If it was in the artifacts, much like it is today, then customizing would require modifications to the OOTB artifacts. Which is exactly what we should be avoiding. Andrew On May 5, 2009, at 11:42 AM, Adrian Crum wrote: In the design I proposed, the configuration resides in the artifacts themselves. -Adrian Harmeet Bedi wrote: If goal is to change security without changing code or XML configuration.. the configuration has to reside somewhere. db seemed like a spot. UI would needs to show the artifacts and permission and configure groups on them. I had SecurityPermission entity extended to have SecurityResource(Artifact) and SecurityActionType(e.g. access) If the issue is that should there be no static check and collect resources to seed db, instead to it dynamically it would be fine. It would make things dynamic and configuration friendly while still taking config out of xml. Harmeet - Original Message - From: "Adrian Crum" To: dev@ofbiz.apache.org Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern Subject: Re: Domain Based Security ( was re: Authz...) Harmeet Bedi wrote: Ofbiz has the graph metadata of artifacts but navigating graph to dynamically determine will be expensive. It doesn't have to be. If we end up using the artifact info stuff for some kind of security administration screen, we can set up the artifact gathering code to go only as deep as what is currently being displayed. In other words, the artifact gathering could be more dynamic. As the user navigates farther down the graph, additional parsing is done. This would eliminate the need to graph all artifacts in one step. I agree with David that storing the graph in the database is a bad idea. -Adrian
Re: Domain Based Security ( was re: Authz...)
The problem I see with this is that in an artifact based system we are forced to implement security on that fine level of granularity. Where in a process based system, the process can be defined as granular as necessary for the application. Only when very fine level of granularity is needed would it be necessary. The level of control in a process model is as great as the application needs but is much easier to understand for administration and configuration. Andrew On May 5, 2009, at 4:28 PM, Adrian Crum wrote: Andrew Zeneski wrote: To me a process driven model is far more comprehendible to an average application administrator, where an artifact based would be way more technical. An administrator would need to understand all the artifacts in the application in order to configure things properly. Where in a process model, the admin only needs to understand the process involved and the artifacts are associated to the process during development. That's a very good point. The design I proposed was based on network administration - where every network resource can have permissions attached to it and there is a great level of control. So yes, it is technical. -Adrian
Re: Domain Based Security ( was re: Authz...)
On May 5, 2009, at 5:24 PM, David E Jones wrote: Well, this is starting to sound exactly like what I proposed, with the exception that in my proposal everything would be tied to a "process" rather than an artifact. The process of "updating a party record" is attached to the artifacts which are involved in the process, then permission logic is attached (by database configuration) to that very same process. I'm not sure what you mean by this... which proposal are you referring to? If it is the main one you documented and implemented I think there are some big differences here, mainly that the artifacts themselves do not have anything in them for configuring access control (permissions, etc), not even specifying a "process" that they are part of, and instead the external stuff where access control is configured refers to the artifacts. Yes, the same proposal I have been talking about from the beginning. While you are correct that the current implementation and proposal does not have a specific method of "registering" artifacts with the process, instead it is using the current patterns to check access to for the process within the artifact. In the end, this is all exactly the same thing, registering an artifact and adding authorization logic to the artifact's framework or calling the same functionality from within the artifact is all really just a matter of aesthetics. So, this is something which could be added to any system which is developed. To me a process driven model is far more comprehendible to an average application administrator, where an artifact based would be way more technical. An administrator would need to understand all the artifacts in the application in order to configure things properly. Where in a process model, the admin only needs to understand the process involved and the artifacts are associated to the process during development. Defining the processes involved in an application is something which should be done during design. During implementation, all that needs to be addressed is associating the artifacts to the correct process. In my opinion security should be thought of as a business level requirement, putting it on the artifact is too technical. Screens and forms are very much business level artifacts in my opinion, and it does seem like for the most part when people ask about configuring access control they have specific screens, forms, form fields, etc in mind. I agree that a rendered screen or form is a business level artifact, but a screen definition or form definition is no more a business level artifact than a Java class, XML file or JSP would be. These are very technical artifacts IMO. As for a process... what is that anyway (I mean on a conceptual level, putting it in terms that should be understandable by someone not familiar with what you're working on, and not even familiar with OFBiz)? Is it a way of grouping screens or other artifacts? If so, that's fine, in fact that's great, and it's one of many ways of grouping artifacts to help deal with the fact that at that level of granularity there are a lot of options to deal with (people usually ask for it before realizing how many options there really are). I gave an example of a process at the top of my message. Another example would be "update a party's email address". In this process there is a service (usually one, but not always) a screen, a form, some fields, etc. In the current authz implementation these artifacts would call their respected methods of checking access to that process, however as I mentioned above this could easily be changed to be part of the artifact's framework, so that an artifact would then register itself with the process. Again, this really won't effectively be much different than calling the existing has-permission method(s). So, while yes I guess it is a way of grouping artifacts, I never considered it as such. I've always thought of it simply as the artifacts are all used in a specific process (or processes). Anyway, to explore the "process" concept further in general a single artifact (such as a screen) is typically used in more than one business process. All that means is that a single artifact can be a member of more than one artifact group and if the user has access to any of those artifact groups they have access to that screen. On the other hand, if that is too liberal (which it seems to me, ie it might allow access where it isn't intended) then we may need to restrict it more. What I mean by that is the term "process" to me might mean that they can use a certain screen (or other artifact) as part of that process, but not as part of any other process or for any other reason. If that's the case then we need something else in the project to keep track of which "process" the user is currently in... and that would be kind of lik
Apology to David (was re: Authz API Discussion)
David, I would like to publicly apologize for my behavior this past weekend. While I do not believe you (or anyone else) has the right to revert any commit which does not directly effect the build or ability to run the trunk without first discussing with the author and giving them a chance to correct/revert the changes themselves; I also do not believe I should have responded to you the way I did. For that I wish to offer you my sincerest apology. I do not believe your actions were a direct attack on me personally, I responded abruptly in the heat of the moment. Having worked together on OFBiz for the last 8 years we both should have been able to rectify any differences without offending one another. Again, I apologize or not acting appropriately. Andrew On May 3, 2009, at 4:00 PM, Andrew Zeneski wrote: Inline... Please don't revert the rest of the code. The point is that this needs time to mature, so it should stay in there but not become the default... not YET anyway. I will leave the what was implemented alone for the time being. Also, please don't be personally offended by this. Just because there are comments and feedback doesn't mean something has no merit, it just means that some adjustments to it might be able to improve it. That's what collaboration is all about, and I guess if you'd rather not do it than have other people comments on it and make changes to it then collaboration will be difficult. I am not offended by any comments or feedback, I was only offended by your actions. Reverting the example was nothing more than a power move by you. You can argue this if you wish, but the fact is nothing else except for an example was effected, and there has been no discussion by anyone to revert anything yet. If you did feel that it was problematic, it should have been brought up if not to the community then at least to me personally. Just to clear that up... are you saying you would rather not do any of this than make some changes and refinements to it based on feedback? I hope that's not the case. My intent with this, as I explained in my email, is to make a compromise and allow development and improvement on this to continue without impact on other parts of the project until it is more ready for that. Your assumptions (as assumptions often are) completely wrong. Even though say now you hope this isn't the case, you have publicly accused me of this in your Notes On Security Changes document. What have I been doing for the past week? It surely wasn't moving ahead and checking in changes to all the applications to use a new authorization pattern. What I have been doing is acquiring additional needs/requirements comparing them to what I have planned and trying to discuss with the community these changes. Refining the API and including the requirements which I have gathered. You keep claiming that this new pattern is less flexible. While that may (but I don't agree) be true to a certain extent, is it also far MORE flexible when it comes to creating custom implementations for vertical, custom or customized applications. Andrew
Re: Plan on deprecating old themes
I like the idea of keeping 2 themes +1 to this. It shows the support for themes but also limits the amount of maintenance required. +1 for flatgrey, I fall back to that whenever another theme gives me trouble. Andrew On May 6, 2009, at 1:02 PM, Jacques Le Roux wrote: For several reason, I really appreciate sometimes to have the good old theme (Flat Grey) at hand. We could keep Flat Grey and the best known at the moment (obviously BiznessTime at the moment). The others would stay at http://docs.ofbiz.org/x/yhQ This would be an easy deprecation policy Jacques From: "Adrian Crum" There were differing opinions about them. I suggested having only one theme in OFBiz, and the other themes could be provided outside the project - by theme providers. David thought it would be good to have several themes in the project in order to demonstrate the theme idea. From my perspective, having more than one theme in the project means that much more code that has to be maintained. As far as I know, no "theme deprecation" plan has been discussed. -Adrian Tim Ruppert wrote: I may have missed this in general, but what is the plan to deprecate themes when people aren't supporting them any longer? We've already got one that we want to do this to - and there will surely be others as we're trying to work out these backend interfaces. Anyways, my vote would be community votes and just removing them - but I'd love to hear what the original intention was and other good ideas out there. Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595
Re: Brainstorming: Security Requirements/Scenarios
Even if we were to continue to debate a process vs artifact based system, the list below would pretty much be the same (s/artifact/ process/gi). That said, I think the list is fairly complete and I can't think of anything else to add at this moment. Andrew On May 6, 2009, at 3:51 PM, David E Jones wrote: I think the discussion about the "process" versus "artifact" has resulted in consideration of a "process" as one way to group artifacts, so there is no need for separate items on this list that explicitly handle processes (ie they are handled implicitly). Please let me know if I'm misunderstanding that (especially Andrew, you've been a big proponent of the process side of things). On that note, are there any other patterns or specific security requirements that others would like to discuss? I don't think this is the sort of thing where we need to discuss the merits of each, unless someone thinks that we shouldn't bother with supporting any of these patterns. These should just be "socked away" somewhere and used while we're doing the design so we have something to evaluate the design alternatives to, and make sure they handle all of these scenarios (or that we decide that a non-supported scenario is not important). -David On May 4, 2009, at 11:28 AM, David E Jones wrote: This thread is specifically for discussing security requirements and security use scenarios to drive OFBiz security functionality going forward. Please keep other discussion in another thread. These things tend to fall into two categories: functionality access and record-level access, or a combination of both. That is a high level generalization so just warning you that what I list below may be limited by my own blindness since I usually think in terms of those two things for security configuration. In other words, that's the point of this brainstorming thread. To get things started, here are a few I can think of and have heard from others, these are in no particular order: 1. User X can use Artifact Y for anything that artifacts supports and on any data (where "artifact" is a screen, web page, part of a screen or page, service, general logic, etc) 2. User X can use Artifact Y only for records determined by Constraint Z 3. User X can use any artifact for records determined by Constraint Z 4. Artifact Y can be used by any user for any purpose it supports 5. Artifact Y can be used by any user for only for records determined by Constraint Z 6. User X can use any artifact for any record (ie superuser) Okay, you can see that my initial pass at this is sort of an enumeration of combinations effort. If you can think of other general scenarios, please share! Also, please feel free to share specific requirements that are not in such generic terms (we can worry about putting them in more generic terms like this later). Thank You! -David
Re: svn commit: r772780 - in /ofbiz/trunk/applications/party: ofbiz-component.xml servicedef/mcas.xml servicedef/services.xml src/org/ofbiz/party/communication/CommunicationEventServices.java
Indeed it is :) Rev 772850 and 772851 improve it even more by adding
support to catch bounce messages on newsletter marketing emails (the
ones which don't create unique communication events per email) and
invalidating an email address from the contact list when it bounces.
Andrew
On May 7, 2009, at 7:21 PM, David E Jones wrote:
Very cool new feature!
-David
On May 7, 2009, at 3:29 PM, j...@apache.org wrote:
Author: jaz
Date: Thu May 7 21:29:06 2009
New Revision: 772780
URL: http://svn.apache.org/viewvc?rev=772780&view=rev
Log:
implemented service to process bounced emails and update the
communication event status
Added:
ofbiz/trunk/applications/party/servicedef/mcas.xml
Modified:
ofbiz/trunk/applications/party/ofbiz-component.xml
ofbiz/trunk/applications/party/servicedef/services.xml
ofbiz/trunk/applications/party/src/org/ofbiz/party/communication/
CommunicationEventServices.java
Modified: ofbiz/trunk/applications/party/ofbiz-component.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/ofbiz-component.xml?rev=772780&r1=772779&r2=772780&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/applications/party/ofbiz-component.xml (original)
+++ ofbiz/trunk/applications/party/ofbiz-component.xml Thu May 7
21:29:06 2009
@@ -34,7 +34,8 @@
location="servicedef/services.xml"/>
location="servicedef/services_view.xml"/>
-
+location="servicedef/mcas.xml"/>
+
http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/servicedef/mcas.xml?rev=772780&view=auto
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/applications/party/servicedef/mcas.xml (added)
+++ ofbiz/trunk/applications/party/servicedef/mcas.xml Thu May 7
21:29:06 2009
@@ -0,0 +1,28 @@
+
+
+
+http://www.w3.org/2001/XMLSchema-instance";
+xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/service-mca.xsd
">
+
+
+
+
+
+
Modified: ofbiz/trunk/applications/party/servicedef/services.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/servicedef/services.xml?rev=772780&r1=772779&r2=772780&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/applications/party/servicedef/services.xml (original)
+++ ofbiz/trunk/applications/party/servicedef/services.xml Thu May
7 21:29:06 2009
@@ -93,7 +93,10 @@
name="Person"
location="org.ofbiz.party.party.PartyServices"
invoke="updatePerson" auth="true">
Update a Person
-name="partyGroupPermissionCheck" main-action="UPDATE"/>
+
+
+
+
attributes>
mode="IN" optional="true"/>
@@ -1167,4 +1170,10 @@
optional="true"/>
optional="false"/>
+
+
++
location="org.ofbiz.party.communication.CommunicationEventServices"
invoke="processBouncedMessage">
+
+
Modified: ofbiz/trunk/applications/party/src/org/ofbiz/party/
communication/CommunicationEventServices.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/src/org/ofbiz/party/communication/CommunicationEventServices.java?rev=772780&r1=772779&r2=772780&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/applications/party/src/org/ofbiz/party/
communication/CommunicationEventServices.java (original)
+++ ofbiz/trunk/applications/party/src/org/ofbiz/party/
communication/CommunicationEventServices.java Thu May 7 21:29:06
2009
@@ -31,8 +31,12 @@
import java.util.Map;
import java.util.Set;
import java.util.TreeSet;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
import javax.mail.Address;
+import javax.mail.BodyPart;
+import javax.mail.Header;
import javax.mail.MessagingException;
import javax.mail.Multipart;
import javax.mail.Part;
@@ -946,4 +950,115 @@
}
return attachmentCount;
}
+
+/*
+ * Service to process incoming email and look for a bounce
message. If the email is indeed a bounce message
+ * the CommunicationEvent will be updated with the proper
COM_BOUNCED status.
+ */
+public static Map
processBouncedMessage(DispatchContext dctx, MapObject> context) {
+Debug.logInfo("Running process bounced message check...",
module);
+MimeMessageWrapper wrapper = (MimeMessageWrapper)
context.get("messageWrapper");
+MimeMessage message = wrapper.getMessage();
+
+LocalDispatcher dispatcher = dctx.getDispatcher();
+GenericDelegator delegator = dctx.getDelegator();
+
+try {
+Object content = message.getContent();
+if (content instanceof Multipart) {
+Multipart mp = (Multipart) content;
+int parts = mp.getCount();
+
+if (parts >= 3) { // it must
Re: svn commit: r774178 - in /ofbiz/trunk/framework/service/src/org/ofbiz/service/mail: JavaMailContainer.java MimeMessageWrapper.java
My pleasure Hans! Just doing some refactoring so we can better track
the status of a communication event. You can now embed $
{communicationEventId} inside the email message. This should help with
opt-out and other types of tracking.
Andrew
On May 12, 2009, at 11:12 PM, Hans Bakker wrote:
Hi Andrew,
excellent improvements here in the email section of the ofbiz system,
thanks for your help in this area.
Regards,
Hans
On Wed, 2009-05-13 at 03:05 +, j...@apache.org wrote:
Author: jaz
Date: Wed May 13 03:05:00 2009
New Revision: 774178
URL: http://svn.apache.org/viewvc?rev=774178&view=rev
Log:
more improvements to the message wrapper logic for getting
attachments and reading multipart messages; added methods to get
headers; mail container now marks messages which are too big to
process (the max size setting) as read (but never deleted) so they
are not always being checked but remain in the mailbox for human
review
Modified:
ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/
JavaMailContainer.java
ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/
MimeMessageWrapper.java
Modified: ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/
JavaMailContainer.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/JavaMailContainer.java?rev=774178&r1=774177&r2=774178&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/
JavaMailContainer.java (original)
+++ ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/
JavaMailContainer.java Wed May 13 03:05:00 2009
@@ -305,17 +305,22 @@
long messageSize = message.getSize();
if (message instanceof MimeMessage &&
messageSize >= maxSize) {
Debug.logWarning("Message from: " +
message.getFrom()[0] + "not received, too big, size:" + messageSize
+ " cannot be more than " + maxSize + " bytes", module);
+
+// set the message as read so it doesn't
continue to try to process; but don't delete it
+message.setFlag(Flags.Flag.SEEN, true);
} else {
this.processMessage(message, session);
if (Debug.verboseOn())
Debug.logVerbose("Message from " +
UtilMisc.toListArray(message.getFrom()) + " with subject [" +
message.getSubject() + "] has been processed." , module);
message.setFlag(Flags.Flag.SEEN, true);
if (Debug.verboseOn())
Debug.logVerbose("Message [" + message.getSubject() + "] is marked
seen", module);
+
+// delete the message after processing
+if (deleteMail) {
+if (Debug.verboseOn())
Debug.logVerbose("Message [" + message.getSubject() + "] is being
deleted", module);
+message.setFlag(Flags.Flag.DELETED,
true);
+}
}
-}
-if (deleteMail) {
-if (Debug.verboseOn())
Debug.logVerbose("Message [" + message.getSubject() + "] is being
deleted", module);
-message.setFlag(Flags.Flag.DELETED, true);
-}
+}
}
// expunge and close the folder
Modified: ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/
MimeMessageWrapper.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/MimeMessageWrapper.java?rev=774178&r1=774177&r2=774178&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/
MimeMessageWrapper.java (original)
+++ ofbiz/trunk/framework/service/src/org/ofbiz/service/mail/
MimeMessageWrapper.java Wed May 13 03:05:00 2009
@@ -122,6 +122,24 @@
return message;
}
+public String getFirstHeader(String header) {
+String[] headers = getHeader(header);
+if (headers != null && headers.length > 0) {
+return headers[0];
+} else {
+return null;
+}
+}
+public String[] getHeader(String header) {
+MimeMessage message = getMessage();
+try {
+return message.getHeader(header);
+} catch (MessagingException e) {
+Debug.logError(e, module);
+return null;
+}
+}
+
public Address[] getFrom() {
MimeMessage message = getMessage();
try {
@@ -235,14 +253,16 @@
String idx = Integer.toString(i);
if (subPartCount > 0) {
for (int si = 0; si < subPartCount; si++) {
-String sidx = idx + "." +
Integer.toString(si);
-if (getPartDisposition(sidx) != n
Re: svn commit: r778988 - in /ofbiz/trunk/applications/party: data/PartyTypeData.xml webapp/partymgr/communication/CommForms.xml
Hans,
This change has broken the functionality which marks outgoing (email)
communication events as read when the user opens the message. The
functionality uses the markCommEventRead which still references the
COM_READ status. Before removing something from a data file, please
make sure you have searched and updated all the code which references
that data.
Doing a quick search for COM_ROLE_READ I am not finding any logic
which ties this in yet. So, either this service needs to be updated,
or we need to add back in the COM_READ status and the
StatusValidChange records.
Please let me know your plans for this.
Andrew
On May 27, 2009, at 12:20 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed May 27 04:20:31 2009
New Revision: 778988
URL: http://svn.apache.org/viewvc?rev=778988&view=rev
Log:
added comments to commevent status, removed the COM_READ status as
COM_ROLE_READ status is now used
Modified:
ofbiz/trunk/applications/party/data/PartyTypeData.xml
ofbiz/trunk/applications/party/webapp/partymgr/communication/
CommForms.xml
Modified: ofbiz/trunk/applications/party/data/PartyTypeData.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/data/PartyTypeData.xml?rev=778988&r1=778987&r2=778988&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/applications/party/data/PartyTypeData.xml (original)
+++ ofbiz/trunk/applications/party/data/PartyTypeData.xml Wed May 27
04:20:31 2009
@@ -300,27 +300,22 @@
statusTypeId="CASE_STATUS"/>
parentTypeId="" statusTypeId="COM_EVENT_STATUS"/>
-statusCode="ENTERED" statusId="COM_ENTERED"
statusTypeId="COM_EVENT_STATUS"/>
-statusCode="PENDING" statusId="COM_PENDING"
statusTypeId="COM_EVENT_STATUS"/>
-statusCode="READ" statusId="COM_READ"
statusTypeId="COM_EVENT_STATUS"/>
-statusCode="IN_PROGRESS" statusId="COM_IN_PROGRESS"
statusTypeId="COM_EVENT_STATUS"/>
-statusCode="UNKNOWN_PARTY" statusId="COM_UNKNOWN_PARTY"
statusTypeId="COM_EVENT_STATUS"/>
+statusCode="PENDING" statusId="COM_PENDING"
statusTypeId="COM_EVENT_STATUS"/>
+statusCode="ENTERED" statusId="COM_ENTERED"
statusTypeId="COM_EVENT_STATUS"/>
+
+statusCode="IN_PROGRESS" statusId="COM_IN_PROGRESS"
statusTypeId="COM_EVENT_STATUS"/>
+statusCode="UNKNOWN_PARTY" statusId="COM_UNKNOWN_PARTY"
statusTypeId="COM_EVENT_STATUS"/>
statusCode="COMPLETE" statusId="COM_COMPLETE"
statusTypeId="COM_EVENT_STATUS"/>
statusCode="RESOLVED" statusId="COM_RESOLVED"
statusTypeId="COM_EVENT_STATUS"/>
statusCode="REFERRED" statusId="COM_REFERRED"
statusTypeId="COM_EVENT_STATUS"/>
statusCode="BOUNCED" statusId="COM_BOUNCED"
statusTypeId="COM_EVENT_STATUS"/>
statusCode="CANCELLED" statusId="COM_CANCELLED"
statusTypeId="COM_EVENT_STATUS"/>
-statusIdTo="COM_PENDING" transitionName="Set Pending"/>
-statusIdTo="COM_READ" transitionName="Read"/>
+statusIdTo="COM_PENDING" transitionName="Set Pending, only visible
to originator"/>
statusIdTo="COM_COMPLETE" transitionName="Complete"/>
-statusIdTo="COM_READ" transitionName="Read"/>
-statusIdTo="COM_IN_PROGRESS" transitionName="Set In Progress"/>
-statusIdTo="COM_IN_PROGRESS" transitionName="Set In Progress"/>
-statusIdTo="COM_COMPLETE" transitionName="Complete"/>
-statusIdTo="COM_READ" transitionName="Read"/>
+statusIdTo="COM_ENTERED" transitionName="Entered,visible to all
participants"/>
+statusIdTo="COM_IN_PROGRESS" transitionName="Set In Progress,
waiting to be send"/>
statusIdTo="COM_COMPLETE" transitionName="Complete"/>
statusIdTo="COM_BOUNCED" transitionName="Bounced"/>
-statusIdTo="COM_READ" transitionName="Read"/>
statusIdTo="COM_RESOLVED" transitionName="Resolve"/>
statusIdTo="COM_REFERRED" transitionName="Refer"/>
statusIdTo="COM_BOUNCED" transitionName="Bounced"/>
@@ -330,7 +325,6 @@
statusIdTo="COM_CANCELLED" transitionName="Cancel"/>
statusIdTo="COM_CANCELLED" transitionName="Cancel"/>
-statusIdTo="COM_CANCELLED" transitionName="Cancel"/>
statusIdTo="COM_CANCELLED" transitionName="Cancel"/>
statusIdTo="COM_CANCELLED" transitionName="Cancel"/>
statusIdTo="COM_CANCELLED" transitionName="Cancel"/>
Modified: ofbiz/trunk/applications/party/webapp/partymgr/
communication/CommForms.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/webapp/partymgr/communication/CommForms.xml?rev=778988&r1=778987&r2=778988&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/applications/party/webapp/partymgr/communication/
CommForms.xml (original)
+++ ofbiz/trunk/applications/party/webapp/partymgr/communication/
CommForms.xml Wed May 27 04:20:31 2009
@@ -193,7 +193,7 @@
when="communicationEvent!=null">
target-type="plain" description="$
{uiLabelMap.CommonSend}"
-
Re: svn commit: r778988 - in /ofbiz/trunk/applications/party: data/PartyTypeData.xml webapp/partymgr/communication/CommForms.xml
Sure Hans,
I documented this in rev 774634 but here it is again:
"Implemented a little event which marks a communication event as read,
and returns a 1px gif image (spacer.gif) to the browser/mail client;
include the following in your communication email:
http://localhost:8080/partymgr/control/ceimages/$
{communicationEventId}/logo.gif"/>
and when the message is opened, the event will be marked as read
(assuming images are loaded); logo.gif can be any name, everything
after the communication event ID in pathInfo is ignored "
So to test this just call the event, like you did but add the path info:
http://localhost:8080/partymgr/control/ceimages/[communication event
Id]/logo.gif
I'll fix the NPE, so it just does nothing with out a communication
event ID. What this should do is mark the recipient role as read.
Andrew
On Jun 4, 2009, at 12:35 AM, Hans Bakker wrote:
Hi Andy,
thanks for reporting this. I should have found this, sorry about that.
I have now updated the e-commerce component in rev 781649 and add the
messages to the top menu to make this more visible.
One thing i did update and could not test very well is
communicationEventServices.java, there is service which is called by
an
external request and is called: markCommunicationAsRead
i tried to do the request:
http://localhost:8080/partymgr/control/ceimages
but get a null pointer exception at line 1223
perhaps you can explain how this service should work and perhaps can
help here?
Regards,
Hans
On Wed, 2009-06-03 at 13:39 -0400, Andrew Zeneski wrote:
Hans,
This change has broken the functionality which marks outgoing (email)
communication events as read when the user opens the message. The
functionality uses the markCommEventRead which still references the
COM_READ status. Before removing something from a data file, please
make sure you have searched and updated all the code which references
that data.
Doing a quick search for COM_ROLE_READ I am not finding any logic
which ties this in yet. So, either this service needs to be updated,
or we need to add back in the COM_READ status and the
StatusValidChange records.
Please let me know your plans for this.
Andrew
On May 27, 2009, at 12:20 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed May 27 04:20:31 2009
New Revision: 778988
URL: http://svn.apache.org/viewvc?rev=778988&view=rev
Log:
added comments to commevent status, removed the COM_READ status as
COM_ROLE_READ status is now used
Modified:
ofbiz/trunk/applications/party/data/PartyTypeData.xml
ofbiz/trunk/applications/party/webapp/partymgr/communication/
CommForms.xml
Modified: ofbiz/trunk/applications/party/data/PartyTypeData.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/data/PartyTypeData.xml?rev=778988&r1=778987&r2=778988&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/applications/party/data/PartyTypeData.xml (original)
+++ ofbiz/trunk/applications/party/data/PartyTypeData.xml Wed May 27
04:20:31 2009
@@ -300,27 +300,22 @@
-
-
-
-
-
+
+
+
+
+
-
-
+
-
-
-
-
-
+
+
-
@@ -330,7 +325,6 @@
-
Modified: ofbiz/trunk/applications/party/webapp/partymgr/
communication/CommForms.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/party/webapp/partymgr/communication/CommForms.xml?rev=778988&r1=778987&r2=778988&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/applications/party/webapp/partymgr/communication/
CommForms.xml (original)
+++ ofbiz/trunk/applications/party/webapp/partymgr/communication/
CommForms.xml Wed May 27 04:20:31 2009
@@ -193,7 +193,7 @@
+target="javascript:
(document.EditInternalNote.statusId.value='COM_ENTERED'),
(document.EditInternalNote.datetimeStarted.value='${nowDate}'),
(document.EditInternalNote.submit())"/>
--
Antwebsystems.com: Quality OFBiz services for competitive rates
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r587109 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilMisc.java
I cannot say exactly how much damage it causes, but since this is as
far as the framework will compile, I figured it was time for a quick
patch. If you have a better fix, please by all means check it in.
Otherwise, let's just make sure we can compile the trunk without errors.
Andrew
-
classes:
[javac] Compiling 15 source files to /Users/jaz/Sandbox/
kickstartr/framework/entityext/build/classes
[javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:305:
cannot find symbol
[javac] symbol : method runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map initialHistoryRes = dispatcher.runSync
("createEntitySyncHistory", UtilMisc.toMap("entitySyncId",
entitySyncId, "runStatusId", "ESR_RUNNING", "beginningSynchTime",
this.currentRunStartTime, "lastCandidateEndTime",
this.currentRunEndTime, "userLogin", userLogin));
[javac] ^
[javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:745:
cannot find symbol
[javac] symbol : method runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map updateEsRunResult = dispatcher.runSync
("updateEntitySyncRunning", UtilMisc.toMap("entitySyncId",
entitySyncId, "lastSuccessfulSynchTime", this.currentRunEndTime,
"userLogin", userLogin));
[javac] ^
[javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:797:
cannot find symbol
[javac] symbol : method runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map completeEntitySyncRes =
dispatcher.runSync("updateEntitySyncRunning", UtilMisc.toMap
("entitySyncId", entitySyncId, "runStatusId", newStatusId,
"userLogin", userLogin));
[javac] ^
[javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:811:
cannot find symbol
[javac] symbol : method runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map deleteEntitySyncHistRes =
dispatcher.runSync("deleteEntitySyncHistory", UtilMisc.toMap
("entitySyncId", entitySyncId, "startDate", startDate, "userLogin",
userLogin));
[javac] ^
[javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:822:
cannot find symbol
[javac] symbol : method runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map completeEntitySyncHistRes =
dispatcher.runSync("updateEntitySyncHistory", UtilMisc.toMap
("entitySyncId", entitySyncId, "startDate", startDate, "runStatusId",
"ESR_COMPLETE", "userLogin", userLogin));
[javac] ^
[javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:945:
cannot find symbol
[javac] symbol : method runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map errorEntitySyncRes = dispatcher.runSync
("updateEntitySyncRunning", UtilMisc.toMap("entitySyncId",
entitySyncId, "runStatusId", runStatusId, "userLogin", userLogin));
[javac]^
[javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:954:
cannot find symbol
[javac] symbol : method runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map errorEntitySyncHistoryRes =
dispatcher.runSync("updateEntitySyncHistory", UtilMisc.toMap
("entitySyncId", entitySyncId, "startDate", startDate, "runStatusId",
runStatusId, "userLogin", userLogin));
[javac] ^
[javac] /Users/jaz/Sandbox/kickstartr/framework/entityext/src/
org/ofbiz/entityext/synchronization/EntitySyncContext.java:979:
cannot find symbol
[javac] symbol : method runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map startEntitySyncRes = dispatcher.runSync
("updateEntitySyncRunning", UtilMisc.toMap("entitySyncId",
entitySyncId, "runStatusId", "ESR_RUNNING", "userLogin", us
Re: svn commit: r586925 [1/2] - in /ofbiz/trunk: applications/accounting/src/org/ofbiz/accounting/finaccount/ applications/accounting/src/org/ofbiz/accounting/invoice/ applications/accounting/src/org/
I agree. I do not want to see this becoming a pain. However, the changes I put into UtilMisc to seem to have solved this problem (at least for the entity sync code). Not saying its the best fix, but for me UtilMisc.toMap() is just not an option. Andrew On Oct 22, 2007, at 4:00 AM: From: David E Jones <[EMAIL PROTECTED]> Date: October 21, 2007 4:38:14 PM EDT To: dev@ofbiz.apache.org Subject: Re: svn commit: r586925 [1/2] - in /ofbiz/trunk: applications/accounting/src/org/ofbiz/accounting/finaccount/ applications/accounting/src/org/ofbiz/accounting/invoice/ applications/accounting/src/org/ofbiz/accounting/payment/ applications/content/src On Oct 21, 2007, at 1:04 PM, Adam Heath wrote: Scott Gray wrote: That looks like a PITA, do we have to include on all toMap calls now? No. == Map context = UtilMisc.toMap(); dispatcher.runSync(serviceName, context); == It's only when you have it inline that it is a problem. javac is not currently smart enough when it comes to type-inference; I've discussed this with the openjdk people, and they confirmed it. If any part of the line uses generics, then javac attempts to make all parts use it. It javac applied type-erasure to the return of toMap, *and* to the call to runSync, then it would be able to find a matching method to call. I'm interested in hearing other opinions, but I think this is a good reason to delay our use of generics for certain things, especially for things that should be minimally cumbersome, like dispatcher calls with UtilMisc.toMap inline, which is really the primary use scenario for the toMap method... Hopefully this new feature in Java will mature more in the near future, but in the mean time we shouldn't be too aggressive in adopting and using it. I know the intentions are good, but the result is what is important. I'm all for progress, but from a pragmatic perspective only. -David smime.p7s Description: S/MIME cryptographic signature
Back on the list
I wasn't on this list since my vacation in July. Reading the digests is just a major PITA. If there are outstanding questions/issues for me, please re-send. Thanks! Andrew smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r587109 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilMisc.java
I use javac 1.5.0_07 (Apple OSX build 1.5.0_07-164), but I have also
seen this with 1.5.0_04 on Linux as well. The error comes from a
total clean build.
Notice that in EntitySyncContext there are a number of inline
UtilMisc calls which were never changed. You made a number of changes
to other files, but not this one.
What JDK are you using?
On Oct 25, 2007, at 6:24 PM, Adam Heath wrote:
Adam Heath wrote:
Andrew Zeneski wrote:
I cannot say exactly how much damage it causes, but since this is
as far
as the framework will compile, I figured it was time for a quick
patch.
If you have a better fix, please by all means check it in.
Otherwise,
let's just make sure we can compile the trunk without errors.
Andrew
-
classes:
[javac] Compiling 15 source files to
/Users/jaz/Sandbox/kickstartr/framework/entityext/build/classes
[javac]
/Users/jaz/Sandbox/kickstartr/framework/entityext/src/org/ofbiz/
entityext/synchronization/EntitySyncContext.java:305:
cannot find symbol
[javac] symbol : method
runSync
(java.lang.String,java.util.Map)
[javac] location: interface org.ofbiz.service.LocalDispatcher
[javac] Map initialHistoryRes =
dispatcher.runSync("createEntitySyncHistory",
UtilMisc.toMap("entitySyncId", entitySyncId, "runStatusId",
"ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime,
"lastCandidateEndTime", this.currentRunEndTime, "userLogin",
userLogin));
Everything compiles for me. I don't check in unless things compile.
What javac are you using? I use java 1.6 normally. I just tried
with
java 1.5, and it worked as well. 1.5 had a few more warnings, but
those
aren't errors.
[resend]
So, Andy, are you going to respond to this, or what?
smime.p7s
Description: S/MIME cryptographic signature
Re: JAZ- [Fwd: Re: svn commit: r586582 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java]
No more of a specialized usage which may be useful elsewhere. Its
just a static worker method.. :)
On Oct 25, 2007, at 6:34 PM, Tim Ruppert wrote:
This probably has to do with that whole backward compatibility
thing would be my guess.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Oct 25, 2007, at 4:24 PM, Adrian Crum wrote:
From: Adrian Crum <[EMAIL PROTECTED]>
Date: October 19, 2007 1:59:54 PM MDT
To: dev@ofbiz.apache.org, [EMAIL PROTECTED]
Subject: Re: svn commit: r586582 - /ofbiz/trunk/framework/base/src/
base/org/ofbiz/base/util/UtilDateTime.java
Reply-To: dev@ofbiz.apache.org
Why would you want to do that? The calling method should have a
TimeZone and Locale object available. Any code that uses this
method will get unpredictable results.
-Adrian
[EMAIL PROTECTED] wrote:
Author: jaz
Date: Fri Oct 19 12:09:27 2007
New Revision: 586582
URL: http://svn.apache.org/viewvc?rev=586582&view=rev
Log:
added adjustTimestamp method which doesn't require timezone or
locale
Modified:
ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java
Modified: ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/
base/org/ofbiz/base/util/UtilDateTime.java?
rev=586582&r1=586581&r2=586582&view=diff
==
--- ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java (original)
+++ ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java Fri Oct 19 12:09:27 2007
@@ -771,6 +771,10 @@
return new Timestamp(tempCal.getTimeInMillis());
}
+public static Timestamp adjustTimestamp(Timestamp stamp,
int adjType, int adjQuantity) {
+return adjustTimestamp(stamp, adjType, adjQuantity,
null, null);
+}
+
public static Timestamp getDayStart(Timestamp stamp,
TimeZone timeZone, Locale locale) {
return getDayStart(stamp, 0, timeZone, locale);
}
smime.p7s
Description: S/MIME cryptographic signature
Re: JAZ- [Fwd: Re: svn commit: r586582 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java]
This method is to use an int offset to adjust the timestamp, without a locale or timezone. That's it. No hidden meanings here. It uses Integer instead of int since Freemarker doesn't wrap primitives. On Oct 25, 2007, at 7:05 PM, Adrian Crum wrote: Andrew Zeneski wrote: The predicted results will be a timestamp adjusted with with the specific amount specified, without a timezone available. Just a helper method. I used it on a system which is set to GMT and requires dates be displayed in the customer facing in the customer's timezone. The timezone is read as an offset (in javascript) and then adjusted on the fly as needed. There is no TimeZone object available, all we know is how many minutes off GMT. Andrew The commit log mentions calling this from Freemarker. There are Locale and TimeZone objects in the Freemarker context. In addition, I'm pretty sure that no matter where you are in the code execution path, you have access to Locale and TimeZone objects. -Adrian smime.p7s Description: S/MIME cryptographic signature
Re: JAZ- [Fwd: Re: svn commit: r586582 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java]
The predicted results will be a timestamp adjusted with with the
specific amount specified, without a timezone available. Just a
helper method.
I used it on a system which is set to GMT and requires dates be
displayed in the customer facing in the customer's timezone. The
timezone is read as an offset (in javascript) and then adjusted on
the fly as needed. There is no TimeZone object available, all we know
is how many minutes off GMT.
Andrew
On Oct 25, 2007, at 6:24 PM, Adrian Crum wrote:
From: Adrian Crum <[EMAIL PROTECTED]>
Date: October 19, 2007 3:59:54 PM EDT
To: dev@ofbiz.apache.org, [EMAIL PROTECTED]
Subject: Re: svn commit: r586582 - /ofbiz/trunk/framework/base/src/
base/org/ofbiz/base/util/UtilDateTime.java
Reply-To: dev@ofbiz.apache.org
Why would you want to do that? The calling method should have a
TimeZone and Locale object available. Any code that uses this
method will get unpredictable results.
-Adrian
[EMAIL PROTECTED] wrote:
Author: jaz
Date: Fri Oct 19 12:09:27 2007
New Revision: 586582
URL: http://svn.apache.org/viewvc?rev=586582&view=rev
Log:
added adjustTimestamp method which doesn't require timezone or locale
Modified:
ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java
Modified: ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/
base/org/ofbiz/base/util/UtilDateTime.java?
rev=586582&r1=586581&r2=586582&view=diff
=
=
--- ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java (original)
+++ ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java Fri Oct 19 12:09:27 2007
@@ -771,6 +771,10 @@
return new Timestamp(tempCal.getTimeInMillis());
}
+public static Timestamp adjustTimestamp(Timestamp stamp, int
adjType, int adjQuantity) {
+return adjustTimestamp(stamp, adjType, adjQuantity, null,
null);
+}
+
public static Timestamp getDayStart(Timestamp stamp, TimeZone
timeZone, Locale locale) {
return getDayStart(stamp, 0, timeZone, locale);
}
smime.p7s
Description: S/MIME cryptographic signature
Re: JAZ- [Fwd: Re: svn commit: r586582 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java]
I disagree. Personally I like methods with optional arguments, especially when these arguments aren't really necessary. When you do not pass the extra arguments, the assumption should be that you get the defaults (default Locale and default TimeZone) which is fine. In addition, this method was mainly put there for the use of Integer instead of int, since the primitive cannot be used inside an FTL. Andrew On Oct 25, 2007, at 7:16 PM, Adrian Crum wrote: Andrew, I understand what the method does. The point I'm trying to make is this: It is not needed and it provides a way to introduce inconsistent data into the project. I understand the method solves a problem for a particular client, but it's not a good thing to include in the project. There is a discussion on Jira about this: https://issues.apache.org/jira/browse/OFBIZ-1361 -Adrian Andrew Zeneski wrote: This method is to use an int offset to adjust the timestamp, without a locale or timezone. That's it. No hidden meanings here. It uses Integer instead of int since Freemarker doesn't wrap primitives. On Oct 25, 2007, at 7:05 PM, Adrian Crum wrote: Andrew Zeneski wrote: The predicted results will be a timestamp adjusted with with the specific amount specified, without a timezone available. Just a helper method. I used it on a system which is set to GMT and requires dates be displayed in the customer facing in the customer's timezone. The timezone is read as an offset (in javascript) and then adjusted on the fly as needed. There is no TimeZone object available, all we know is how many minutes off GMT. Andrew The commit log mentions calling this from Freemarker. There are Locale and TimeZone objects in the Freemarker context. In addition, I'm pretty sure that no matter where you are in the code execution path, you have access to Locale and TimeZone objects. -Adrian smime.p7s Description: S/MIME cryptographic signature
Re: Dates, Times, Internationalization, and the UtilDateTime class
Just my two cents here, I do not want everything to depend on a user selecting his timezone. There are many cases where we will no want to force this dependency. The main case being customer facing applications where the webmaster does not want to impose this requirement on their users. This was a requirement imposed on me and I see no reason why it wouldn't happen again. It is always common for webmasters to do all it takes to require less from their users. This was solved by obtaining the number of minutes from GMT offset in javascript (getTimezoneOffset()). Since we had no way to get a TimeZone string from javascript (only the number of minutes) the only way to do this was to pull the number of minutes and adjust the current time (which in this case, server time was GMT). The method I added to UtilDateTime was to help with this, but now I see it can be greatly improved. I think this method will be very useful. One thing which needs to change, is since the minutes offset is based on GMT, we need to make sure the Timestamp is set to GMT time, before the adjustment is made. This will give us a valid time in the user's timezone without a TimeZone object. I think it is good, to support the user selected TimeZone, but we should also look at methods which require this to be automated. In this case, no TimeZone object will be available in the session, but we can always get the number of minutes offset passed through from the browser. On Oct 27, 2007, at 4:19 PM, Adrian Crum wrote: Prior to the recent work done to bring user-selected time zones into the project, OFBiz pretty much ignored a user's time zone and locale and performed date/time calculations based upon the server's locale and time zone. This caused problems for international users - as the previous links point out. smime.p7s Description: S/MIME cryptographic signature
Re: Hate to dump this one on you
I don't think your credit is due to the fact it was not in stock, the credit was probably a promotion. The inventory settings can be set one of two ways: 1. Accept the order, which would place the items not available on back order (still charges the full price) 2. Do not accept the order, or rather do not allow out of stock items to be added to the cart. Sounds like you are setup for #1, in which case the only thing I would be concerned about is why there was an adjustment for 1 item. This could very well have been a promotion, which would solve that issue. Andrew On Oct 31, 2007, at 1:38 AM, [EMAIL PROTECTED] wrote: This bug is a show-stopper I think. Create an order for 1 WG- and 5 GZ-1001 to DemoCustCompany on a billing account (don't know if that makes a difference). Note that you have 0 ATP and OnHand on the GZ-1001 Complete the order. On the final screen, note that the order is for $122.91 (before promos tax and shipping). It should have been for 18.95, the cost of the single WG-. Your subtotal is for 1 WG- and 4 GZ-1001 (one is credited as an adjustment) This should have credit all 5 items that were not in stock instead of the one. Skip smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r590554 - /ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/login/LoginEvents.java
Yep.
On Oct 31, 2007, at 5:32 AM, Jacques Le Roux wrote:
Hi Andy,
Just for my information, it is intended to add an UI later ?
Jacques
Author: jaz
Date: Tue Oct 30 21:33:50 2007
New Revision: 590554
URL: http://svn.apache.org/viewvc?rev=590554&view=rev
Log:
added code which uses "rememberMe" parameter to store a cookie with
the user's login ID
Modified:
ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/
login/LoginEvents.java
Modified: ofbiz/trunk/applications/securityext/src/org/ofbiz/
securityext/login/LoginEvents.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/login/LoginEvents.java?rev=590554&r1=590553&r2=590554&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/
login/LoginEvents.java (original)
+++ ofbiz/trunk/applications/securityext/src/org/ofbiz/securityext/
login/LoginEvents.java Tue Oct 30 21:33:50 2007
@@ -22,6 +22,7 @@
import java.util.Iterator;
import java.util.Map;
+import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
@@ -53,6 +54,7 @@
public static final String module = LoginEvents.class.getName();
public static final String resource = "SecurityextUiLabels";
+public static final String usernameCookieName =
"OFBiz.Username";
/**
* Save USERNAME and PASSWORD for use by auth pages even if we
start in non-auth pages.
@@ -342,7 +344,41 @@
if (!"success".equals(responseString)) {
return responseString;
}
+if ("Y".equals(request.getParameter("rememberMe"))) {
+setUsername(request, response);
+}
// if we logged in okay, do the check store customer role
return ProductEvents.checkStoreCustomerRole(request,
response);
}
-}
+
+public static String getUsername(HttpServletRequest request) {
+String cookieUsername = null;
+Cookie[] cookies = request.getCookies();
+if (Debug.verboseOn()) Debug.logVerbose("Cookies:" +
cookies, module);
+if (cookies != null) {
+for (int i = 0; i < cookies.length; i++) {
+if
(cookies[i].getName().equals(usernameCookieName)) {
+cookieUsername = cookies[i].getValue();
+break;
+}
+}
+}
+return cookieUsername;
+}
+
+public static void setUsername(HttpServletRequest request,
HttpServletResponse response) {
+HttpSession session = request.getSession();
+String domain =
UtilProperties.getPropertyValue("url.properties", "cookie.domain");
+// first try to get the username from the cookie
+synchronized (session) {
+if (UtilValidate.isEmpty(getUsername(request))) {
+// create the cookie and send it back
+Cookie cookie = new Cookie(usernameCookieName,
request.getParameter("USERNAME"));
+cookie.setMaxAge(60 * 60 * 24 * 365);
+cookie.setPath("/");
+cookie.setDomain(domain);
+response.addCookie(cookie);
+}
+}
+}
+}
\ No newline at end of file
smime.p7s
Description: S/MIME cryptographic signature
Re: pool-lifetime and sleeptime
These may actually not be used anymore. I think these were settings for the old XAPool library we were using a few years ago. To confirm, you will want to check all the classes which read these settings and see if they are actually used. Andrew On Nov 6, 2007, at 6:15 AM, Jacques Le Roux wrote: Hi, I wonder what exactly for this entity-engine parameters are useful for (default to respectively 10 and 5 min.) ? Thanks Jacques smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Move from Beanshell to Groovy
+1 On May 21, 2008, at 1:08 AM, David E Jones wrote: This is a vote based on the recent discussion thread for changing the OFBiz best practice tool for writing data preparation scripts from using Beanshell to using Groovy, and more generally making Groovy the standard scripting language wherever generic scripting is needed, even as a way to implement services (as a secondary best practice to using simple-methods). This sort of decision is perhaps not totally necessary to vote on, but does have a big impact on the project and many people involved, so a vote should help draw opinions and lead the community toward the best decision possible. Please vote: [+1] Yes, replace Beanshell with Groovy [+0] I'm not for, but I'm not against [-1] No, stick to Beanshell and don't migrate toward Groovy Many comments were brought up in the discussion thread, but addition comments related to your vote are welcome. As per usual everyone is welcome to vote and express opinions though only PMC votes are binding. -David smime.p7s Description: S/MIME cryptographic signature
Re: [Fwd: svn commit: r510756 - /ofbiz/trunk/applications/content/webapp/content/WEB-INF/controller.xml]
Yes, I am 100% sure. I put it there initially for this reason, but then found that when the directed happened it would die when the text date was more than the limit of HTTP GET. This caused the whole process to blow up and ended up causing the same problem I was trying to avoid. So, in this case when the HTTP POST data exceeds the HTTP GET limitations, we can't use the redirect. The redirect w/ no parameters fails since the screen does require certain parameters. Andrew On Feb 27, 2007, at 2:35 PM, Si Chen wrote: Andy - Are you sure about getting rid of the request-redirect? If the user accidentally hits the refresh button on his browser he'd resubmit a request twice. We've noticed this is a very common source of errors for users. Si From: [EMAIL PROTECTED] Date: February 22, 2007 8:46:19 PM EST To: commits@ofbiz.apache.org Subject: svn commit: r510756 - /ofbiz/trunk/applications/content/ webapp/content/WEB-INF/controller.xml Reply-To: dev@ofbiz.apache.org Author: jaz Date: Thu Feb 22 17:46:18 2007 New Revision: 510756 URL: http://svn.apache.org/viewvc?view=rev&rev=510756 Log: got rid of request-direct returns, not needed and cause problems with large amounts of data Modified: ofbiz/trunk/applications/content/webapp/content/WEB-INF/ controller.xml Modified: ofbiz/trunk/applications/content/webapp/content/WEB-INF/ controller.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/content/ webapp/content/WEB-INF/controller.xml? view=diff&rev=510756&r1=510755&r2=510756 == --- ofbiz/trunk/applications/content/webapp/content/WEB-INF/ controller.xml (original) +++ ofbiz/trunk/applications/content/webapp/content/WEB-INF/ controller.xml Thu Feb 22 17:46:18 2007 @@ -280,7 +280,7 @@ -value="WebSiteCms"/> + @@ -292,7 +292,7 @@ -value="WebSiteCms"/> +
Re: [VOTE] Create Release Branch for Version 4.0
In the plan I see no process for tagging. Even though branching and tagging in SVN are technically the same, its common practice to not change a tag once it is created. I think we should add one step to the procedure to tag each actual release from the branch. The branch for example 4.0 remains the 4.x branch. All patches to this branch AFTER a release would go into 4.1 or 4.0.1 minor bug fixes, once the bug fixes are enough to justify a new release of the 4.x series. Other than that one small comment +1 on creating the branch! Andrew On Apr 21, 2007, at 12:19 AM, David E. Jones wrote: I forgot to mention: we will leave this vote open for at least 24 hours. If we don't have the requisite 3 PMC votes in favor at that time the time period will be extended. -David On Apr 20, 2007, at 10:05 PM, David E. Jones wrote: This is a vote to create a release branch now (or whenever the vote concludes) according to the plan described here: http://docs.ofbiz.org/display/OFBADMIN/Release+Plan The proposed version number for this release is 4.0. This was previously agreed on to happen today, but I think a vote on it is in order before we actually do so. Please vote +1, +0, or -1, and comment as needed. Thanks, -David smime.p7s Description: S/MIME cryptographic signature
Re: UI Refactoring progress
Very nice work! I took a look at the patch in JIRA and found it to be a very nice improvement! Good job. Andrew p.s. Thanks for fixing whatever I did... :0 On Apr 23, 2007, at 1:22 PM, Adrian Crum wrote: A lot of progress has been made since the last update. The Webtools and Accounting components have been refactored. One of the committers re-introduced deprecated styles in the Webtools component (*cough* Andrew *cough*) so I had to go through it again. Committers - please watch out for this. Let's not go backwards. The masthead (header), main navigation bar, and footer have been refactored. The new HTML markup makes the page layout extremely flexible. For instance, you can now move the masthead, main navigation, and footer to other locations on the screen, just by making a few changes to the main style sheet. If you have been updating your local copy of OFBiz regularly, you probably get the impression that the main navigation bar is having an identity crisis. Actually, we're just trying to come up with a style that everyone likes. If anyone would like to contribute their own style, they are welcome to do so. I submitted a new style for the project which has gotten some initial positive feedback - https://issues.apache.org/jira/browse/ OFBIZ-918. Go check it out and vote for it if you like it. The refactoring effort has made a serious impact on the amount of markup generated. Pages that used to contain 100 to 200 DIVs now have 12 to 20. Looking to the future - I started taking a look at the Order and Product components. They have hundreds of files and I believe some of them are shared with the eCommerce component. I'm not sure where to go from here on those two. If I refactor them, then that might break eCommerce - since its style sheet doesn't contain the new styles. I'm working on some ideas for a collapsible masthead. It will enable a user to free up more screen space. I hope to take a look at the menu widget soon. I'd like to have it support nested menus - so that we can have fancy cascaded or flyout menus. -Adrian smime.p7s Description: S/MIME cryptographic signature
Re: UI Refactoring progress
Adrian, Are the images you included in your JIRA bundle free for use? Andrew On Apr 23, 2007, at 1:22 PM, Adrian Crum wrote: A lot of progress has been made since the last update. The Webtools and Accounting components have been refactored. One of the committers re-introduced deprecated styles in the Webtools component (*cough* Andrew *cough*) so I had to go through it again. Committers - please watch out for this. Let's not go backwards. The masthead (header), main navigation bar, and footer have been refactored. The new HTML markup makes the page layout extremely flexible. For instance, you can now move the masthead, main navigation, and footer to other locations on the screen, just by making a few changes to the main style sheet. If you have been updating your local copy of OFBiz regularly, you probably get the impression that the main navigation bar is having an identity crisis. Actually, we're just trying to come up with a style that everyone likes. If anyone would like to contribute their own style, they are welcome to do so. I submitted a new style for the project which has gotten some initial positive feedback - https://issues.apache.org/jira/browse/ OFBIZ-918. Go check it out and vote for it if you like it. The refactoring effort has made a serious impact on the amount of markup generated. Pages that used to contain 100 to 200 DIVs now have 12 to 20. Looking to the future - I started taking a look at the Order and Product components. They have hundreds of files and I believe some of them are shared with the eCommerce component. I'm not sure where to go from here on those two. If I refactor them, then that might break eCommerce - since its style sheet doesn't contain the new styles. I'm working on some ideas for a collapsible masthead. It will enable a user to free up more screen space. I hope to take a look at the menu widget soon. I'd like to have it support nested menus - so that we can have fancy cascaded or flyout menus. -Adrian smime.p7s Description: S/MIME cryptographic signature
Re: UI Refactoring progress
Nice job... Andrew On Apr 23, 2007, at 5:46 PM, Adrian Crum wrote: Yes, of course. I granted the license to it all. Andrew Zeneski wrote: Adrian, Are the images you included in your JIRA bundle free for use? Andrew On Apr 23, 2007, at 1:22 PM, Adrian Crum wrote: A lot of progress has been made since the last update. The Webtools and Accounting components have been refactored. One of the committers re-introduced deprecated styles in the Webtools component (*cough* Andrew *cough*) so I had to go through it again. Committers - please watch out for this. Let's not go backwards. The masthead (header), main navigation bar, and footer have been refactored. The new HTML markup makes the page layout extremely flexible. For instance, you can now move the masthead, main navigation, and footer to other locations on the screen, just by making a few changes to the main style sheet. If you have been updating your local copy of OFBiz regularly, you probably get the impression that the main navigation bar is having an identity crisis. Actually, we're just trying to come up with a style that everyone likes. If anyone would like to contribute their own style, they are welcome to do so. I submitted a new style for the project which has gotten some initial positive feedback - https://issues.apache.org/jira/ browse/ OFBIZ-918. Go check it out and vote for it if you like it. The refactoring effort has made a serious impact on the amount of markup generated. Pages that used to contain 100 to 200 DIVs now have 12 to 20. Looking to the future - I started taking a look at the Order and Product components. They have hundreds of files and I believe some of them are shared with the eCommerce component. I'm not sure where to go from here on those two. If I refactor them, then that might break eCommerce - since its style sheet doesn't contain the new styles. I'm working on some ideas for a collapsible masthead. It will enable a user to free up more screen space. I hope to take a look at the menu widget soon. I'd like to have it support nested menus - so that we can have fancy cascaded or flyout menus. -Adrian smime.p7s Description: S/MIME cryptographic signature
Re: UI Refactoring progress
I hit send too fast. Again, nice job, I personally would like to see this as the default L&F, is a vote in order for this? Andrew On Apr 23, 2007, at 5:46 PM, Adrian Crum wrote: Yes, of course. I granted the license to it all. Andrew Zeneski wrote: Adrian, Are the images you included in your JIRA bundle free for use? Andrew On Apr 23, 2007, at 1:22 PM, Adrian Crum wrote: A lot of progress has been made since the last update. The Webtools and Accounting components have been refactored. One of the committers re-introduced deprecated styles in the Webtools component (*cough* Andrew *cough*) so I had to go through it again. Committers - please watch out for this. Let's not go backwards. The masthead (header), main navigation bar, and footer have been refactored. The new HTML markup makes the page layout extremely flexible. For instance, you can now move the masthead, main navigation, and footer to other locations on the screen, just by making a few changes to the main style sheet. If you have been updating your local copy of OFBiz regularly, you probably get the impression that the main navigation bar is having an identity crisis. Actually, we're just trying to come up with a style that everyone likes. If anyone would like to contribute their own style, they are welcome to do so. I submitted a new style for the project which has gotten some initial positive feedback - https://issues.apache.org/jira/ browse/ OFBIZ-918. Go check it out and vote for it if you like it. The refactoring effort has made a serious impact on the amount of markup generated. Pages that used to contain 100 to 200 DIVs now have 12 to 20. Looking to the future - I started taking a look at the Order and Product components. They have hundreds of files and I believe some of them are shared with the eCommerce component. I'm not sure where to go from here on those two. If I refactor them, then that might break eCommerce - since its style sheet doesn't contain the new styles. I'm working on some ideas for a collapsible masthead. It will enable a user to free up more screen space. I hope to take a look at the menu widget soon. I'd like to have it support nested menus - so that we can have fancy cascaded or flyout menus. -Adrian smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r533447 - /ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/ShoppingCart.java
Good catch, thanks for fixing this!
Andrew
On Apr 28, 2007, at 8:08 PM, [EMAIL PROTECTED] wrote:
Author: jonesde
Date: Sat Apr 28 17:08:16 2007
New Revision: 533447
URL: http://svn.apache.org/viewvc?view=rev&rev=533447
Log:
Fixed NPE in new finAccountId checking; now we can complete a
checkout again
Modified:
ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/
ShoppingCart.java
Modified: ofbiz/trunk/applications/order/src/org/ofbiz/order/
shoppingcart/ShoppingCart.java
URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/
src/org/ofbiz/order/shoppingcart/ShoppingCart.java?
view=diff&rev=533447&r1=533446&r2=533447
==
--- ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/
ShoppingCart.java (original)
+++ ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/
ShoppingCart.java Sat Apr 28 17:08:16 2007
@@ -4319,9 +4319,15 @@
public int compareTo(Object o) {
CartPaymentInfo that = (CartPaymentInfo) o;
Debug.logInfo("Compare [" + this.toString() + "] to ["
+ that.toString() + "]", module);
-if (!this.finAccountId.equals(that.finAccountId)) {
-return -1;
+
+if (this.finAccountId == null) {
+if (that.finAccountId != null) {
+return -1;
+}
+} else if (!this.finAccountId.equals
(that.finAccountId)) {
+return -1;
}
+
if (this.paymentMethodId != null) {
if (that.paymentMethodId == null) {
return 1;
smime.p7s
Description: S/MIME cryptographic signature
Re: [VOTE] Require Java SDK 5 (Java 1.5)
+0.9 On Apr 28, 2007, at 7:51 PM, David E. Jones wrote: Now that we have done a release branch (liberating in a way, isn't it?) should we move forward and require Java SDK 5 to run OFBiz? I think the time passed a while ago where it was safe to do this. Version 6 of the SDK is out now, and all platforms that I'm aware of (even Apache Harmony) are SDK 5 compatible. So, let's vote! -David smime.p7s Description: S/MIME cryptographic signature
Re: Upgrading to javolution 4.2.8
Jacopo,
I attempted this a few months ago but ran into some serious problems
with the entity import (EntitySaxReader) operations. My patch (which
at first glance) looked at lot like yours, but 100% of the time throw
out of memory issues which importing data (from scratch). Can you
test your patch and see if you have any of the same problems?
Andrew
On Apr 30, 2007, at 4:31 AM, Jacopo Cappellato wrote:
Sorry,
here is the patch.
Jacopo Cappellato wrote:
What about upgrading the javolution jar from 3.1.1 to 4.2.8
(latest stable release)?
I'm testing it and the attached patch contains the changes needed
by the upgrade.
Jacopo
Index: framework/base/src/base/org/ofbiz/base/util/collections/
MapStack.java
===
--- framework/base/src/base/org/ofbiz/base/util/collections/
MapStack.java (revisione 533556)
+++ framework/base/src/base/org/ofbiz/base/util/collections/
MapStack.java (copia locale)
@@ -27,7 +27,7 @@
import java.util.Set;
import javolution.lang.Reusable;
-import javolution.realtime.ObjectFactory;
+import javolution.context.ObjectFactory;
import javolution.util.FastList;
import javolution.util.FastMap;
import javolution.util.FastSet;
Index: framework/entity/src/org/ofbiz/entity/GenericPK.java
===
--- framework/entity/src/org/ofbiz/entity/GenericPK.java (revisione
533556)
+++ framework/entity/src/org/ofbiz/entity/GenericPK.java (copia
locale)
@@ -20,7 +20,7 @@
import java.util.Map;
-import javolution.realtime.ObjectFactory;
+import javolution.context.ObjectFactory;
import org.ofbiz.entity.model.ModelEntity;
Index: framework/entity/src/org/ofbiz/entity/GenericValue.java
===
--- framework/entity/src/org/ofbiz/entity/GenericValue.java
(revisione 533556)
+++ framework/entity/src/org/ofbiz/entity/GenericValue.java (copia
locale)
@@ -25,7 +25,7 @@
import java.util.Map;
import javolution.lang.Reusable;
-import javolution.realtime.ObjectFactory;
+import javolution.context.ObjectFactory;
import javolution.util.FastMap;
import org.ofbiz.base.util.Debug;
Index: framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java
===
--- framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java
(revisione 533556)
+++ framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java
(copia locale)
@@ -35,10 +35,11 @@
import freemarker.template.Template;
import freemarker.template.TemplateException;
import freemarker.template.TemplateHashModel;
-import javolution.lang.Text;
+import javolution.text.CharArray;
+import javolution.text.Text;
import javolution.util.FastMap;
import javolution.xml.sax.Attributes;
-import javolution.xml.sax.RealtimeParser;
+import javolution.xml.sax.XMLReaderImpl;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Node;
@@ -217,7 +218,8 @@
}
*/
-RealtimeParser parser = new RealtimeParser(16384);
+//RealtimeParser parser = new RealtimeParser(16384);
+XMLReaderImpl parser = new XMLReaderImpl();
parser.setContentHandler(this);
parser.setErrorHandler(this);
@@ -280,7 +282,7 @@
public void endDocument() throws org.xml.sax.SAXException {}
-public void endElement(CharSequence namespaceURI, CharSequence
localName, CharSequence fullName) throws org.xml.sax.SAXException {
+public void endElement(CharArray namespaceURI, CharArray
localName, CharArray fullName) throws org.xml.sax.SAXException {
if (Debug.verboseOn()) Debug.logVerbose("endElement:
localName=" + localName + ", fullName=" + fullName + ",
numberRead=" + numberRead, module);
String fullNameString = fullName.toString();
if ("entity-engine-xml".equals(fullNameString)) {
@@ -402,24 +404,24 @@
}
}
-public void endPrefixMapping(CharSequence prefix) throws
org.xml.sax.SAXException {}
+public void endPrefixMapping(CharArray prefix) throws
org.xml.sax.SAXException {}
public void ignorableWhitespace(char[] values, int offset, int
count) throws org.xml.sax.SAXException {
// String value = new String(values, offset, count);
// Debug.logInfo("ignorableWhitespace: value=" + value,
module);
}
-public void processingInstruction(CharSequence target,
CharSequence instruction) throws org.xml.sax.SAXException {}
+public void processingInstruction(CharArray target, CharArray
instruction) throws org.xml.sax.SAXException {}
public void setDocumentLocator(org.xml.sax.Locator locator) {
this.locator = locator;
}
-public void skippedEntity(CharSequence name) throws
org.xml.sax.SAXException {}
+public void skippedEntity(CharArray name) throws
org.xml.sax.SAXException {}
public void startDocument() throw
Re: Upgrading to javolution 4.2.8
I was using 1.4 and a 1.4 compiled version of javolution maybe that was *my* problem... On Apr 30, 2007, at 5:29 AM, Jacopo Cappellato wrote: David, that's great, thanks. I will quickly test and then commit if it is good; of course after the vote to upgrade to java 1.5 has passed, because this version of javolution requires it. For now it seems to work fine (I run "ant run-install" etc...) Do you think that adding the overloaded methods to the EntitySaxReader class is better than changing the signatures (like I did)? David E. Jones wrote: Your patch looks pretty similar to the one I started a while ago to update this (included below). I did things slightly different with the EntitySaxReader. I didn't commit this at the time because something wasn't working right, but I don't remember what. I was working against 4.2.5 and it may be that the problem was in that version of Javolution. Anyway, if OFBiz loads fine and basic stuff like a checkout in ecommerce actually works, and in this case a entity XML import as well, then yeah it would be great to get this updated. -David On Apr 30, 2007, at 2:29 AM, Jacopo Cappellato wrote: What about upgrading the javolution jar from 3.1.1 to 4.2.8 (latest stable release)? I'm testing it and the attached patch contains the changes needed by the upgrade. Jacopo === Index: framework/base/lib/javolution.jar === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: framework/base/lib/javolution-4.2.5.jar === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Property changes on: framework/base/lib/javolution-4.2.5.jar ___ Name: svn:mime-type + application/octet-stream Index: framework/base/src/base/org/ofbiz/base/util/collections/ MapStack.java === --- framework/base/src/base/org/ofbiz/base/util/collections/ MapStack.java(revision 510441) +++ framework/base/src/base/org/ofbiz/base/util/collections/ MapStack.java(working copy) @@ -26,8 +26,8 @@ import java.util.Map; import java.util.Set; +import javolution.context.ObjectFactory; import javolution.lang.Reusable; -import javolution.realtime.ObjectFactory; import javolution.util.FastList; import javolution.util.FastMap; import javolution.util.FastSet; Index: framework/entity/src/org/ofbiz/entity/GenericPK.java === --- framework/entity/src/org/ofbiz/entity/GenericPK.java (revision 510441) +++ framework/entity/src/org/ofbiz/entity/GenericPK.java (working copy) @@ -20,7 +20,7 @@ import java.util.Map; -import javolution.realtime.ObjectFactory; +import javolution.context.ObjectFactory; import org.ofbiz.entity.model.ModelEntity; Index: framework/entity/src/org/ofbiz/entity/GenericValue.java === --- framework/entity/src/org/ofbiz/entity/GenericValue.java (revision 510441) +++ framework/entity/src/org/ofbiz/entity/GenericValue.java (working copy) @@ -24,8 +24,8 @@ import java.util.List; import java.util.Map; +import javolution.context.ObjectFactory; import javolution.lang.Reusable; -import javolution.realtime.ObjectFactory; import javolution.util.FastMap; import org.ofbiz.base.util.Debug; Index: framework/entity/src/org/ofbiz/entity/util/ EntitySaxReader.java === --- framework/entity/src/org/ofbiz/entity/util/ EntitySaxReader.java(revision 510441) +++ framework/entity/src/org/ofbiz/entity/util/ EntitySaxReader.java(working copy) @@ -29,21 +29,11 @@ import java.util.List; import java.util.Map; -import freemarker.ext.beans.BeansWrapper; -import freemarker.ext.dom.NodeModel; -import freemarker.template.Configuration; -import freemarker.template.Template; -import freemarker.template.TemplateException; -import freemarker.template.TemplateHashModel; -import javolution.lang.Text; +import javolution.text.CharArray; +import javolution.text.Text; import javolution.util.FastMap; import javolution.xml.sax.Attributes; -import javolution.xml.sax.RealtimeParser; -import org.w3c.dom.Document; -import org.w3c.dom.Element; -import org.w3c.dom.Node; -import org.xml.sax.ErrorHandler; -import org.xml.sax.SAXException; +import javolution.xml.sax.XMLReaderImpl; import org.ofbiz.base.util.Base64; import org.ofbiz.base.util.Debug; @@ -57,7 +47,19 @@ import org.ofbiz.entity.model.ModelField; import org.ofbiz.entity.transaction.GenericTransactionException; import org.ofbiz.entity.transaction.TransactionUtil; +import org.w3c.dom.Document; +import org.w3c.dom.Element; +import org.w3c.dom.Node; +import org.x
Re: [VOTE][Result] Require Java SDK 5 (Java 1.5)
Is 1.5 slower to compile than 1.4 for others or is it just me? Andrew On Apr 30, 2007, at 8:40 PM, David E. Jones wrote: Looks like this was a popular item... here are the results: +1 PMC - 3: David, Jacopo, Andrew +1 commiters - 3: Scott Gray, Tim Ruppert, Jacques Le Roux +1 contributors - 6: Anil Patel, Chris Howe, Vinay Agarwal, BJ Freeman, Joe Eckard, Marco Risaliti +0 - 0 -1 - 0 The vote passed with the necessary 3 PMC +1 votes. Please note that we are working on adding more people to the PMC to help get higher PMC involvement with such votes in the future. Thanks for the participation from everyone! Based on this the policy going forward will be that OFBiz requires a Java SDK 5 (1.5) series JDK to run. Documentation and other changes will be made over time. As for Java 6/1.6 we will test that over time and try to support it soon, but it will probably be quite a while before it is required, and for big requirements like that there will be another vote like this. -David On Apr 28, 2007, at 5:51 PM, David E. Jones wrote: Now that we have done a release branch (liberating in a way, isn't it?) should we move forward and require Java SDK 5 to run OFBiz? I think the time passed a while ago where it was safe to do this. Version 6 of the SDK is out now, and all platforms that I'm aware of (even Apache Harmony) are SDK 5 compatible. So, let's vote! -David smime.p7s Description: S/MIME cryptographic signature
Re: Upgrading to javolution 4.2.8
I see the update, nice work! I'm happy to see that updated. They had a number of performance improvements since the last version we were using. Andrew On May 1, 2007, at 5:00 AM, Jacopo Cappellato wrote: Maybe java 1.4 was the issue. With the latest javolution release java 1.5+ is required and with it I could run "ant run-install" without issues. Jacopo David E. Jones wrote: Yes, I was trying to maintain the 1.4 compatibility too, hopefully it will work better without that... ;) -David On Apr 30, 2007, at 3:40 PM, Andrew Zeneski wrote: I was using 1.4 and a 1.4 compiled version of javolution maybe that was *my* problem... On Apr 30, 2007, at 5:29 AM, Jacopo Cappellato wrote: David, that's great, thanks. I will quickly test and then commit if it is good; of course after the vote to upgrade to java 1.5 has passed, because this version of javolution requires it. For now it seems to work fine (I run "ant run-install" etc...) Do you think that adding the overloaded methods to the EntitySaxReader class is better than changing the signatures (like I did)? David E. Jones wrote: Your patch looks pretty similar to the one I started a while ago to update this (included below). I did things slightly different with the EntitySaxReader. I didn't commit this at the time because something wasn't working right, but I don't remember what. I was working against 4.2.5 and it may be that the problem was in that version of Javolution. Anyway, if OFBiz loads fine and basic stuff like a checkout in ecommerce actually works, and in this case a entity XML import as well, then yeah it would be great to get this updated. -David On Apr 30, 2007, at 2:29 AM, Jacopo Cappellato wrote: What about upgrading the javolution jar from 3.1.1 to 4.2.8 (latest stable release)? I'm testing it and the attached patch contains the changes needed by the upgrade. Jacopo === Index: framework/base/lib/javolution.jar == = Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: framework/base/lib/javolution-4.2.5.jar == = Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Property changes on: framework/base/lib/javolution-4.2.5.jar __ _ Name: svn:mime-type + application/octet-stream Index: framework/base/src/base/org/ofbiz/base/util/collections/ MapStack.java == = --- framework/base/src/base/org/ofbiz/base/util/collections/ MapStack.java(revision 510441) +++ framework/base/src/base/org/ofbiz/base/util/collections/ MapStack.java(working copy) @@ -26,8 +26,8 @@ import java.util.Map; import java.util.Set; +import javolution.context.ObjectFactory; import javolution.lang.Reusable; -import javolution.realtime.ObjectFactory; import javolution.util.FastList; import javolution.util.FastMap; import javolution.util.FastSet; Index: framework/entity/src/org/ofbiz/entity/GenericPK.java == = --- framework/entity/src/org/ofbiz/entity/GenericPK.java (revision 510441) +++ framework/entity/src/org/ofbiz/entity/GenericPK.java (working copy) @@ -20,7 +20,7 @@ import java.util.Map; -import javolution.realtime.ObjectFactory; +import javolution.context.ObjectFactory; import org.ofbiz.entity.model.ModelEntity; Index: framework/entity/src/org/ofbiz/entity/GenericValue.java == = --- framework/entity/src/org/ofbiz/entity/GenericValue.java (revision 510441) +++ framework/entity/src/org/ofbiz/entity/GenericValue.java (working copy) @@ -24,8 +24,8 @@ import java.util.List; import java.util.Map; +import javolution.context.ObjectFactory; import javolution.lang.Reusable; -import javolution.realtime.ObjectFactory; import javolution.util.FastMap; import org.ofbiz.base.util.Debug; Index: framework/entity/src/org/ofbiz/entity/util/ EntitySaxReader.java == = --- framework/entity/src/org/ofbiz/entity/util/ EntitySaxReader.java(revision 510441) +++ framework/entity/src/org/ofbiz/entity/util/ EntitySaxReader.java(working copy) @@ -29,21 +29,11 @@ import java.util.List; import java.util.Map; -import freemarker.ext.beans.BeansWrapper; -import freemarker.ext.dom.NodeModel; -import freemarker.template.Configuration; -import freemarker.template.Template; -import freemarker.template.TemplateException; -import freemarker.template.TemplateHashModel; -import javolution.lang.Text; +import javolution.text.CharArray; +import javolution.text.Text; import javolution.
