Simple-method-test-suite
Hi All, In a test def I would like to be able to specify a entire file of simple-method tests where every simple method in the file would be run in succession similar to how junit-test-suite works where every method in a class is run as a test. The way I see it there are two options: 1. Remove the requirement that the simple-method-test element must provide a simple method name to run. If it is omitted then then every simple method should be run. 2. Add a new element simple-method-test-suite specifically for this purpose. The goal here is to make tests a little easier to write. Thanks Scott HotWax Media http://www.hotwaxmedia.com smime.p7s Description: S/MIME cryptographic signature
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
[jira] Updated: (OFBIZ-2414) links not unique when the same screen containing the same form is used more than once.
[ https://issues.apache.org/jira/browse/OFBIZ-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Bakker updated OFBIZ-2414: --- Summary: links not unique when the same screen containing the same form is used more than once. (was: links not unique when the same sacreen containing the same form is used more than once.) > links not unique when the same screen containing the same form is used more > than once. > -- > > Key: OFBIZ-2414 > URL: https://issues.apache.org/jira/browse/OFBIZ-2414 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: Release Branch 9.04 >Reporter: Hans Bakker > Fix For: Release Branch 9.04 > > > This is a problem also present in the old renderer. > If a screen is included more than once and it has the same form, the form > hyperlinks, which are now html forms have id's which are not unique in the > total html result. This problem is solved in the menu renderer but not in the > form renderer. > This problem shows when a "mycommunication" portlet is added twice to the > same portal page in order to show the email of 2 different users. If i click > on the 'subject' of am email, nothing happens because the id of the > underlaying hyperlink form is not unique. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2414) links not unique when the same sacreen containing the same form is used more than once.
links not unique when the same sacreen containing the same form is used more than once. --- Key: OFBIZ-2414 URL: https://issues.apache.org/jira/browse/OFBIZ-2414 Project: OFBiz Issue Type: Sub-task Affects Versions: Release Branch 9.04 Reporter: Hans Bakker Fix For: Release Branch 9.04 This is a problem also present in the old renderer. If a screen is included more than once and it has the same form, the form hyperlinks, which are now html forms have id's which are not unique in the total html result. This problem is solved in the menu renderer but not in the form renderer. This problem shows when a "mycommunication" portlet is added twice to the same portal page in order to show the email of 2 different users. If i click on the 'subject' of am email, nothing happens because the id of the underlaying hyperlink form is not unique. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Authz API Discussion (was re: svn commit: r770084)
Understood. I remember sitting next to you at the developer's conference, and watching you work. I experienced firsthand your "masochistic urge to work on something which did not already have some sort of design." I asked you for help, and you gave me links that pointed me right to the answer. I really appreciated that. I admire you and I respect you. Please understand that. Before I got involved with OFBiz I worked as an independent programmer - I didn't have to answer to anyone. I could do my own thing. Like you, I had the "masochistic urge to work on something which did not already have some sort of design." I didn't consult with anyone - I just came up with a design and wrote the code for it. Working with the OFBiz community has taught me the value of community. It has changed my ways. I started off with suggesting my "superior designs" (that I emailed to David, and I am embarrassed to read today) and they were critiqued, in a stern yet polite way. Yet I accepted those critiques. In the years that followed, David and I would disagree about many things, but I never ignored his advice or his opinions - I would always consider them carefully. So that's all I'm suggesting now. Please understand that you are respected for who you are - one of the founders of the project. Please understand that you are respected for your talent. But also, please understand that we are a community. I want to help with this effort. There is nothing that would satisfy me more than all of us working together on the refactoring of OFBiz security. All I ask is that we back off for a little while and let the community offer their comments, suggestions, and recommendations - even if it means discarding "superior designs." Together, we can take those comments, suggestions, and recommendations, and use them to redesign OFBiz security in a way that will meet the needs of the community and impress the world at large. -Adrian --- On Fri, 5/1/09, Andrew Zeneski wrote: > From: Andrew Zeneski > Subject: Re: Authz API Discussion (was re: svn commit: r770084) > To: dev@ofbiz.apache.org > Date: Friday, May 1, 2009, 9:00 PM > 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 > de
Re: Authz API Discussion (was re: svn commit: r770084)
On May 1, 2009, at 10: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. Since then more energy has been spend in trying to get answer for "Why you did not ask us first" then really understand the proposal and do constructive feedback. 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. What's wrong with that, as long as he did not disappear after committing the 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? Implementation in example component demonstrates that he is prepared to demonstrate new system and let people test and ask questions. If few things are not implemented yet then either help with them or just ask. Instead of asking to restart, its better if you ask for more complex examples that prove abilities of new system. Help evaluate instead of resisting. 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. Not always that case. 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? Project will not suffer immensely, at the same time its not suffering because code is committed to trunk. I can ask same thing to others, new system is not hurting anybody, we can still use old system. 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. There is no motivation for Andrew to do any such thing. Its always our policy to contribute maximum possible (unless clients have objections) to the community. I am really surprised and its really unfortunate that you think like this. -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)
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)
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 -
Re: ERROR: Cannot update specified contact info because it does not correspond to the specified party
This is not the right place to ask such questions.
Send your email on "OFBiz User ML " to get quick
answer on this.
For more details please read the details present on the page shown below
(Please don't repeat such mistakes):
http://docs.ofbiz.org/display/OFBADMIN/Mailing+Lists
--
Ashish
On Sat, May 2, 2009 at 2:12 AM, shuchi wrote:
>
> I was trying to Edit the User-Interface of partymgr. I added following code
> in editcontactmech.ftl
>
>
> Planet
>
> Value="${(mechMap.postalAddress.planet)!}">
>
>
>
> gives me following error.
>
> ERROR:Cannot update specified contact info because it does not correspond
> to
> the specified party. calling service updatePartyContactMech in
> updatePartyPostalAddress
>
> Please help!
>
> Thanks
> --
> View this message in context:
> http://www.nabble.com/ERROR%3A-Cannot-update-specified-contact-info-because-it-does-not-correspond-to-the-specified-party-tp23339399p23339399.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
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 smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (OFBIZ-2409) How do I use ofbiz model in banking services?
[ https://issues.apache.org/jira/browse/OFBIZ-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705215#action_12705215 ] Ashish Vijaywargiya commented on OFBIZ-2409: This is not the right place to ask such questions. You should send the questions on "OFBiz User ML ". For now I am closing this issue. For subscribing on the mailing list please refer the below link: http://docs.ofbiz.org/display/OFBADMIN/Mailing+Lists -- Ashish > How do I use ofbiz model in banking services? > - > > Key: OFBIZ-2409 > URL: https://issues.apache.org/jira/browse/OFBIZ-2409 > Project: OFBiz > Issue Type: Question > Components: accounting, order, specialpurpose/ecommerce, > specialpurpose/webpos >Affects Versions: SVN trunk > Environment: any >Reporter: bj_zhou > Fix For: SVN trunk > > > Bank account should support mutil currency(USD、EUR),and custom can > deposit/withdraw mutil currency(not only store 's default currency) cash，who > can I payin/payout cash which isn't store's default currency? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2409) How do I use ofbiz model in banking services?
[ https://issues.apache.org/jira/browse/OFBIZ-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya closed OFBIZ-2409. -- Resolution: Invalid > How do I use ofbiz model in banking services? > - > > Key: OFBIZ-2409 > URL: https://issues.apache.org/jira/browse/OFBIZ-2409 > Project: OFBiz > Issue Type: Question > Components: accounting, order, specialpurpose/ecommerce, > specialpurpose/webpos >Affects Versions: SVN trunk > Environment: any >Reporter: bj_zhou > Fix For: SVN trunk > > > Bank account should support mutil currency(USD、EUR),and custom can > deposit/withdraw mutil currency(not only store 's default currency) cash，who > can I payin/payout cash which isn't store's default currency? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2407) Functionality for "Weight Packages Only" option on pack order screen
[ https://issues.apache.org/jira/browse/OFBIZ-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705214#action_12705214 ] Ashish Vijaywargiya commented on OFBIZ-2407: >> My opinion is based on the fact that it would certainly add a dependency on >> the special purpose component. Infact, this will. This is bad practice to have dependency of applications component on specialpurpose component and we should avoid it. +1 for adding this on Common component and let's use it from there. (if it don't exists there) Thanks ! -- Ashish Vijaywargiya > Functionality for "Weight Packages Only" option on pack order screen > - > > Key: OFBIZ-2407 > URL: https://issues.apache.org/jira/browse/OFBIZ-2407 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: SVN trunk >Reporter: Pranay Pandey >Assignee: Vikas Mayur >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-2407.patch > > > Functionality for "Weight Packages Only" option on pack order screen is to > be added. > # In Facility -> Packing screens when the order entered already has a > Shipment that exists in the Picked status: add a "Weight Packages Only" > button. > # When user clicks on "Weight Packages Only" show a form with Weight input > box, optional dimension input boxes (length, width, height), optional > drop-down for pre-configured boxes (using data from ShipmentBoxType entity > and two buttons: "Next Package" and "Complete" . > # When the "Complete" button is pressed if the shipping charge is > 10%(configure in shipment.properties file, use property name > "shipment.default.cost.actual_over_estimated_percent_allowed") above the > estimated amount (the amount that would be charged to the customer). > #* The system will warn user that the shipping amount is too much there will > be a warning form with two buttons: "Ship Now" and "Hold Shipment". > #* if Ship Now is pressed the system will run as normal > #* if Hold Shipment is pressed the Shipment will remain in the Picked status, > weight/size changes will be retained, no other changes made. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Authz API Discussion (was re: svn commit: r770084)
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 > >>> > >>> > >>> > >>> > > > > > >
[jira] Commented: (OFBIZ-2404) Improved functionality of mergefromtrunk.sh
[ https://issues.apache.org/jira/browse/OFBIZ-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705213#action_12705213 ] Ashish Vijaywargiya commented on OFBIZ-2404: Thanks Buddy for committing my changes. Special thanks to Vikas for commenting on my work. -- Ashish > Improved functionality of mergefromtrunk.sh > --- > > Key: OFBIZ-2404 > URL: https://issues.apache.org/jira/browse/OFBIZ-2404 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04 >Reporter: Ashish Vijaywargiya >Assignee: Jacques Le Roux >Priority: Trivial > Fix For: Release Branch 9.04 > > Attachments: merge_from_trunk_improved.patch > > > As I discussed on the mailing list before few days to add "Log Details" from > the trunk revision number when we apply changes to release branch. > For more details you can see the discussion done on dev list with subject > "Update the log message details in mergefromtrunk.sh file ?" > Here I am uploading patch for Unix based OS (Please help me to do the same > changes in *.bat file, I am not in touch with Windows since last 4 years so > can't help much to prepare batch file) > Thanks ! > -- > Ashish Vijaywargiya -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Authz API Discussion (was re: svn commit: r770084)
Where did that come from??!! --- On Fri, 5/1/09, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: Authz API Discussion (was re: svn commit: r770084) > To: dev@ofbiz.apache.org > Date: Friday, May 1, 2009, 7:45 PM > --- On Fri, 5/1/09, Adam Heath > wrote: > > > pps: I'm very interested in the idea of this. A > single > > api to be used > > by any class for security, would be very welcome by > me. > > I'm very interested too, as well as others. I have some > ideas also. But there are a few in this thread who seem
Re: Authz API Discussion (was re: svn commit: r770084)
--- On Fri, 5/1/09, Adam Heath wrote: > Plus, if the new system can run in parallel, and classes > can be > changed over to it one at a time, then what is the big > deal? The big deal is in recoding everything. Your comment reminds me of one of David's favorite expressions - "So what if it isn't perfect, we can always refactor it later" - as if we have all the time and resources in the world to do refactorings. Btw, it's not a "fracas" - it's a gentlemanly disagreement. ;-) -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
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 smime.p7s Description: S/MIME cryptographic signature
Re: Authz API Discussion (was re: svn commit: r770084)
--- On Fri, 5/1/09, Adam Heath wrote: > pps: I'm very interested in the idea of this. A single > api to be used > by any class for security, would be very welcome by me. I'm very interested too, as well as others. I have some ideas also. But there are a few in this thread who seem
[jira] Commented: (OFBIZ-2400) Create a Portlet for leave
[ https://issues.apache.org/jira/browse/OFBIZ-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705212#action_12705212 ] Hans Bakker commented on OFBIZ-2400: In general, if you have a problem with your development, find places where it does work (what you did) but then compare it to the places that do work. In this case the portlet screen should not have a decorator and is included in a screen with a decorator which is used in the ofbiz normal interface. Regards, Hans > Create a Portlet for leave > -- > > Key: OFBIZ-2400 > URL: https://issues.apache.org/jira/browse/OFBIZ-2400 > Project: OFBiz > Issue Type: Sub-task > Components: humanres >Affects Versions: SVN trunk >Reporter: Vikas Mayur >Priority: Minor > Fix For: SVN trunk > > Attachments: PortletForLeave.patch > > > Create a portlet for leave in Humanres component. > This can be accessed from > https://localhost:8443/humanres/control/EditEmployeeLeaves?partyId=DemoCustomer > Steps: > 1) Create a new file HumanResPortletData.xml with reader-name seed. > 2) Add data for PortletCategory, PortalPortlet and PortletPortletCategory. > Refer to xxxPortletData.xml, where xxx=component name (Accounting, Party, > Order etc.) > 3) Add data for My Portal. Refer to MyPortalTypeData.xml > Note: PortletAttribute data can be added if required. > For example see the screen "ListCustRequests" > order/widget/ordermgr/RequestScreens.xml and the script under this screen > "retrievePortletAttributes.groovy" > 4) We can define a new portlet category for this component portlets. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Authz API Discussion (was re: svn commit: r770084)
Andrew Zeneski wrote: > 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. This can be summarized as release early, release often. If there are problems with the actual implementation, then, by all means, give details as to what you(not you Andrew, but whoever) take issue with. But never put down someone who is *actually coding*, and, responding to issues that are raised. Plus, if the new system can run in parallel, and classes can be changed over to it one at a time, then what is the big deal? ps: I've not actually read the document, nor actually looked at any of this new code. I'm just commenting on the resulting fracas, if I can use the term. pps: I'm very interested in the idea of this. A single api to be used by any class for security, would be very welcome by me.
Re: Authz API Discussion (was re: svn commit: r770084)
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)
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 smime.p7s Description: S/MIME cryptographic signature
Re: Authz API Discussion (was re: svn commit: r770084)
On 2/05/2009, at 1:55 PM, Adrian Crum wrote: I don't really think that is relevant, permission services were an improvement to the existing security framework, designing a new framework doesn't invalidate an improvement to the old one. Of course it is relevant! Do we need to continue to design things that ultimately have to be redesigned? "Those who ignore history are doomed to repeat it." I think there is a big difference between making an improvement to an existing framework and completely redesigning a framework. Your original comment implied that Andrew's previous work was flawed and I was trying to point out that there was nothing wrong with the last refactor, it was a perfectly valid improvement to what was in place before it. What is the problem here? Are you that convinced that Andrew's implementation is perfect? That there's no room for improvement or other opinions? In case your memory is shortening here's what I wrote previously in this thread: Will it need improvement over time? of course it will but I think it's a much better base to work from. Let me be clear, I have no problem here whatsoever, I'm just countering arguments that the community wasn't given an opportunity to be involved because it was and still does. smime.p7s Description: S/MIME cryptographic signature
Re: Authz API Discussion (was re: svn commit: r770084)
--- 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)
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. Andrew has been actively explaining his idea all this time. 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. 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. I don't see any reason why we should start over. 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. Regards Anil Patel On May 1, 2009, at 10:03 PM, Adrian Crum wrote: --- On Fri, 5/1/09, Andrew Zeneski wrote: 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. Things ARE being said. Let's start over and do this as a community. -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
--- On Fri, 5/1/09, Andrew Zeneski wrote: > 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. Things ARE being said. Let's start over and do this as a community. -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
> I don't really think that is relevant, permission > services were an improvement to the existing security > framework, designing a new framework doesn't invalidate > an improvement to the old one. Of course it is relevant! Do we need to continue to design things that ultimately have to be redesigned? "Those who ignore history are doomed to repeat it." What is the problem here? Are you that convinced that Andrew's implementation is perfect? That there's no room for improvement or other opinions? -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
The concerns were communicated and ignored, hence the Confluence page. I'm not new to this process, and I'm not suggesting anything I haven't done myself.. When I have an idea, I present it to the dev mailing list and wait for responses. If there is some interest, I post POC code in Jira (just do a search on "Sandbox:" with me as the reporter). Others are able to comment and provide patches. When everyone agrees on the change, I commit it. As far as community involvement in the new security framework is concerned, a simple check of timestamps will reveal: April 24, Confluence page created: "OFBiz Security Refactor" April 27, First mention of Security Refactor on ml: Jacques reply to "Best place for security check?" April 28, Jira OFBIZ-2380 created: "Security Re-Implementation" April 29, SVN commit 769928: "implementation of new authorization (authz) functionality" I don't see a lot of community involvement there. Rather, I see a design being foisted on the community. Unlike Andrew, when I have an idea, I present it to the community first - before I start "working hard on it." I have a lot of ideas - many of them not worth pursuing, and the community has been good at bringing that to my attention (the SAX widgets parsing idea is a recent example). So, instead of going back and forth in this thread, why not create a new one - one that invites others to participate in the process. It's obvious from the conversation so far that some have felt excluded. So why object to starting over? -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, 5:55 PM > Well posting concerns in a new confluence page doesn't > really constitute communicating those concerns. > > In my experience with the community silence has always > implied either consent or a lack of interest and when your > working hard on something you don't want to see progress > stall while you wait in vain for people to comment further. > > All this could easily have been avoided by interested > parties simply commenting that they are actually interested > and would like time to comment further instead of just > assuming that the proposer is aware that you're going to > get around to it at some point. > > Regards > Scott > > > On 2/05/2009, at 12:25 PM, Adrian Crum wrote: > > > > > --- On Fri, 5/1/09, Scott Gray > wrote: > >> What do you mean by reboot this entire process? > So far > >> you're the only person who has questioned the > design... > >> and you already commented on it initially on the > confluence > >> page to which Andrew responded. > > > > That's not true: > > > > > http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model?focusedCommentId=7797#comment-7797 > > > > -Adrian > > > > > > > >
Re: Authz API Discussion (was re: svn commit: r770084)
On 2/05/2009, at 12: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." I don't really think that is relevant, permission services were an improvement to the existing security framework, designing a new framework doesn't invalidate an improvement to the old one. 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. The point is that it was opened up to the community before any code was written, all that needed to happen to delay coding was for someone to say that they needed time. Collaboration is a two way street and it shouldn't be up to the proposer to check to see if you're considering making a comment at some point you should just say so. Regards Scott smime.p7s Description: S/MIME cryptographic signature
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
[jira] Issue Comment Edited: (OFBIZ-2316) Replace the footer in smoothfeater
[
https://issues.apache.org/jira/browse/OFBIZ-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705202#action_12705202
]
BJ Freeman edited comment on OFBIZ-2316 at 5/1/09 6:27 PM:
---
the multiflex theme uses
<#assign nowTimestamp =
Static["org.ofbiz.base.util.UtilDateTime"].nowTimestamp()>
Copyright (c) 2001-${nowTimestamp?string("")} The Apache Software
Foundation - http://www.apache.org"; class="tabletext"
target="_blank">www.apache.org
Powered by http://ofbiz.apache.org"; target="_blank">Apache
OFBiz
Copyright (c) 2001-${nowTimestamp?string("")} The Apache Software
Foundation - http://www.apache.org"; class="tabletext"
target="_blank">www.apache.org
was (Author: bjfreeman):
the multi theme uses
Copyright (c) 2001-${nowTimestamp?string("")} The Apache Software
Foundation - http://www.apache.org"; class="tabletext"
target="_blank">www.apache.org
> Replace the footer in smoothfeater
> --
>
> Key: OFBIZ-2316
> URL: https://issues.apache.org/jira/browse/OFBIZ-2316
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
>Affects Versions: Release Branch 9.04, SVN trunk
>Reporter: Jacques Le Roux
> Fix For: Release Branch 9.04, SVN trunk
>
> Attachments: screenshot-1.jpg
>
>
> ON dev ML, my request was
> Actually the things that IMO are missing are
> * The ASF copyright and link to a apache.org site
> * Powered by OFBiz and link to ofbiz.apache.org
> * Release.revision informations
> Here is Ryan Foster's proposition
> The originally thinking was to give the backend look and feel a more
> "desktop" like feeling, where most of the information and navigation is
> located in sidebars, file menus, tabs, etc. Following that line of thinking,
> maybe we put a "help" link in the header right next to preferences that drops
> down in a similar fashion to show copyright, link to apache, etc. This would
> function exactly the same way that the help link functions in apps like
> Firefox, Mac Mail, Outlook, Word, etc. We could even put a simple keyword
> search field in this section that searches docs.ofbiz.org. See the attached
> screenshot for an example.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2346) Change Copyright Year
[
https://issues.apache.org/jira/browse/OFBIZ-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705203#action_12705203
]
BJ Freeman commented on OFBIZ-2346:
---
the multiflex theme uses
<#assign nowTimestamp =
Static["org.ofbiz.base.util.UtilDateTime"].nowTimestamp()>
Copyright (c) 2001-${nowTimestamp?string("")} The Apache Software
Foundation - http://www.apache.org"; class="tabletext"
target="_blank">www.apache.org
Powered by http://ofbiz.apache.org"; target="_blank">Apache
OFBiz
> Change Copyright Year
> --
>
> Key: OFBIZ-2346
> URL: https://issues.apache.org/jira/browse/OFBIZ-2346
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS
>Affects Versions: SVN trunk
>Reporter: Ashish Vijaywargiya
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: Copyright_Year_Change.patch
>
>
> I don't know much about when this copyright year and other related info
> changes come into existence.
> But if its right time to change the copyright year then here is the patch.
> And if it comes into existence after the completion of year then we can
> safely close this issue.
> Thanks !
> --
> Ashish
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2316) Replace the footer in smoothfeater
[
https://issues.apache.org/jira/browse/OFBIZ-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705202#action_12705202
]
BJ Freeman commented on OFBIZ-2316:
---
the multi theme uses
Copyright (c) 2001-${nowTimestamp?string("")} The Apache Software
Foundation - http://www.apache.org"; class="tabletext"
target="_blank">www.apache.org
> Replace the footer in smoothfeater
> --
>
> Key: OFBIZ-2316
> URL: https://issues.apache.org/jira/browse/OFBIZ-2316
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
>Affects Versions: Release Branch 9.04, SVN trunk
>Reporter: Jacques Le Roux
> Fix For: Release Branch 9.04, SVN trunk
>
> Attachments: screenshot-1.jpg
>
>
> ON dev ML, my request was
> Actually the things that IMO are missing are
> * The ASF copyright and link to a apache.org site
> * Powered by OFBiz and link to ofbiz.apache.org
> * Release.revision informations
> Here is Ryan Foster's proposition
> The originally thinking was to give the backend look and feel a more
> "desktop" like feeling, where most of the information and navigation is
> located in sidebars, file menus, tabs, etc. Following that line of thinking,
> maybe we put a "help" link in the header right next to preferences that drops
> down in a similar fashion to show copyright, link to apache, etc. This would
> function exactly the same way that the help link functions in apps like
> Firefox, Mac Mail, Outlook, Word, etc. We could even put a simple keyword
> search field in this section that searches docs.ofbiz.org. See the attached
> screenshot for an example.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Authz API Discussion (was re: svn commit: r770084)
Well posting concerns in a new confluence page doesn't really constitute communicating those concerns. In my experience with the community silence has always implied either consent or a lack of interest and when your working hard on something you don't want to see progress stall while you wait in vain for people to comment further. All this could easily have been avoided by interested parties simply commenting that they are actually interested and would like time to comment further instead of just assuming that the proposer is aware that you're going to get around to it at some point. Regards Scott On 2/05/2009, at 12:25 PM, Adrian Crum wrote: --- On Fri, 5/1/09, Scott Gray wrote: What do you mean by reboot this entire process? So far you're the only person who has questioned the design... and you already commented on it initially on the confluence page to which Andrew responded. That's not true: http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model?focusedCommentId=7797#comment-7797 -Adrian smime.p7s Description: S/MIME cryptographic signature
Re: Authz API Discussion (was re: svn commit: r770084)
--- 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: Microsoft NAV look and feel
I was thinking at the (great) new Bizness Time theme at 1st place... Jacques From: "Adrian Crum" Thanks for mentioning that. Although the RTL community hasn't been involved recently, we don't want to exclude them altogether. -Adrian --- On Fri, 5/1/09, Jacques Le Roux wrote: From: Jacques Le Roux Subject: Re: Microsoft NAV look and feel To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 5:14 PM Be used by RTL languages, Arab, etc. ? Adrian made efforts for that also, I think we can't lose that on the road... Jacques From: "Adrian Crum" > > Would that be accessible? In other words, is it blind/sight impaired accessible? > > -Adrian > > > --- On Fri, 5/1/09, Ean Schuessler wrote: > >> From: Ean Schuessler >> Subject: Re: Microsoft NAV look and feel >> To: dev@ofbiz.apache.org, "adrian crum" >> Cc: dev@ofbiz.apache.org >> Date: Friday, May 1, 2009, 4:31 PM >> Converting the widget system to GWT would be a major >> strategic challenge. You would probably need an entirely new >> renderer that just sent the XML descriptions of screens to a >> mini-screen display application on the client. The client >> would then instantiate GWT widgets and bind them together >> with events that would execute the server side logic when >> they are clicked. >> One major difference is the fact that GWT widgets have >> state in the sense of Swing or even JSF whereas OFBiz >> widgets do not. >> - "Adrian Crum" wrote: > It's a good thing we have themes - someone with >> enough time on their hands could develop a theme that looks >> like that. ;-) > Someone suggested GWT two years ago and I took a look >> at it. From what I recall, it requires some complicated and >> sometimes convoluted markup in order to get the desired >> effects. > At around the same time, there was an effort in the >> project to reduce markup and make it more CSS Zen Garden >> like. The CSS Zen Garden approach won, and that's what >> you see in the project today. I'm still in favor of that >> approach. > Btw, I wouldn't be opposed to having small changes >> made to the markup to make styling a little easier. For >> example, we could have the menu widgets output >> elements inside the elements to make it easier to >> style menu item backgrounds. >> -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 >> x 315 > > >
Re: Authz API Discussion (was re: svn commit: r770084)
--- On Fri, 5/1/09, Scott Gray wrote: > What do you mean by reboot this entire process? So far > you're the only person who has questioned the design... > and you already commented on it initially on the confluence > page to which Andrew responded. That's not true: http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model?focusedCommentId=7797#comment-7797 -Adrian
Re: Microsoft NAV look and feel
Thanks for mentioning that. Although the RTL community hasn't been involved recently, we don't want to exclude them altogether. -Adrian --- On Fri, 5/1/09, Jacques Le Roux wrote: > From: Jacques Le Roux > Subject: Re: Microsoft NAV look and feel > To: dev@ofbiz.apache.org > Date: Friday, May 1, 2009, 5:14 PM > Be used by RTL languages, Arab, etc. ? > Adrian made efforts for that also, I think we can't > lose that on the road... > > Jacques > > From: "Adrian Crum" > > > > Would that be accessible? In other words, is it > blind/sight impaired accessible? > > > > -Adrian > > > > > > --- On Fri, 5/1/09, Ean Schuessler > wrote: > > > >> From: Ean Schuessler > >> Subject: Re: Microsoft NAV look and feel > >> To: dev@ofbiz.apache.org, "adrian crum" > > >> Cc: dev@ofbiz.apache.org > >> Date: Friday, May 1, 2009, 4:31 PM > >> Converting the widget system to GWT would be a > major > >> strategic challenge. You would probably need an > entirely new > >> renderer that just sent the XML descriptions of > screens to a > >> mini-screen display application on the client. The > client > >> would then instantiate GWT widgets and bind them > together > >> with events that would execute the server side > logic when > >> they are clicked. > >> One major difference is the fact that GWT widgets > have > >> state in the sense of Swing or even JSF whereas > OFBiz > >> widgets do not. > >> - "Adrian Crum" wrote: > It's > a good thing we have themes - someone with > >> enough time on their hands could develop a theme > that looks > >> like that. ;-) > Someone suggested GWT two > years ago and I took a look > >> at it. From what I recall, it requires some > complicated and > >> sometimes convoluted markup in order to get the > desired > >> effects. > At around the same time, there was > an effort in the > >> project to reduce markup and make it more CSS Zen > Garden > >> like. The CSS Zen Garden approach won, and > that's what > >> you see in the project today. I'm still in > favor of that > >> approach. > Btw, I wouldn't be opposed to > having small changes > >> made to the markup to make styling a little > easier. For > >> example, we could have the menu widgets output > > >> elements inside the elements to make it > easier to > >> style menu item backgrounds. > >> -- Ean Schuessler, CTO Brainfood.com > e...@brainfood.com - http://www.brainfood.com - 214-720-0700 > >> x 315 > > > > > >
Re: Microsoft NAV look and feel
Be used by RTL languages, Arab, etc. ? Adrian made efforts for that also, I think we can't lose that on the road... Jacques From: "Adrian Crum" Would that be accessible? In other words, is it blind/sight impaired accessible? -Adrian --- On Fri, 5/1/09, Ean Schuessler wrote: From: Ean Schuessler Subject: Re: Microsoft NAV look and feel To: dev@ofbiz.apache.org, "adrian crum" Cc: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 4:31 PM Converting the widget system to GWT would be a major strategic challenge. You would probably need an entirely new renderer that just sent the XML descriptions of screens to a mini-screen display application on the client. The client would then instantiate GWT widgets and bind them together with events that would execute the server side logic when they are clicked. One major difference is the fact that GWT widgets have state in the sense of Swing or even JSF whereas OFBiz widgets do not. - "Adrian Crum" wrote: > It's a good thing we have themes - someone with enough time on their hands could develop a theme that looks like that. ;-) > Someone suggested GWT two years ago and I took a look at it. From what I recall, it requires some complicated and sometimes convoluted markup in order to get the desired effects. > At around the same time, there was an effort in the project to reduce markup and make it more CSS Zen Garden like. The CSS Zen Garden approach won, and that's what you see in the project today. I'm still in favor of that approach. > Btw, I wouldn't be opposed to having small changes made to the markup to make styling a little easier. For example, we could have the menu widgets output elements inside the elements to make it easier to style menu item backgrounds. -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
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/
Finally not sure why, but I can't find Philippe Mouawad issues in Jira for OFBiz, anyway... Jacques From: "Jacques Le Roux" I think we have currently some issues pending in Jira that would benefit of a such effort (look for Mouawad in Jira) Jacques From: "Andrew Zeneski" 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: 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/
I think we have currently some issues pending in Jira that would benefit of a such effort (look for Mouawad in Jira) Jacques From: "Andrew Zeneski" 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)
Inline On 2/05/2009, at 10:45 AM, Adrian Crum wrote: Don't get me wrong, I'm not resisting change. I commented on your design document that I'm in support of a security refactor. I'm sure others in the community would support that too. The problem is, this wasn't discussed with the community beforehand. No one was given an opportunity to provide input. It appears (and I know that this might not be true) that the design was created, some coding had been done, and THEN a document was drawn up and code committed shortly afterward. Appearances must be deceiving, to the best of my knowledge Andrew put a lot of effort into creating a proposal, posted it to confluence and created a jira issue linking to the page (which got sent to the dev list). He then responded to all the comments that people made, waited a few days for additional comments and THEN began coding. My recommendation would be to reboot this entire process to give the community a chance to be involved in the design. What do you mean by reboot this entire process? So far you're the only person who has questioned the design... and you already commented on it initially on the confluence page to which Andrew responded. We should: 1. Send an email to the dev mailing list (and optionally the user list) asking for comments on the existing security framework and what they would like to see changed. I agree this could have been done more explicitly but a jira issue was created which does get sent to the dev list. People obviously saw it because comments were posted to the page. 2. Compile the list into a set of design objectives. 3. Send the list to the dev mailing list and ask for suggestions for implementing the design objectives. 4. Compile a list of implementations and send it to the dev mailing list for a vote. From my perspective, that's how a developer community should work. Until those steps are followed, you're going to have a lot of people asking the same questions I am - because they weren't involved and don't understand what you're doing. I don't understand why you don't understand, how is what has been committed different from the detailed design proposal that Andrew posted last week? I now realize you've obviously read it because you commented on the page, so if you don't understand what is being done now then you mustn't have understood it last week either and if you didn't understand it last week why didn't you post more comments/ questions? -Adrian --- On Fri, 5/1/09, Andrew Zeneski wrote: From: Andrew Zeneski Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 2:30 PM 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 smime.p7s Description: S/MIME cryptographic signature
Re: Microsoft NAV look and feel
Would that be accessible? In other words, is it blind/sight impaired accessible? -Adrian --- On Fri, 5/1/09, Ean Schuessler wrote: > From: Ean Schuessler > Subject: Re: Microsoft NAV look and feel > To: dev@ofbiz.apache.org, "adrian crum" > Cc: dev@ofbiz.apache.org > Date: Friday, May 1, 2009, 4:31 PM > Converting the widget system to GWT would be a major > strategic challenge. You would probably need an entirely new > renderer that just sent the XML descriptions of screens to a > mini-screen display application on the client. The client > would then instantiate GWT widgets and bind them together > with events that would execute the server side logic when > they are clicked. > > One major difference is the fact that GWT widgets have > state in the sense of Swing or even JSF whereas OFBiz > widgets do not. > > - "Adrian Crum" wrote: > > It's a good thing we have themes - someone with > enough time on their hands could develop a theme that looks > like that. ;-) > > Someone suggested GWT two years ago and I took a look > at it. From what I recall, it requires some complicated and > sometimes convoluted markup in order to get the desired > effects. > > At around the same time, there was an effort in the > project to reduce markup and make it more CSS Zen Garden > like. The CSS Zen Garden approach won, and that's what > you see in the project today. I'm still in favor of that > approach. > > Btw, I wouldn't be opposed to having small changes > made to the markup to make styling a little easier. For > example, we could have the menu widgets output > elements inside the elements to make it easier to > style menu item backgrounds. > > -- > Ean Schuessler, CTO Brainfood.com > e...@brainfood.com - http://www.brainfood.com - 214-720-0700 > x 315
Re: Authz API Discussion (was re: svn commit: r770084)
Big +1 But also I agree that Andrew made is best to communicate before commiting For me 2 things were missing 1) A news on MLs, but it looks like Andrew sent one and it did not get through for a reason or another (things between head and keyboard? ;o) 2) CTR mode : commit to fast before anybody had time to review anything Jacques From: "Adrian Crum" Don't get me wrong, I'm not resisting change. I commented on your design document that I'm in support of a security refactor. I'm sure others in the community would support that too. The problem is, this wasn't discussed with the community beforehand. No one was given an opportunity to provide input. It appears (and I know that this might not be true) that the design was created, some coding had been done, and THEN a document was drawn up and code committed shortly afterward. My recommendation would be to reboot this entire process to give the community a chance to be involved in the design. We should: 1. Send an email to the dev mailing list (and optionally the user list) asking for comments on the existing security framework and what they would like to see changed. 2. Compile the list into a set of design objectives. 3. Send the list to the dev mailing list and ask for suggestions for implementing the design objectives. 4. Compile a list of implementations and send it to the dev mailing list for a vote. From my perspective, that's how a developer community should work. Until those steps are followed, you're going to have a lot of people asking the same questions I am - because they weren't involved and don't understand what you're doing. -Adrian --- On Fri, 5/1/09, Andrew Zeneski wrote: From: Andrew Zeneski Subject: Re: Authz API Discussion (was re: svn commit: r770084) To: dev@ofbiz.apache.org Date: Friday, May 1, 2009, 2:30 PM 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: Microsoft NAV look and feel
Sounds more like Dojo. With GWT you write full on widget code, like Swing. - "Adrian Crum" wrote: > What I objected to at the time (I don't know if this is still the case) was > the complex HTML structures wrapped around a bit of text. Something like: > Some > text. > I can understand the need for multiple elements - so that you can layer > effects (due to CSS limitations). But why do they all need to have their own > class? The only one needed is "foo" - you can style the contained > elements with CSS descendant selectors. -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: Microsoft NAV look and feel
Converting the widget system to GWT would be a major strategic challenge. You would probably need an entirely new renderer that just sent the XML descriptions of screens to a mini-screen display application on the client. The client would then instantiate GWT widgets and bind them together with events that would execute the server side logic when they are clicked. One major difference is the fact that GWT widgets have state in the sense of Swing or even JSF whereas OFBiz widgets do not. - "Adrian Crum" wrote: > It's a good thing we have themes - someone with enough time on their hands > could develop a theme that looks like that. ;-) > Someone suggested GWT two years ago and I took a look at it. From what I > recall, it requires some complicated and sometimes convoluted markup in order > to get the desired effects. > At around the same time, there was an effort in the project to reduce markup > and make it more CSS Zen Garden like. The CSS Zen Garden approach won, and > that's what you see in the project today. I'm still in favor of that > approach. > Btw, I wouldn't be opposed to having small changes made to the markup to make > styling a little easier. For example, we could have the menu widgets output > elements inside the elements to make it easier to style menu item > backgrounds. -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: Microsoft NAV look and feel
Gosh, those are pretty interesting. I guess its a little more Icefacesish. I've mostly been looking at GWT but I can see strong arguments about why you don't want validation logic running in the client (or at least *just* in the client). Eclipse certainly is a strong endorsement, though Google is also a force to be reconned with. - "Raj Saini" wrote: > This is very much possible using Eclipse RAP. I did basic level of > integration (Wrote a view handler for RAP). You can see some of the > demos here: > http://www.eclipse.org/rap/demos.php -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Proposal: multiple price class rules
I've been looking at the price rules code that allows you to reset the price to the promotion price under certain conditions. I have a situation where I would like to have several different price types configured and then set the product price to one of those several categories depending on a series of conditions. I wish that there was a type of ProductPriceAction that would allow you to reset the price to a PriceType based on a string passed in with the rule. Unfortunately, ProductPriceActions only allow you to specify an Double amount. I sort of wonder why this is not a string value that could serve a variety of functions depending on the rule. In a broader view, I'm frustrated with the primitive microlanguage of the price rules. I wish for Drools style specification with full language features. Drools is BSD, ya know, could we go there? Please? -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
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: 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/
From: "Adam Heath" To: Sent: Friday, May 01, 2009 10:52 PM Subject: 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/ 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? Executor framework : interesting, I was not aware ! Thanks Jacques
[jira] Commented: (OFBIZ-2398) BizznessTime Theme
[ https://issues.apache.org/jira/browse/OFBIZ-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705173#action_12705173 ] Jacques Le Roux commented on OFBIZ-2398: I think we should take into account some of the comments [there|http://docs.ofbiz.org/display/OFBADMIN/New+Features+Roadmap+-+Living+Document#NewFeaturesRoadmap-LivingDocument-UI(UserInterface)enhancements] > BizznessTime Theme > -- > > Key: OFBIZ-2398 > URL: https://issues.apache.org/jira/browse/OFBIZ-2398 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: SVN trunk >Reporter: Ryan Foster > Fix For: SVN trunk > > Attachments: BizznessTime.patch, bizznesstime.zip > > > This new theme, codename: It's Bizzness Time, addresses most if not all major > identified issues with the new Smoothfeather theme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2316) Replace the footer in smoothfeater
[ https://issues.apache.org/jira/browse/OFBIZ-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705170#action_12705170 ] Jacques Le Roux commented on OFBIZ-2316: Copyright 2008 :( We should find a global solution for that, I saw a discussion between Ashish and someone else about that... Ha yes : OFBIZ-2346 > Replace the footer in smoothfeater > -- > > Key: OFBIZ-2316 > URL: https://issues.apache.org/jira/browse/OFBIZ-2316 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Jacques Le Roux > Fix For: Release Branch 9.04, SVN trunk > > Attachments: screenshot-1.jpg > > > ON dev ML, my request was > Actually the things that IMO are missing are > * The ASF copyright and link to a apache.org site > * Powered by OFBiz and link to ofbiz.apache.org > * Release.revision informations > Here is Ryan Foster's proposition > The originally thinking was to give the backend look and feel a more > "desktop" like feeling, where most of the information and navigation is > located in sidebars, file menus, tabs, etc. Following that line of thinking, > maybe we put a "help" link in the header right next to preferences that drops > down in a similar fashion to show copyright, link to apache, etc. This would > function exactly the same way that the help link functions in apps like > Firefox, Mac Mail, Outlook, Word, etc. We could even put a simple keyword > search field in this section that searches docs.ofbiz.org. See the attached > screenshot for an example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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: Authz API Discussion (was re: svn commit: r770084)
Don't get me wrong, I'm not resisting change. I commented on your design document that I'm in support of a security refactor. I'm sure others in the community would support that too. The problem is, this wasn't discussed with the community beforehand. No one was given an opportunity to provide input. It appears (and I know that this might not be true) that the design was created, some coding had been done, and THEN a document was drawn up and code committed shortly afterward. My recommendation would be to reboot this entire process to give the community a chance to be involved in the design. We should: 1. Send an email to the dev mailing list (and optionally the user list) asking for comments on the existing security framework and what they would like to see changed. 2. Compile the list into a set of design objectives. 3. Send the list to the dev mailing list and ask for suggestions for implementing the design objectives. 4. Compile a list of implementations and send it to the dev mailing list for a vote. >From my perspective, that's how a developer community should work. Until those >steps are followed, you're going to have a lot of people asking the same >questions I am - because they weren't involved and don't understand what >you're doing. -Adrian --- On Fri, 5/1/09, Andrew Zeneski wrote: > From: Andrew Zeneski > Subject: Re: Authz API Discussion (was re: svn commit: r770084) > To: dev@ofbiz.apache.org > Date: Friday, May 1, 2009, 2:30 PM > 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)
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.
Inline
On 2/05/2009, at 9:45 AM, Adrian Crum wrote:
--- On Fri, 5/1/09, Andrew Zeneski
wrote:
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.
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?
I think it's an improvement, you can directly see what permissions are
required on the service without having to find a service def and then
it's method. The newer permissions are more intelligent so you don't
need to write a service for every variation in auth requirements.
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.
The idea of specifying some kind of parameter in the permission is
interesting. The question is, (speaking as a user) What does that
parameter do?
It runs dynamic access script defined on the SecurityPermission record
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?
Maybe that could be expressed as :component:admin.
I would rather hear an example of what this would be used for before
figuring out how to add it.
smime.p7s
Description: S/MIME cryptographic signature
[jira] Commented: (OFBIZ-2312) Styling flaws in smoothfeather
[ https://issues.apache.org/jira/browse/OFBIZ-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705161#action_12705161 ] Jacques Le Roux commented on OFBIZ-2312: In the new Buziness Time theme issue 6 is fixed > Styling flaws in smoothfeather > -- > > Key: OFBIZ-2312 > URL: https://issues.apache.org/jira/browse/OFBIZ-2312 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk > Environment: XP FF3 >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > I was to create an issue for each styling flaws in smoothfeather, but it's > far too mcuh work. So I have created only one issue to list what we find. > We can create a numbered comment for each issue to separate them and refer > easily to them whe fixed. Here we go > I wondered how to "close" (sub-)issues here. I thought about removing > comments but editing the original comment and using -understrike- with a > notice should be far better. You get -understrike- using \-understrike\- > If someone feels that the sub-issues here should be splitted in standard > sub-tasks of OFBIZ-2309 (or even better of the current issue), please feel > free to do so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2312) Styling flaws in smoothfeather
[ https://issues.apache.org/jira/browse/OFBIZ-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705160#action_12705160 ] Jacques Le Roux commented on OFBIZ-2312: For me in the new Buziness Time theme issue 5 is fixed (but a little quirk on WIndows/FF3 with out of "screen"). But as it was an Ashish's comment I let him express himself about this issue :) > Styling flaws in smoothfeather > -- > > Key: OFBIZ-2312 > URL: https://issues.apache.org/jira/browse/OFBIZ-2312 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk > Environment: XP FF3 >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > I was to create an issue for each styling flaws in smoothfeather, but it's > far too mcuh work. So I have created only one issue to list what we find. > We can create a numbered comment for each issue to separate them and refer > easily to them whe fixed. Here we go > I wondered how to "close" (sub-)issues here. I thought about removing > comments but editing the original comment and using -understrike- with a > notice should be far better. You get -understrike- using \-understrike\- > If someone feels that the sub-issues here should be splitted in standard > sub-tasks of OFBIZ-2309 (or even better of the current issue), please feel > free to do so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2312) Styling flaws in smoothfeather
[ https://issues.apache.org/jira/browse/OFBIZ-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705158#action_12705158 ] Jacques Le Roux commented on OFBIZ-2312: In the new Buziness Time theme issue 4 is fixed > Styling flaws in smoothfeather > -- > > Key: OFBIZ-2312 > URL: https://issues.apache.org/jira/browse/OFBIZ-2312 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk > Environment: XP FF3 >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > I was to create an issue for each styling flaws in smoothfeather, but it's > far too mcuh work. So I have created only one issue to list what we find. > We can create a numbered comment for each issue to separate them and refer > easily to them whe fixed. Here we go > I wondered how to "close" (sub-)issues here. I thought about removing > comments but editing the original comment and using -understrike- with a > notice should be far better. You get -understrike- using \-understrike\- > If someone feels that the sub-issues here should be splitted in standard > sub-tasks of OFBIZ-2309 (or even better of the current issue), please feel > free to do so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2312) Styling flaws in smoothfeather
[ https://issues.apache.org/jira/browse/OFBIZ-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705157#action_12705157 ] Jacques Le Roux commented on OFBIZ-2312: In the new Buziness Time theme issue 3 is fixed > Styling flaws in smoothfeather > -- > > Key: OFBIZ-2312 > URL: https://issues.apache.org/jira/browse/OFBIZ-2312 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk > Environment: XP FF3 >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > I was to create an issue for each styling flaws in smoothfeather, but it's > far too mcuh work. So I have created only one issue to list what we find. > We can create a numbered comment for each issue to separate them and refer > easily to them whe fixed. Here we go > I wondered how to "close" (sub-)issues here. I thought about removing > comments but editing the original comment and using -understrike- with a > notice should be far better. You get -understrike- using \-understrike\- > If someone feels that the sub-issues here should be splitted in standard > sub-tasks of OFBIZ-2309 (or even better of the current issue), please feel > free to do so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2312) Styling flaws in smoothfeather
[ https://issues.apache.org/jira/browse/OFBIZ-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705154#action_12705154 ] Jacques Le Roux commented on OFBIZ-2312: Issue 2 in the new Buziness Time theme : it's far better. The search servlet is any longer collapsable but this is not Buziness Time theme issue, I will open a new independant issue for that. So issue 2 is closed IMO > Styling flaws in smoothfeather > -- > > Key: OFBIZ-2312 > URL: https://issues.apache.org/jira/browse/OFBIZ-2312 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk > Environment: XP FF3 >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > I was to create an issue for each styling flaws in smoothfeather, but it's > far too mcuh work. So I have created only one issue to list what we find. > We can create a numbered comment for each issue to separate them and refer > easily to them whe fixed. Here we go > I wondered how to "close" (sub-)issues here. I thought about removing > comments but editing the original comment and using -understrike- with a > notice should be far better. You get -understrike- using \-understrike\- > If someone feels that the sub-issues here should be splitted in standard > sub-tasks of OFBIZ-2309 (or even better of the current issue), please feel > free to do so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2413) The search servlet (up part of lookup screens) is any longer collapsable
[ https://issues.apache.org/jira/browse/OFBIZ-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-2413: --- Issue Type: Bug (was: Improvement) > The search servlet (up part of lookup screens) is any longer collapsable > > > Key: OFBIZ-2413 > URL: https://issues.apache.org/jira/browse/OFBIZ-2413 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Jacques Le Roux >Priority: Trivial > Fix For: Release Branch 9.04, SVN trunk > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2316) Replace the footer in smoothfeater
[ https://issues.apache.org/jira/browse/OFBIZ-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705153#action_12705153 ] Jacques Le Roux commented on OFBIZ-2316: Actually the www.apache.org and OFBiz parts are links (I saw them when I read my comment in mail sent by Jira) but this are not visible as a link, maybe this is wanted, I'm not a designer ;) But I would try to keep them visible (links different from plain text) This is an all behaviour that I think we should keep. My 2 cts > Replace the footer in smoothfeater > -- > > Key: OFBIZ-2316 > URL: https://issues.apache.org/jira/browse/OFBIZ-2316 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Jacques Le Roux > Fix For: Release Branch 9.04, SVN trunk > > Attachments: screenshot-1.jpg > > > ON dev ML, my request was > Actually the things that IMO are missing are > * The ASF copyright and link to a apache.org site > * Powered by OFBiz and link to ofbiz.apache.org > * Release.revision informations > Here is Ryan Foster's proposition > The originally thinking was to give the backend look and feel a more > "desktop" like feeling, where most of the information and navigation is > located in sidebars, file menus, tabs, etc. Following that line of thinking, > maybe we put a "help" link in the header right next to preferences that drops > down in a similar fashion to show copyright, link to apache, etc. This would > function exactly the same way that the help link functions in apps like > Firefox, Mac Mail, Outlook, Word, etc. We could even put a simple keyword > search field in this section that searches docs.ofbiz.org. See the attached > screenshot for an example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2413) The search servlet (up part of lookup screens) is any longer collapsable
The search servlet (up part of lookup screens) is any longer collapsable Key: OFBIZ-2413 URL: https://issues.apache.org/jira/browse/OFBIZ-2413 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Release Branch 9.04, SVN trunk Reporter: Jacques Le Roux Priority: Trivial Fix For: Release Branch 9.04, SVN trunk -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2312) Styling flaws in smoothfeather
[ https://issues.apache.org/jira/browse/OFBIZ-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705147#action_12705147 ] Jacques Le Roux commented on OFBIZ-2312: Issue 1 in the new Buziness Time theme : login and pwd zones are still too long > Styling flaws in smoothfeather > -- > > Key: OFBIZ-2312 > URL: https://issues.apache.org/jira/browse/OFBIZ-2312 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk > Environment: XP FF3 >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > I was to create an issue for each styling flaws in smoothfeather, but it's > far too mcuh work. So I have created only one issue to list what we find. > We can create a numbered comment for each issue to separate them and refer > easily to them whe fixed. Here we go > I wondered how to "close" (sub-)issues here. I thought about removing > comments but editing the original comment and using -understrike- with a > notice should be far better. You get -understrike- using \-understrike\- > If someone feels that the sub-issues here should be splitted in standard > sub-tasks of OFBIZ-2309 (or even better of the current issue), please feel > free to do so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2304) The css styles for "smoothfeather" style associated to the different log levels in the view log screen in webtools are missing
[ https://issues.apache.org/jira/browse/OFBIZ-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-2304. -- Resolution: Fixed Assignee: Tim Ruppert Fixed in the new Buziness Time theme > The css styles for "smoothfeather" style associated to the different log > levels in the view log screen in webtools are missing > -- > > Key: OFBIZ-2304 > URL: https://issues.apache.org/jira/browse/OFBIZ-2304 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato >Assignee: Tim Ruppert >Priority: Minor > Fix For: SVN trunk > > > The css styles for "smoothfeather" style associated to the different log > levels in the view log screen in webtools are missing, and as a consequence, > the log messages are no longer colored as they are in the standard OFBiz > style; here is the screen: > https://localhost:8443/webtools/control/LogView -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2306) The new "smoothfeather" style is not internationalized (i18n)
[ https://issues.apache.org/jira/browse/OFBIZ-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-2306. -- Resolution: Fixed Assignee: Tim Ruppert Looks like this has been fixed in the new Buziness Time theme > The new "smoothfeather" style is not internationalized (i18n) > -- > > Key: OFBIZ-2306 > URL: https://issues.apache.org/jira/browse/OFBIZ-2306 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Jacques Le Roux >Assignee: Tim Ruppert > Fix For: Release Branch 9.04, SVN trunk > > > This is a *real handicap* for non English community. It should be done in the > Release 9.04 IMO -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2308) New "smoothfeather" style Business Area enhancement
[ https://issues.apache.org/jira/browse/OFBIZ-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705141#action_12705141 ] Ryan Foster commented on OFBIZ-2308: You are absolutely right. It is annoying, and a little clumsy. I'll get that fixed so that one drop down cancels out the other. I think it might also help to add in a timeout feature as well so that if you do nothing at all, the dropdown automatically blinds back up after a set period of time. > New "smoothfeather" style Business Area enhancement > > > Key: OFBIZ-2308 > URL: https://issues.apache.org/jira/browse/OFBIZ-2308 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: SVN trunk >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > We could have a title for each column of Business Area. Something like "Main > applications" "Secondary applications", maybe 2 colors also ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2316) Replace the footer in smoothfeater
[ https://issues.apache.org/jira/browse/OFBIZ-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705140#action_12705140 ] Jacques Le Roux commented on OFBIZ-2316: In the new Bizness Time theme., I see these static informations without links Powered by OFBiz Copyright 2001-2008 The Apache Software Foundation - www.apache.org But I don't see some of the requirement above. Do I miss something ? > Replace the footer in smoothfeater > -- > > Key: OFBIZ-2316 > URL: https://issues.apache.org/jira/browse/OFBIZ-2316 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Jacques Le Roux > Fix For: Release Branch 9.04, SVN trunk > > Attachments: screenshot-1.jpg > > > ON dev ML, my request was > Actually the things that IMO are missing are > * The ASF copyright and link to a apache.org site > * Powered by OFBiz and link to ofbiz.apache.org > * Release.revision informations > Here is Ryan Foster's proposition > The originally thinking was to give the backend look and feel a more > "desktop" like feeling, where most of the information and navigation is > located in sidebars, file menus, tabs, etc. Following that line of thinking, > maybe we put a "help" link in the header right next to preferences that drops > down in a similar fashion to show copyright, link to apache, etc. This would > function exactly the same way that the help link functions in apps like > Firefox, Mac Mail, Outlook, Word, etc. We could even put a simple keyword > search field in this section that searches docs.ofbiz.org. See the attached > screenshot for an example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2305) With the smoothfeather style the "PDF" link in the order detail screen is not working properly
[ https://issues.apache.org/jira/browse/OFBIZ-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-2305. -- Resolution: Fixed Fix Version/s: Release Branch 9.04 Assignee: Tim Ruppert Fixed in the new Bizness Time theme, not commited yet... > With the smoothfeather style the "PDF" link in the order detail screen is not > working properly > -- > > Key: OFBIZ-2305 > URL: https://issues.apache.org/jira/browse/OFBIZ-2305 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato >Assignee: Tim Ruppert > Fix For: Release Branch 9.04, SVN trunk > > > Here is the link: > https://localhost:8443/ordermgr/control/orderview?orderId=DEMO10090 > the PDF link is at the top left of the screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-2381) Implementation of new Authorization API
[
https://issues.apache.org/jira/browse/OFBIZ-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704374#action_12704374
]
Andrew Zeneski edited comment on OFBIZ-2381 at 5/1/09 2:56 PM:
---
*Commit History*
Revision 769928 - Base API - not enabled will not effect anything
Revision 769929 - Ext. API + Test Cases - Effects only when running tests
Revision 769936 - Service Engine Integration - dispatchContext.getAuthz() -
used in check-permission tags
Revision 769937 - Controller Integration - use request.getAttribute("authz") -
ACTIVE IN CoreEvents.java
Revision 769943 - Widget Integration - enabled when NOT using an action=""
element
Revision 769944 - Themes Integration - uses both APIs for checking permission
Revision 769963 - Fix for infinite looping when using hasPermission from
service based DA implementations
Revision 769965 - MiniLang (Simple Method) integration - enabled when NOT using
an action="" element
Revision 770036 - Added license header
Revision 770076 - Bug fixes, changed groovy context name to permissionContext
Revision 770077 - Integrated (in context setup) with Webslinger
Revision 770401 - Removed 'expanded' parameter from API; included new
findMatchingPermissions() method
Revision 770407 - Fixed themes to work the the API change
Revision 770771 - Fixed issue w/ ThreadLocal not being cleared by a thread pool
Revision 770836 - Renamed AbtractAuthorization to AbstractAuthorization as it
should have been in the first place
was (Author: jaz):
*Commit History*
Revision 769928 - Base API - not enabled will not effect anything
Revision 769929 - Ext. API + Test Cases - Effects only when running tests
Revision 769936 - Service Engine Integration - dispatchContext.getAuthz() -
used in check-permission tags
Revision 769937 - Controller Integration - use request.getAttribute("authz") -
ACTIVE IN CoreEvents.java
Revision 769943 - Widget Integration - enabled when NOT using an action=""
element
Revision 769944 - Themes Integration - uses both APIs for checking permission
Revision 769963 - Fix for infinite looping when using hasPermission from
service based DA implementations
Revision 769965 - MiniLang (Simple Method) integration - enabled when NOT using
an action="" element
Revision 770036 - Added license header
Revision 770076 - Bug fixes, changed groovy context name to permissionContext
Revision 770077 - Integrated (in context setup) with Webslinger
Revision 770401 - Removed 'expanded' parameter from API; included new
findMatchingPermissions() method
Revision 770407 - Fixed themes to work the the API change
Revision 770771 - Fixed issue w/ ThreadLocal not being cleared by a thread pool
> Implementation of new Authorization API
> ---
>
> Key: OFBIZ-2381
> URL: https://issues.apache.org/jira/browse/OFBIZ-2381
> Project: OFBiz
> Issue Type: Sub-task
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Andrew Zeneski
>Assignee: Andrew Zeneski
> Fix For: SVN trunk
>
> Attachments: security_2_0-api.patch
>
> Original Estimate: 48h
> Time Spent: 48h
> Remaining Estimate: 0h
>
> Implementation of Authorization API (see documentation on parent task)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2308) New "smoothfeather" style Business Area enhancement
[ https://issues.apache.org/jira/browse/OFBIZ-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705137#action_12705137 ] Jacques Le Roux commented on OFBIZ-2308: The demand above as been solved in the new Bizness Time theme which will replace smooth feather theme. Though without using different colors in both columns but in the columns title. But I find another thing annoying : could it be possible to not have to use the up arrow but simply click around elsewhere. For instance if you open the Business Area and then (without closing the Business Area) the Preferences you dont see the Preferences options... > New "smoothfeather" style Business Area enhancement > > > Key: OFBIZ-2308 > URL: https://issues.apache.org/jira/browse/OFBIZ-2308 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: SVN trunk >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > We could have a title for each column of Business Area. Something like "Main > applications" "Secondary applications", maybe 2 colors also ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: PartyRelationship
Yes, I think this is correct. The best way to make sure is to look at the demo data, like the DemoOrderPeopleData.xml file and a few others have PartyRelationship data in them. -David On May 1, 2009, at 11:45 AM, Andrew Zeneski wrote: 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)
--- On Fri, 5/1/09, Andrew Zeneski wrote:
> 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.
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 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?
> >> 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.
The idea of specifying some kind of parameter in the permission is interesting.
The question is, (speaking as a user) What does that parameter do?
> >> 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?
Maybe that could be expressed as :component:admin.
-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: Microsoft NAV look and feel
Adrian Crum wrote: > Someone suggested GWT two years ago and I took a look at > it. From what I recall, it requires some complicated and > sometimes convoluted markup in order to get the desired > effects. I've got gwt startup code that scans the page document for class="Foo", and converts them to GWT widgets on the fly. But since it has to handle any possible widget, the compiled output tends to include *all* of GWT; almost nothing can be optimized out. This tends to give a 300k javascript file, or larger/smaller, depending on obfusication.
Re: Microsoft NAV look and feel
What I objected to at the time (I don't know if this is still the case) was the complex HTML structures wrapped around a bit of text. Something like: Some text. I can understand the need for multiple elements - so that you can layer effects (due to CSS limitations). But why do they all need to have their own class? The only one needed is "foo" - you can style the contained elements with CSS descendant selectors. -Adrian --- On Fri, 5/1/09, Adam Heath wrote: > From: Adam Heath > Subject: Re: Microsoft NAV look and feel > To: dev@ofbiz.apache.org > Date: Friday, May 1, 2009, 2:13 PM > Adrian Crum wrote: > > Someone suggested GWT two years ago and I took a look > at > > it. From what I recall, it requires some complicated > and > > sometimes convoluted markup in order to get the > desired > > effects. > > I've got gwt startup code that scans the page document > for > class="Foo", and converts them to GWT widgets on > the fly. But since > it has to handle any possible widget, the compiled output > tends to > include *all* of GWT; almost nothing can be optimized out. > This tends > to give a 300k javascript file, or larger/smaller, > depending on > obfusication.
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
[jira] Commented: (OFBIZ-2339) No bullets rendered
[ https://issues.apache.org/jira/browse/OFBIZ-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705125#action_12705125 ] Jacques Le Roux commented on OFBIZ-2339: Great, thanks Rob (and Tim) > No bullets rendered > --- > > Key: OFBIZ-2339 > URL: https://issues.apache.org/jira/browse/OFBIZ-2339 > Project: OFBiz > Issue Type: Sub-task >Reporter: Jacques Le Roux >Assignee: Tim Ruppert > Fix For: SVN trunk > > > The styles associate with > * > and > ** > are no longer rendering bullets. > Could it be possible to differentiate simple indentation from bullet > (numbering is working well) ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Odd number of characters in applications/accounting/data/AccountingTypeData.xml
Thanks Marco, in a hurry and forgot that one... Jacques From: "Marco Risaliti" Hi Jacques, it's required to do some steps as explained in the documentation http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration R767278 PaymentGatewayPayflowPro and PaymentGatewayClearCommerce password encrypted. or in alternative you have to do an ant clean-all ant/run-install only if it's your working copy. Thanks Marco Il giorno 01/mag/09, alle ore 20:03, Jacques Le Roux ha scritto: Not sure why yet, but I got this error while running ant run- install. I also tried importing the file using webtools/import xml : same error ERROR: Error parsing entity xml file: org.ofbiz.base.util.GeneralRuntimeException: null (Odd number of characters.) Currently trying bizness time new theme, very excited (though tired, confuse feeling) Jacques
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/
From: "Adam Heath" 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. Actually it's very clear! Jacques 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: Authz API Discussion (was re: svn commit: r770084)
I see this new security framework as big step forward. The existing
security system is way too static, I mean permission rules are
embedded in services such that users always need ofbiz DSL (mini lang)
experts to do simple stuff (good job security, If there were customers).
New system opens up doors for building tools that will make Ofbiz
Administrators life lot easy. Like now I can write tools that will
scan all the services/ forms/screen/menu widgets (may request entries
in controller) and present me a tree of
1) Artifacts like services, screens, forms. Resources that you will
like to secure.
2) List of different levels of permissions.
Artifact node will show permission needed and children nodes that are
list of users who have access the them.
Permission node can list users who have those permission and list of
artifacts that are allowed to use at that level.
Administrator will be able to add or remove user or change level of
access.
If done right permissions in special purpose applications will be much
more manageable. Auto-grant functionality can be {quote} extended
{quote}, we can connect it with date model that stores permission
dependency.
e.g When user is granted "update:sfa:contact:1" permission, How
will security framework know that its same as "update:party:1"? We
can setup data for mapping special purpose permissions with
fundamental permissions. So when security framework finds that called
service requires "update:party:1" permission and user does not
have it then figure out if user have permissions that are equivalent
or better then "update:party:1" permission.
Auto-grant concept can be extended for securing higher level
(compound) services that in turn call multiple services. Just an idea,
if we make our request secured like services, then we can secure our
UI components because they know request id.
Also, I believe HWM is going to help by providing some resources to
assist in the effort.
+1
Whatever we decide, I am happy we are thinking about it.
Regards
Anil Patel
On May 1, 2009, at 2:23 PM, Andrew Zeneski wrote:
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.
+1
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
Re: Microsoft NAV look and feel
It's a good thing we have themes - someone with enough time on their hands could develop a theme that looks like that. ;-) Someone suggested GWT two years ago and I took a look at it. From what I recall, it requires some complicated and sometimes convoluted markup in order to get the desired effects. At around the same time, there was an effort in the project to reduce markup and make it more CSS Zen Garden like. The CSS Zen Garden approach won, and that's what you see in the project today. I'm still in favor of that approach. Btw, I wouldn't be opposed to having small changes made to the markup to make styling a little easier. For example, we could have the menu widgets output elements inside the elements to make it easier to style menu item backgrounds. -Adrian --- On Fri, 5/1/09, Ean Schuessler wrote: > From: Ean Schuessler > Subject: Microsoft NAV look and feel > To: "OFBiz Dev List" > Cc: "erik" > Date: Friday, May 1, 2009, 10:53 AM > I really like what Microsoft NAV is doing in their > interfaces. If we do something like this using GWT it would > be suh-lick! > > http://www.microsoft.com/library/media/1033/business/images/dynamics/screenshotimages/PivotTable.jpg > > > -- > Ean Schuessler, CTO Brainfood.com > e...@brainfood.com - http://www.brainfood.com - 214-720-0700 > x 315
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/
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: 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: PartyRelationship
--- 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
ERROR: Cannot update specified contact info because it does not correspond to the specified party
I was trying to Edit the User-Interface of partymgr. I added following code in editcontactmech.ftl Planet gives me following error. ERROR: Cannot update specified contact info because it does not correspond to the specified party. calling service updatePartyContactMech in updatePartyPostalAddress Please help! Thanks -- View this message in context: http://www.nabble.com/ERROR%3A-Cannot-update-specified-contact-info-because-it-does-not-correspond-to-the-specified-party-tp23339399p23339399.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Authz API Discussion (was re: svn commit: r770084)
--- On Fri, 5/1/09, Andrew Zeneski wrote: > 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. 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
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: Authz API Discussion (was re: svn commit: r770084)
--- 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? > 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. > 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? -Adrian
Re: Odd number of characters in applications/accounting/data/AccountingTypeData.xml
Hi Jacques, it's required to do some steps as explained in the documentation http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration R767278 PaymentGatewayPayflowPro and PaymentGatewayClearCommerce password encrypted. or in alternative you have to do an ant clean-all ant/run-install only if it's your working copy. Thanks Marco Il giorno 01/mag/09, alle ore 20:03, Jacques Le Roux ha scritto: Not sure why yet, but I got this error while running ant run- install. I also tried importing the file using webtools/import xml : same error ERROR: Error parsing entity xml file: org.ofbiz.base.util.GeneralRuntimeException: null (Odd number of characters.) Currently trying bizness time new theme, very excited (though tired, confuse feeling) Jacques
Odd number of characters in applications/accounting/data/AccountingTypeData.xml
Not sure why yet, but I got this error while running ant run-install. I also tried importing the file using webtools/import xml : same error ERROR: Error parsing entity xml file: org.ofbiz.base.util.GeneralRuntimeException: null (Odd number of characters.) Currently trying bizness time new theme, very excited (though tired, confuse feeling) Jacques
[jira] Created: (OFBIZ-2412) updateOrderAdjustment
updateOrderAdjustment - Key: OFBIZ-2412 URL: https://issues.apache.org/jira/browse/OFBIZ-2412 Project: OFBiz Issue Type: Sub-task Reporter: Rohit Sureka Updating any order adjustment, to a order cause the secure URL error. https://www.example.com/ordermgr/control/updateOrderAdjustment?orderAdjustmentId=10040&orderId=WSCO10010 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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).
[jira] Created: (OFBIZ-2411) editshipmentroutesegment page
editshipmentroutesegment page - Key: OFBIZ-2411 URL: https://issues.apache.org/jira/browse/OFBIZ-2411 Project: OFBiz Issue Type: Sub-task Reporter: Rohit Sureka https://www.example.com/facility/control/updateShipmentRouteSegment?shipmentId=10010&shipmentRouteSegmentId=1&carrierPartyId=FEDEX&shipmentMethodTypeId=AIR&originFacilityId=WebStoreWarehouse&destFacilityId=&originContactMechId=9200&destContactMechId=11120&originTelecomNumberId=9201&destTelecomNumberId=&thirdPartyAccountNumber=&thirdPartyPostalCode=&thirdPartyCountryGeoCode=&carrierServiceStatusId=SHRSCS_NOT_STARTED&trackingIdNumber=&estimatedStartDate=&estimatedArrivalDate=&actualStartDate=&actualArrivalDate=&billingWeight=&billingWeightUomId=¤cyUomId=&actualTransportCost=&actualServiceCost=&actualOtherCost=&actualCost= -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Microsoft NAV look and feel
Hi Ean, This is very much possible using Eclipse RAP. I did basic level of integration (Wrote a view handler for RAP). You can see some of the demos here: http://www.eclipse.org/rap/demos.php Thanks, Raj Ean Schuessler wrote: I really like what Microsoft NAV is doing in their interfaces. If we do something like this using GWT it would be suh-lick! http://www.microsoft.com/library/media/1033/business/images/dynamics/screenshotimages/PivotTable.jpg
[jira] Created: (OFBIZ-2410) EditShipmentRouteSegments does not show the package.
EditShipmentRouteSegments does not show the package.
Key: OFBIZ-2410
URL: https://issues.apache.org/jira/browse/OFBIZ-2410
Project: OFBiz
Issue Type: Bug
Components: product
Affects Versions: SVN trunk
Environment: redhat, postgres
Reporter: Rohit Sureka
Hi,
The EditShipmentRouteSegments, does not show the order package(s), at the link
https://www.example.com/facility/control/EditShipmentRouteSegments?shipmentId=10010
The bug was probably introduced with the migration of this file
EditShipmentRouteSegments.bsh from bsh to groovy.
shipmentId = request.getParameter("shipmentId");
if (!shipmentId) {
shipmentId = context.shipmentId;
}
shipment = null;
if (!shipmentId) {
shipment = delegator.findOne("Shipment", [shipmentId : shipmentId], false);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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/
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).
[jira] Issue Comment Edited: (OFBIZ-2407) Functionality for "Weight Packages Only" option on pack order screen
[ https://issues.apache.org/jira/browse/OFBIZ-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705033#action_12705033 ] Pranay Pandey edited comment on OFBIZ-2407 at 5/1/09 11:26 AM: --- This patch is from Akash Jain. Thanks. Following are the steps for testing: # Create sales order, it should be in Approved status. # Verify all order items from "Facility-->Verify Pick" screen, now shipmentId (in PICKED status) and invoiceId (in INVOICE_IN_PROCESS status) will be generated. # Now go in Pack Order screen, select the order items and depress "Pack Item" button, all items will be in package(s). # Depress "Weight Package Only" button, weight package only form will open. There will be field for entering Package weight, Dimensions, Shipment Package Type and two buttons "Next Package" and "Complete" # Enter all fields and depress Next Package button, enter the weight and dimensions of all packages one by one, then depress "Complete" button. # If new estimate shipping charges is 10% less or grater than estimate shipping charges (taken when order created) then warning form will open otherwise shipment will be packed; order will be in COMPLETED and dimensions will be saved in ShipmentPackage entity. # The warining form will show message "There is much difference in shipping charges" and two buttons "Ship Now" and "Hold Shipment". # If Ship Now button clicked then shipment will be PACKED, order status will be COMPLETED and Dimensions, Shipment Package Type will be saved in ShipmentPackage entity. # If "Hold Shipment" button is clicked then shipment will remain in PICKED status and Dimensions, Shipment Package type will saved in ShipmentPackage entity. was (Author: pandeypranay): I am uploading the patch for "Weight Package Only" . There are steps for testing # Create sales order, it should be in Approved status # Verified all order items, now shipmentId (in Picked status) and invoiceId (in INVOICE_IN_PROCESS status) will generate # Now go in pack order screen, select the order items and depress "Pack Item" button, all items will be in package(s) # Depress " Weight Package Only" button, weight package only form will open there will be field for enter weight package, dimensions, shipment package type and two buttons "Next Package" and "Complete" # Enter all fields and depress Next Package button, enter the weight and dimensions of all packages one by one, then depress "Complete" button # If new estimate shipping charges is 10% less or grater than estimate shipping charges (taken when order created) then warning form will open otherwise shipment will be packed and order will be complete and dimension will save in ShipmentPackage entity # There are warning message "There is much difference in shipping charges" and two buttons "Ship Now" and "Hold Shipment" in warning form # If depress on Ship Now button then shipment will be packed and order status will be complete and dimensions, shipment package type will be save in ShipmentPackage entity # If depress on Hold Shipment button then shipment will remains in Picked status and dimension, shipment package type will save in ShipmentPackage entity. > Functionality for "Weight Packages Only" option on pack order screen > - > > Key: OFBIZ-2407 > URL: https://issues.apache.org/jira/browse/OFBIZ-2407 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: SVN trunk >Reporter: Pranay Pandey >Assignee: Vikas Mayur >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-2407.patch > > > Functionality for "Weight Packages Only" option on pack order screen is to > be added. > # In Facility -> Packing screens when the order entered already has a > Shipment that exists in the Picked status: add a "Weight Packages Only" > button. > # When user clicks on "Weight Packages Only" show a form with Weight input > box, optional dimension input boxes (length, width, height), optional > drop-down for pre-configured boxes (using data from ShipmentBoxType entity > and two buttons: "Next Package" and "Complete" . > # When the "Complete" button is pressed if the shipping charge is > 10%(configure in shipment.properties file, use property name > "shipment.default.cost.actual_over_estimated_percent_allowed") above the > estimated amount (the amount that would be charged to the customer). > #* The system will warn user that the shipping amount is too much there will > be a warning form with two buttons: "Ship Now" and "Hold Shipment". > #* if Ship Now is pressed the system will run as normal > #* if Hold Shipment is pressed the Shipment will remain in the Picked status, > weight/size changes will be retained, no o
