Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: [hidden email]
> 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
> <[hidden email]> wrote:
> >
> >> From: Scott Gray
> <[hidden email]>
> >> Subject: Re: Authz API Discussion (was re: svn
> commit: r770084)
> >> To: [hidden email]
> >> 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
> >> <[hidden email]> 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
> >>>
> >>>
> >>>
> >>>
> >
> >
> >

     

[Scott Gray-2]

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 <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
>> To: [hidden email]
>> 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
>> <[hidden email]> wrote:
>>>
>>>> From: Scott Gray
>> <[hidden email]>
>>>> Subject: Re: Authz API Discussion (was re: svn
>> commit: r770084)
>>>> To: [hidden email]
>>>> 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
>>>> <[hidden email]> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: [hidden email]
> 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
> <[hidden email]> wrote:
> >
> >> From: Scott Gray
> <[hidden email]>
> >> Subject: Re: Authz API Discussion (was re: svn
> commit: r770084)
> >> To: [hidden email]
> >> 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
> >> <[hidden email]> wrote:
> >>>
> >>>> From: Scott Gray
> >> <[hidden email]>
> >>>> Subject: Re: Authz API Discussion (was re:
> svn
> >> commit: r770084)
> >>>> To: [hidden email]
> >>>> 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
> >>>> <[hidden email]> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >

     

[Andrew Zeneski-2]

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 <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
>> To: [hidden email]
>> 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
>> <[hidden email]> wrote:
>>>
>>>> From: Scott Gray
>> <[hidden email]>
>>>> Subject: Re: Authz API Discussion (was re: svn
>> commit: r770084)
>>>> To: [hidden email]
>>>> 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
>>>> <[hidden email]> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>

[Andrew Zeneski-2]

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 <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
>> To: [hidden email]
>> 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
>> <[hidden email]> wrote:
>>>
>>>> From: Scott Gray
>> <[hidden email]>
>>>> Subject: Re: Authz API Discussion (was re: svn
>> commit: r770084)
>>>> To: [hidden email]
>>>> 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
>>>> <[hidden email]> wrote:
>>>>>
>>>>>> From: Scott Gray
>>>> <[hidden email]>
>>>>>> Subject: Re: Authz API Discussion (was re:
>> svn
>>>> commit: r770084)
>>>>>> To: [hidden email]
>>>>>> 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
>>>>>> <[hidden email]> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>

[Anil Patel-3]

On May 1, 2009, at 10:19 PM, Adrian Crum wrote:

>
> --- On Fri, 5/1/09, Anil Patel <[hidden email]> 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
>
>
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Andrew Zeneski <[hidden email]>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: [hidden email]
> 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
> <[hidden email]> wrote:
> >
> >> From: Scott Gray
> <[hidden email]>
> >> Subject: Re: Authz API Discussion (was re: svn
> commit: r770084)
> >> To: [hidden email]
> >> 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
> >> <[hidden email]> wrote:
> >>>
> >>>> From: Scott Gray
> >> <[hidden email]>
> >>>> Subject: Re: Authz API Discussion (was re:
> svn
> >> commit: r770084)
> >>>> To: [hidden email]
> >>>> 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
> >>>> <[hidden email]> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >

     

[Andrew Zeneski-2]

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 <has-
permission>, <permission-service> 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 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

[Scott Gray-2]

One thing that came to mind during our "discussion" today and I'm not  
sure how feasible it is but I'll throw it out there anyway:
Most record based permission checks come to down querying the database  
for related records to check various roles and whatnot right?  So what  
if instead of querying the database independently we provided some  
sort of security wrapped delegator to the applications that intercepts  
database queries and automatically appends the required entity  
expressions to the query.

If it is a findOne/getRelatedOne query and no result is returned then  
you throw some sort of authorization exception because obviously the  
user didn't fit the criteria of someone able to view the record.  If  
it's a findList/getRelated then only the permissible records would be  
returned.

So instead of writing scripts for permissions we would write some sort  
of entity expression.  Just a thought.

Regards
Scott

On 2/05/2009, at 1:30 PM, Andrew Zeneski wrote:

> I think everyone needs to step back just a bit. Yes, some code was  
> written, but nothing that drastically changes anything. Actually, I  
> paid very close attention to make sure that this could sit on the  
> side lines so it could be evaluated. Very little effort has been put  
> into the real work of migrating the applications, but that is going  
> to change soon...
>
> So, instead of discussing what should or should not have been done,  
> look at the fact that this entire effort is sitting in the  
> community's lap right this minute. But instead of reviewing what is  
> there, pointing out weaknesses offering suggestions or anything  
> constructive at all, the discussion is solely around whether or not  
> code should have been implemented or not. Let's face it, these  
> documents have been in front of you for over a week, and there was  
> not a single objection or concern raised until today. I have only a  
> limited amount of free time, and if I am going to following this  
> effort through to the end, it needs to have a steady progression. So  
> to be frank, get over it.
>
> Code is being worked on actively for this effort, and I am expecting  
> more involvement as soon as the API is finalized. That said, if you  
> do have something to add, wish to see or just want to be involved,  
> now is the time to be proactive! Otherwise the effort will push  
> forward with the people who are indeed interested in improving  
> security in OFBiz.
>
> Andrew
>
>
>
> On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>
>>
>> --- On Fri, 5/1/09, Scott Gray <[hidden email]> 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
>>
>>
>>
>>
>

[Jacques Le Roux]

Just for discussion convenience, here are the links in Confluence and Jira I think are related to this discussion so far

https://issues.apache.org/jira/browse/OFBIZ-2380 (main task)
http://docs.ofbiz.org/x/-B0 (Andrew's proposition)
http://docs.ofbiz.org/x/JR4 (detailed persmissions)

http://docs.ofbiz.org/x/bR4 (David's comments)
http://docs.ofbiz.org/display/OFBTECH/OFBiz+security (Doc on security so far)
BTW, we should take care of updating the last link.

Jacques

From: "Andrew Zeneski" <[hidden email]>

> 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 <has-
> permission>, <permission-service> 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 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
>

[Andrew Zeneski-2]

Are you saying that we attach some logic to the authorization API  
which returns an EntityCondition object to limit the data returned in  
queries? This goes well with the idea I had to add an  
EntityUtil.filterByPermission() method. However, I don't think this is  
something which would replace scripts (or services) for permissions,  
but would be something along with it to make queries more secure. If  
we can come up with a generic way to implement this (or maybe only  
somewhat generic) I think it would be really useful.

So far here are the list of other things which have been discussed and  
all work well with the current proposal:

1. SimpleRoleCheckDa - A simple role check dynamic access class. This  
would include some new tables to associate table name and role type  
IDs for simple role based checking. You would associate the table  
(i.e. ContentRole) with the permission as well as valid roles (ADMIN,  
OWNER, etc). The simple class can be attach to any permission which  
only requires very simple role based checks.

2. EntityUtil.filterByPermission() - A new method which (like  
filterByDate) takes a list of GenericValue objects and removes the  
ones which the user does not have permission to perform the operation  
on. The permission string would be passed and parsed using the value  
for the entity. Nice way to pull out data a user should not see, but  
limited as it will not work with the ELI.

3. Associate EntityCondition with permissions (correct me if I am  
wrong here) to have a unified way of limiting data in queries. If this  
is possible, the filterByPermission might not be necessary.


Andrew

On May 2, 2009, at 8:02 AM, Scott Gray wrote:

> One thing that came to mind during our "discussion" today and I'm  
> not sure how feasible it is but I'll throw it out there anyway:
> Most record based permission checks come to down querying the  
> database for related records to check various roles and whatnot  
> right?  So what if instead of querying the database independently we  
> provided some sort of security wrapped delegator to the applications  
> that intercepts database queries and automatically appends the  
> required entity expressions to the query.
>
> If it is a findOne/getRelatedOne query and no result is returned  
> then you throw some sort of authorization exception because  
> obviously the user didn't fit the criteria of someone able to view  
> the record.  If it's a findList/getRelated then only the permissible  
> records would be returned.
>
> So instead of writing scripts for permissions we would write some  
> sort of entity expression.  Just a thought.
>
> Regards
> Scott
>
> On 2/05/2009, at 1:30 PM, Andrew Zeneski wrote:
>
>> I think everyone needs to step back just a bit. Yes, some code was  
>> written, but nothing that drastically changes anything. Actually, I  
>> paid very close attention to make sure that this could sit on the  
>> side lines so it could be evaluated. Very little effort has been  
>> put into the real work of migrating the applications, but that is  
>> going to change soon...
>>
>> So, instead of discussing what should or should not have been done,  
>> look at the fact that this entire effort is sitting in the  
>> community's lap right this minute. But instead of reviewing what is  
>> there, pointing out weaknesses offering suggestions or anything  
>> constructive at all, the discussion is solely around whether or not  
>> code should have been implemented or not. Let's face it, these  
>> documents have been in front of you for over a week, and there was  
>> not a single objection or concern raised until today. I have only a  
>> limited amount of free time, and if I am going to following this  
>> effort through to the end, it needs to have a steady progression.  
>> So to be frank, get over it.
>>
>> Code is being worked on actively for this effort, and I am  
>> expecting more involvement as soon as the API is finalized. That  
>> said, if you do have something to add, wish to see or just want to  
>> be involved, now is the time to be proactive! Otherwise the effort  
>> will push forward with the people who are indeed interested in  
>> improving security in OFBiz.
>>
>> Andrew
>>
>>
>>
>> On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>>
>>>
>>> --- On Fri, 5/1/09, Scott Gray <[hidden email]> 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
>>>
>>>
>>>
>>>
>>
>

[Adrian Crum-2]

--- On Sat, 5/2/09, Scott Gray <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: [hidden email]
> Date: Saturday, May 2, 2009, 5:02 AM
> One thing that came to mind during our
> "discussion" today and I'm not sure how
> feasible it is but I'll throw it out there anyway:
> Most record based permission checks come to down querying
> the database for related records to check various roles and
> whatnot right?  So what if instead of querying the database
> independently we provided some sort of security wrapped
> delegator to the applications that intercepts database
> queries and automatically appends the required entity
> expressions to the query.

That's a great idea! My picture of an ideal security refactor is to make more of the framework "security-aware" - like your example here.

-Adrian



     

[David E Jones-3]

On May 1, 2009, at 3:30 PM, Andrew Zeneski wrote:

> 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 :)

Yes, I agree... a discussion and feedback is a far better approach.

> 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.

Subjective benefit.

> 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.

Also a subjective benefit.

-David

[David E Jones-3]

This seemed like as good a message to respond to as any... nice thread  
though!

Since revisionist history seems popular in this thread here is my own:  
One day I saw a Jira issue that pointed to some big documents that  
were in someone's personal space on confluence, and pages I had not  
seen referenced before. Unfortunately posting something to confluence  
doesn't put it in front of very many eyes (ie only those who watch the  
regular updates), more on that below. The next day I saw some code  
going in, and then more and more. Being stuck traveling at the time I  
didn't have time to review or comment, and WHAM! there the code was  
and the ONLY to get any changes to it at that point are to complain  
and fight like hell... being too tired for that and too frustrated  
with that and various other things, I just added my comments to a  
confluence page of my own, and this one is in the open wiki and not in  
my personal space:

http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model

How many people saw it? Well, no matter, if you are interested please  
take a look now.

My personal opinion on this is that the design has only subjective  
improvements and most of it is a big step backwards (easier but less  
flexible, for the services versus direct permission part anyway, and  
we decided long ago that flexibility was better than ease in this  
case; and yes there is a creative way to invoke code attached to  
permissions, but that is a bit inflexible IMO since much permission  
logic involved multiple permissions... it's the artifact we want the  
code attached to not the permission itself), plus will cause migration  
pain for those updating. I'm not against change and progress... unless  
it is change only for the sake of change and founded on someone's  
subjective opinion of what is better and easier.

I see no side-by-side comparisons or concrete improvements or even  
presentation of non-subjective issues to resolve (ie "this is  
prettier, and easier", that's subjective), just a bunch of stuff in  
the documents that is (in my subjective view) just a bunch of BS that  
could have been generated by a "business software BS generator". To  
find some great examples of those, search on google for "bs  
generator", some fun results include:

http://www.atrixnet.com/bs-generator.html
http://www.erikandanna.com/Humor/bullshit_generator.htm

It looks like what I was afraid of is EXACTLY what happened. Andrew  
and various others seem simply not interested in feedback being  
convinced of what they have presented and not wanted to admit any  
appearance of fault, which appreciating and using feedback naturally  
does. If you think that's harsh then bash me like you've bashed  
Adrian. Don't worry... go for it! I happen to have a button with the  
letters "delete" on it, and I've been using it more and more lately.

As for how to move forward? How about we allow development to go on as  
desired, and we'll discuss and modify best practices over time. I will  
revert the changes to the example component (in the spirit of Commit-
Then-Review that some are so fond of... well there's my review and a  
commit to boot!). BTW, thanks Andrew for isolating those in a single  
commit. For examples going forward whle this is still up in the air,  
examples of use new artifacts can be added (ie new service, screen,  
etc), or a patch can be kept on a jira issue for those who want to try  
it out. Once we have decided on best practices moving forward, then we  
can change the example component. Not sure how people want to move  
forward, but for now I have attached the patch here (note that this  
can also be produced with a "svn diff -r 770083:r770408 >  
AuthzExampleComponentSupport.patch" from the ofbiz/framework/exmaple  
directory):

https://issues.apache.org/jira/browse/OFBIZ-2383

For other components let's not be too hasty. I won't get into a commit  
war over the example component, but for the rest I'll gladly do so  
since I think these changes have a negative ROI and this whole thing  
has turned into a big old chest-thumping mess. That being the case,  
sorry for joining in and thumping my own chest.

Hopefully we can discuss some security objectives and common cases we  
want to support, and then evaluate this new proposed approach against  
them and/or establish a new approach based on this. There definitely  
ARE areas where it is currently cumbersome to implement specific  
security related requirements.

-David


On May 1, 2009, at 10:00 PM, Andrew Zeneski wrote:

> In the past, what 8 years that I have been working on OFBiz, not  
> once have I had the masochistic urge to work on something which did  
> not already have some sort  of design. Never will you fine me  
> wishing to refactor something without having the requirements  
> already known. So, you will never find me coming to the table empty  
> handed, and that is exactly what this sort of "request" is asking.
>
> Nor, do I want to review and discuss with someone an idea until they  
> have their thoughts put together. So, what you can expect from me  
> now, in the past and in the future is exactly your first statement.  
> "Here is my design, what do you think..."
>
>
> On May 1, 2009, at 10:56 PM, Adrian Crum wrote:
>
>>
>> It's not the same! There is a big difference between "Here's my  
>> design, what do you think?" and "I'm interested in refactoring the  
>> security framework. Could you help me with the design?"
>>
>> -Adrian
>>
>> --- On Fri, 5/1/09, Scott Gray <[hidden email]> wrote:
>>
>>> From: Scott Gray <[hidden email]>
>>> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
>>> To: [hidden email]
>>> 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
>>> <[hidden email]> wrote:
>>>>
>>>>> From: Scott Gray
>>> <[hidden email]>
>>>>> Subject: Re: Authz API Discussion (was re: svn
>>> commit: r770084)
>>>>> To: [hidden email]
>>>>> 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
>>>>> <[hidden email]> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>

[Scott Gray-2]

Yeah attaching entity conditions to permissions somehow was what I had  
in mind.

Another thing I thought of today was some sort of intelligent  
EntityValue that restricts gets or sets based on permissions defined  
on the security aware delegator.  Stuff like that could pass through  
to form widgets which would automatically hide fields or make them  
read only.

And what about defining permission requirements on request-maps in the  
controller?  They could automatically be applied at every stage of the  
request, service calls, screen/form renders and delegator calls.  Then  
you could specify a required permission in once place only but if  
needed also in various other places where you want to increase the  
granularity.

Regards
Scott

On 3/05/2009, at 6:59 AM, Andrew Zeneski wrote:

> Are you saying that we attach some logic to the authorization API  
> which returns an EntityCondition object to limit the data returned  
> in queries? This goes well with the idea I had to add an  
> EntityUtil.filterByPermission() method. However, I don't think this  
> is something which would replace scripts (or services) for  
> permissions, but would be something along with it to make queries  
> more secure. If we can come up with a generic way to implement this  
> (or maybe only somewhat generic) I think it would be really useful.
>
> So far here are the list of other things which have been discussed  
> and all work well with the current proposal:
>
> 1. SimpleRoleCheckDa - A simple role check dynamic access class.  
> This would include some new tables to associate table name and role  
> type IDs for simple role based checking. You would associate the  
> table (i.e. ContentRole) with the permission as well as valid roles  
> (ADMIN, OWNER, etc). The simple class can be attach to any  
> permission which only requires very simple role based checks.
>
> 2. EntityUtil.filterByPermission() - A new method which (like  
> filterByDate) takes a list of GenericValue objects and removes the  
> ones which the user does not have permission to perform the  
> operation on. The permission string would be passed and parsed using  
> the value for the entity. Nice way to pull out data a user should  
> not see, but limited as it will not work with the ELI.
>
> 3. Associate EntityCondition with permissions (correct me if I am  
> wrong here) to have a unified way of limiting data in queries. If  
> this is possible, the filterByPermission might not be necessary.
>
>
> Andrew
>
> On May 2, 2009, at 8:02 AM, Scott Gray wrote:
>
>> One thing that came to mind during our "discussion" today and I'm  
>> not sure how feasible it is but I'll throw it out there anyway:
>> Most record based permission checks come to down querying the  
>> database for related records to check various roles and whatnot  
>> right?  So what if instead of querying the database independently  
>> we provided some sort of security wrapped delegator to the  
>> applications that intercepts database queries and automatically  
>> appends the required entity expressions to the query.
>>
>> If it is a findOne/getRelatedOne query and no result is returned  
>> then you throw some sort of authorization exception because  
>> obviously the user didn't fit the criteria of someone able to view  
>> the record.  If it's a findList/getRelated then only the  
>> permissible records would be returned.
>>
>> So instead of writing scripts for permissions we would write some  
>> sort of entity expression.  Just a thought.
>>
>> Regards
>> Scott
>>
>> On 2/05/2009, at 1:30 PM, Andrew Zeneski wrote:
>>
>>> I think everyone needs to step back just a bit. Yes, some code was  
>>> written, but nothing that drastically changes anything. Actually,  
>>> I paid very close attention to make sure that this could sit on  
>>> the side lines so it could be evaluated. Very little effort has  
>>> been put into the real work of migrating the applications, but  
>>> that is going to change soon...
>>>
>>> So, instead of discussing what should or should not have been  
>>> done, look at the fact that this entire effort is sitting in the  
>>> community's lap right this minute. But instead of reviewing what  
>>> is there, pointing out weaknesses offering suggestions or anything  
>>> constructive at all, the discussion is solely around whether or  
>>> not code should have been implemented or not. Let's face it, these  
>>> documents have been in front of you for over a week, and there was  
>>> not a single objection or concern raised until today. I have only  
>>> a limited amount of free time, and if I am going to following this  
>>> effort through to the end, it needs to have a steady progression.  
>>> So to be frank, get over it.
>>>
>>> Code is being worked on actively for this effort, and I am  
>>> expecting more involvement as soon as the API is finalized. That  
>>> said, if you do have something to add, wish to see or just want to  
>>> be involved, now is the time to be proactive! Otherwise the effort  
>>> will push forward with the people who are indeed interested in  
>>> improving security in OFBiz.
>>>
>>> Andrew
>>>
>>>
>>>
>>> On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>>>
>>>>
>>>> --- On Fri, 5/1/09, Scott Gray <[hidden email]> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

[Shi Yusen]

Great movement! Exciting!

Only one question, I read your document and I'm not sure whether it's
easy to support multiple OUs of sales, for example:
access:sfa:langhua egovernment sales unit:opportunity
access:sfa:langhua ecomerce sales unit:opportunity
access:sfa:langhua chemistry sales unit:opportunity

Regards,

Shi Yusen/Beijing Langhua Ltd.


在 2009-05-01五的 13:36 -0400，Andrew Zeneski写道：

> I'd like to move the discussion of the new Authz security  
> implementation to this thread. To start off the discussion I will  
> briefly describe what I would like to propose as the NEW best practices.
>
> 1. Single point of contact for ALL security checks, instead of having  
> security embedded in functionality, or tied to services directly, the  
> API should be the governor of all security. This means no more writing  
> security logic in the functionality, and no more permission services  
> attached directly to functionality (services or ecas). This is a bad  
> design IMHO because it spreads the permission logic around in multiple  
> places and makes it impossible to get the same results when checking  
> permissions from different framework tools.
>
> -- We want to be consistent, and be able to obtain the same  
> information from the UI or screen/form as we would get from a service  
> call.
> -- Main point of contact is the Authorization interface.
>
> 2. Permission services become Dynamic Access (DA). Now instead of  
> having permission services attached to services, we have Dynamic  
> Access implementations which can be a compiled Java object, a Groovy  
> script or a Service. My personal preference here is the Groovy script,  
> but the API current supports all three. This DA logic is attached to a  
> permission instead of a service.
>
> -- This allows for extending or changing the permission logic for a  
> specific implementation/customization/application much easier. Since  
> the DAs are all data driven, changing the seed data you can change the  
> logic which is used. This means you no longer have to customize the  
> services or logic in OFBiz to change the way authorization is handled  
> for your company (or client); one less thing to worry about when  
> merging customizations with the open source project.
>
> -- for groovy use "component://path/to/script.groovy" in the  
> dynamicAccess field on SecurityPermission.
> -- for services use "service:serviceName" in the dynamicAccess field  
> on SecurityPermission
> -- for objects use "org.ofbiz.path.to.Object (which implements  
> DynamicAccess)" in the dynamicAccess field on SecurityPermission
>
> 3. Avoid having to check multiple permissions, for example  
> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission  
> format which embeds all permissions which will be accepted:
>
> Example: update:party:contact:10000 - Update the contact information  
> for party 10000
>
> This will allow anyone who has:
> "update" or "update:party" or "update:party:contact" or is granted  
> record level access by the DA logic.
>
> 4. Define permission for users, not admins. Instead of looking for a  
> static permission, set the permission to be checked at the most  
> granular level. When doing so, admin users will always have permission  
> and the API will handle user access using DA logic.
>
> -- see: http://docs.ofbiz.org/x/JR4
>
> That's enough to get started, http://docs.ofbiz.org/x/-B0 contains a  
> lot more details; interested parties are encouraged to read it through.
>
>
> Andrew
>
>
>
>
>
>
>

[Adrian Crum-2]

--- On Sat, 5/2/09, David E Jones <[hidden email]> wrote:
> My personal opinion on this is that the design has only
> subjective improvements and most of it is a big step
> backwards (easier but less flexible, for the services versus
> direct permission part anyway, and we decided long ago that
> flexibility was better than ease in this case; and yes there
> is a creative way to invoke code attached to permissions,
> but that is a bit inflexible IMO since much permission logic
> involved multiple permissions... it's the artifact we
> want the code attached to not the permission itself)

I've been thinking about that aspect of it. If I understand correctly, here are two of the issues being addressed by the new security:

1. Permission checking is being done in scripts, so a programmer is required to change the permission checking logic. An ordinary systems administrator with no knowledge of mini-language would not be able to change how permissions are checked. The new permission string is supposed to make changes to permission checking easier for the non-programmer administrators.

2. Permission checking isn't consistent. Two similar branches of logic will check permissions in two different ways: one will check a permission string, and another will run a script. This is common in the UI versus the services called by the UI. A simple "has permission" check is done in the UI, and then the service invoked runs a script to check permissions.

I agree with you that substituting the permission service with a permission string is too inflexible.

One of the ideas I've been toying with is the idea of a permission expression. I started writing some code for that and was going to put it in Jira, but I decided to put it on the shelf until the dust settles from this thread.

Let's say we took Andrew's new permission string and gave it more oomph - where it could contain functions and such. (The expression language would be simple enough for common administrators to understand.) That could eliminate many of the permission checking scripts. In effect, the permission string becomes a mini-script. This mini-script could be used anywhere a permission string is being used now.

One of the problems I have with what has been proposed so far is that the permission string can be ambiguous when it comes to inserting parameters. For example, "update:example:${exampleId}" - what does that mean? There's no way to tell by looking at it. It would be preferable to have something like "update:example + relatedTo(exampleId)". That permission tells me something - it requires update:example permission and the user must be related to exampleId in some way.

I think permission expressions would solve both of the issues above.

-Adrian




     

[Andrew Zeneski-2]

I must admit this is very disappointing, and not a very "community"  
sort of thing I would expect from someone who is an advocate for a  
"community". Instead, this is a very tyrannical approach to the whole  
thing and very disrespectful. So far the two people who have not seen  
this being a great improvement is you and then once you spoke up  
Adrian followed.

So, the revert was warranted because only you saw fit to revert it.  
Maybe I should start looking over your code and reverting things I  
don't agree with. That would surely drive a this community in the  
right direction <sarcasm>.

Let's look at the current tally:

Anil, Scott and I have voiced approval for this proposal.
You and Adrian have voiced disapproval.

How does 3:2 justify a automatic revert? I think what you have done  
right here was very anti-community and EXTREMELY disrespectful to the  
one person who has been working with you 8 years to bring this project  
to where it is today. So, if your goal in reverting this was to piss  
me off and ruin what little respect I have left for you, it worked.

I will personally revert the rest of the code over the next week.


Andrew



On May 3, 2009, at 2:12 AM, David E Jones wrote:

>
> This seemed like as good a message to respond to as any... nice  
> thread though!
>
> Since revisionist history seems popular in this thread here is my  
> own: One day I saw a Jira issue that pointed to some big documents  
> that were in someone's personal space on confluence, and pages I had  
> not seen referenced before. Unfortunately posting something to  
> confluence doesn't put it in front of very many eyes (ie only those  
> who watch the regular updates), more on that below. The next day I  
> saw some code going in, and then more and more. Being stuck  
> traveling at the time I didn't have time to review or comment, and  
> WHAM! there the code was and the ONLY to get any changes to it at  
> that point are to complain and fight like hell... being too tired  
> for that and too frustrated with that and various other things, I  
> just added my comments to a confluence page of my own, and this one  
> is in the open wiki and not in my personal space:
>
> http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model
>
> How many people saw it? Well, no matter, if you are interested  
> please take a look now.
>
> My personal opinion on this is that the design has only subjective  
> improvements and most of it is a big step backwards (easier but less  
> flexible, for the services versus direct permission part anyway, and  
> we decided long ago that flexibility was better than ease in this  
> case; and yes there is a creative way to invoke code attached to  
> permissions, but that is a bit inflexible IMO since much permission  
> logic involved multiple permissions... it's the artifact we want the  
> code attached to not the permission itself), plus will cause  
> migration pain for those updating. I'm not against change and  
> progress... unless it is change only for the sake of change and  
> founded on someone's subjective opinion of what is better and easier.
>
> I see no side-by-side comparisons or concrete improvements or even  
> presentation of non-subjective issues to resolve (ie "this is  
> prettier, and easier", that's subjective), just a bunch of stuff in  
> the documents that is (in my subjective view) just a bunch of BS  
> that could have been generated by a "business software BS  
> generator". To find some great examples of those, search on google  
> for "bs generator", some fun results include:
>
> http://www.atrixnet.com/bs-generator.html
> http://www.erikandanna.com/Humor/bullshit_generator.htm
>
> It looks like what I was afraid of is EXACTLY what happened. Andrew  
> and various others seem simply not interested in feedback being  
> convinced of what they have presented and not wanted to admit any  
> appearance of fault, which appreciating and using feedback naturally  
> does. If you think that's harsh then bash me like you've bashed  
> Adrian. Don't worry... go for it! I happen to have a button with the  
> letters "delete" on it, and I've been using it more and more lately.
>
> As for how to move forward? How about we allow development to go on  
> as desired, and we'll discuss and modify best practices over time. I  
> will revert the changes to the example component (in the spirit of  
> Commit-Then-Review that some are so fond of... well there's my  
> review and a commit to boot!). BTW, thanks Andrew for isolating  
> those in a single commit. For examples going forward whle this is  
> still up in the air, examples of use new artifacts can be added (ie  
> new service, screen, etc), or a patch can be kept on a jira issue  
> for those who want to try it out. Once we have decided on best  
> practices moving forward, then we can change the example component.  
> Not sure how people want to move forward, but for now I have  
> attached the patch here (note that this can also be produced with a  
> "svn diff -r 770083:r770408 > AuthzExampleComponentSupport.patch"  
> from the ofbiz/framework/exmaple directory):
>
> https://issues.apache.org/jira/browse/OFBIZ-2383
>
> For other components let's not be too hasty. I won't get into a  
> commit war over the example component, but for the rest I'll gladly  
> do so since I think these changes have a negative ROI and this whole  
> thing has turned into a big old chest-thumping mess. That being the  
> case, sorry for joining in and thumping my own chest.
>
> Hopefully we can discuss some security objectives and common cases  
> we want to support, and then evaluate this new proposed approach  
> against them and/or establish a new approach based on this. There  
> definitely ARE areas where it is currently cumbersome to implement  
> specific security related requirements.
>
> -David
>
>
> On May 1, 2009, at 10:00 PM, Andrew Zeneski wrote:
>
>> In the past, what 8 years that I have been working on OFBiz, not  
>> once have I had the masochistic urge to work on something which did  
>> not already have some sort  of design. Never will you fine me  
>> wishing to refactor something without having the requirements  
>> already known. So, you will never find me coming to the table empty  
>> handed, and that is exactly what this sort of "request" is asking.
>>
>> Nor, do I want to review and discuss with someone an idea until  
>> they have their thoughts put together. So, what you can expect from  
>> me now, in the past and in the future is exactly your first  
>> statement. "Here is my design, what do you think..."
>>
>>
>> On May 1, 2009, at 10:56 PM, Adrian Crum wrote:
>>
>>>
>>> It's not the same! There is a big difference between "Here's my  
>>> design, what do you think?" and "I'm interested in refactoring the  
>>> security framework. Could you help me with the design?"
>>>
>>> -Adrian
>>>
>>> --- On Fri, 5/1/09, Scott Gray <[hidden email]> wrote:
>>>
>>>> From: Scott Gray <[hidden email]>
>>>> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
>>>> To: [hidden email]
>>>> 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
>>>> <[hidden email]> wrote:
>>>>>
>>>>>> From: Scott Gray
>>>> <[hidden email]>
>>>>>> Subject: Re: Authz API Discussion (was re: svn
>>>> commit: r770084)
>>>>>> To: [hidden email]
>>>>>> 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
>>>>>> <[hidden email]> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>

[Adrian Crum-2]

--- On Sat, 5/2/09, David E Jones <[hidden email]> wrote:
> My personal opinion on this is that the design has only
> subjective improvements and most of it is a big step
> backwards (easier but less flexible, for the services versus
> direct permission part anyway, and we decided long ago that
> flexibility was better than ease in this case; and yes there
> is a creative way to invoke code attached to permissions,
> but that is a bit inflexible IMO since much permission logic
> involved multiple permissions... it's the artifact we
> want the code attached to not the permission itself)

Take your comment - "it's the artifact we want the code attached to not the permission itself" - and combine that with Scott's suggestion to have a security-aware delegator, and you have a solution I proposed years ago: a domain-driven security system.

In a domain-driven security system, each OFBiz artifact is responsible for handling security for itself. There is no explicit permission-checking code. Each OFBiz artifact identifies itself in a security domain. When a user tries to use that artifact, it checks the user's permissions against its own position in the domain.

Using the Example component's EditExample screen as an example, here is what a security domain might look like:

framework
  example
    screen
      EditExample (screen)
        EditExample (form)

Permissions are hierarchical - each artifact inherits permissions from the artifact above it. This is very similar to what Andrew is trying to achieve, but it's different because the artifacts themselves control the security - there is no call to a permission service with a permission string.

Here's what it might look like in ExampleScreens.xml:

<screens xmlns:xsi="...">
  <security domain="framework:example:screen"/>

  <screen name="EditExample">
    <security domain="EditExample"/>
    ...
  </screen>

</screens>

Notice there are no explicit permission checks. Instead, each artifact has identified itself in the security domain.

When the widget is run, each artifact checks the user's permissions against its own security domain. So, the EditExample screen would look for the framework:example:screen:EditExample" permissions and handle itself accordingly. (Andrew - this is why I suggested having permission checking code return all permissions for a context.)

If a user has the access:framework:example:screen:EditExample permission, the screen will display.

Let's take a look at what happens in the form widget. Here is what ExampleForms would look like:

<form name="EditExample" type="single" target="updateExample" title="" default-map-name="example">
  <security domain="EditExample"/>
  ...
</form>

Again, when the widget is run, each artifact checks the user's permissions against its own security domain. So, the EditExample form would look for the framework:example:screen:EditExample:EditExample" permissions and handle itself accordingly.

Let's say the user doesn't have any permissions for that context. Keep in mind permissions are hierarchical - so the form widget would work its way up the hierarchy to find permissions. If a user has the access:framework:example:screen:EditExample permission, the form will display plain text with no input fields. If the user has the update:framework:example:screen:EditExample permission, the form will provide input fields.

Form fields could identify themselves in the security domain as well - so only the fields the user is permitted to access will appear.

Service definitions and entities could identify themselves in the security domain in a similar way, and have similar permissions checking logic. Some examples:

framework
  example
    service
      updateExample

framework
  example
    entity
      Example

The nice thing about this approach is that you could leverage the artifact gathering code to display the security domain as a tree - with permission checkboxes next to each "leaf." That would enable any administrator to manage user security easily.

-Adrian
 


     

[David E Jones-3]

Please don't revert the rest of the code. The point is that this needs  
time to mature, so it should stay in there but not become the  
default... not YET anyway.

Also, please don't be personally offended by this. Just because there  
are comments and feedback doesn't mean something has no merit, it just  
means that some adjustments to it might be able to improve it. That's  
what collaboration is all about, and I guess if you'd rather not do it  
than have other people comments on it and make changes to it then  
collaboration will be difficult.

Just to clear that up... are you saying you would rather not do any of  
this than make some changes and refinements to it based on feedback? I  
hope that's not the case. My intent with this, as I explained in my  
email, is to make a compromise and allow development and improvement  
on this to continue without impact on other parts of the project until  
it is more ready for that.

On a side note: I personally don't like the CTR way of doing things  
and I like the pattern of discussion and covering any dissent before I  
throw things in. However, in this case I did so because that seemed to  
be the preferred working pattern and I'll admit it is a more efficient  
way of doing things in some cases.

-David


On May 3, 2009, at 10:13 AM, Andrew Zeneski wrote:

> I must admit this is very disappointing, and not a very "community"  
> sort of thing I would expect from someone who is an advocate for a  
> "community". Instead, this is a very tyrannical approach to the  
> whole thing and very disrespectful. So far the two people who have  
> not seen this being a great improvement is you and then once you  
> spoke up Adrian followed.
>
> So, the revert was warranted because only you saw fit to revert it.  
> Maybe I should start looking over your code and reverting things I  
> don't agree with. That would surely drive a this community in the  
> right direction <sarcasm>.
>
> Let's look at the current tally:
>
> Anil, Scott and I have voiced approval for this proposal.
> You and Adrian have voiced disapproval.
>
> How does 3:2 justify a automatic revert? I think what you have done  
> right here was very anti-community and EXTREMELY disrespectful to  
> the one person who has been working with you 8 years to bring this  
> project to where it is today. So, if your goal in reverting this was  
> to piss me off and ruin what little respect I have left for you, it  
> worked.
>
> I will personally revert the rest of the code over the next week.
>
>
> Andrew
>
>
>
> On May 3, 2009, at 2:12 AM, David E Jones wrote:
>
>>
>> This seemed like as good a message to respond to as any... nice  
>> thread though!
>>
>> Since revisionist history seems popular in this thread here is my  
>> own: One day I saw a Jira issue that pointed to some big documents  
>> that were in someone's personal space on confluence, and pages I  
>> had not seen referenced before. Unfortunately posting something to  
>> confluence doesn't put it in front of very many eyes (ie only those  
>> who watch the regular updates), more on that below. The next day I  
>> saw some code going in, and then more and more. Being stuck  
>> traveling at the time I didn't have time to review or comment, and  
>> WHAM! there the code was and the ONLY to get any changes to it at  
>> that point are to complain and fight like hell... being too tired  
>> for that and too frustrated with that and various other things, I  
>> just added my comments to a confluence page of my own, and this one  
>> is in the open wiki and not in my personal space:
>>
>> http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model
>>
>> How many people saw it? Well, no matter, if you are interested  
>> please take a look now.
>>
>> My personal opinion on this is that the design has only subjective  
>> improvements and most of it is a big step backwards (easier but  
>> less flexible, for the services versus direct permission part  
>> anyway, and we decided long ago that flexibility was better than  
>> ease in this case; and yes there is a creative way to invoke code  
>> attached to permissions, but that is a bit inflexible IMO since  
>> much permission logic involved multiple permissions... it's the  
>> artifact we want the code attached to not the permission itself),  
>> plus will cause migration pain for those updating. I'm not against  
>> change and progress... unless it is change only for the sake of  
>> change and founded on someone's subjective opinion of what is  
>> better and easier.
>>
>> I see no side-by-side comparisons or concrete improvements or even  
>> presentation of non-subjective issues to resolve (ie "this is  
>> prettier, and easier", that's subjective), just a bunch of stuff in  
>> the documents that is (in my subjective view) just a bunch of BS  
>> that could have been generated by a "business software BS  
>> generator". To find some great examples of those, search on google  
>> for "bs generator", some fun results include:
>>
>> http://www.atrixnet.com/bs-generator.html
>> http://www.erikandanna.com/Humor/bullshit_generator.htm
>>
>> It looks like what I was afraid of is EXACTLY what happened. Andrew  
>> and various others seem simply not interested in feedback being  
>> convinced of what they have presented and not wanted to admit any  
>> appearance of fault, which appreciating and using feedback  
>> naturally does. If you think that's harsh then bash me like you've  
>> bashed Adrian. Don't worry... go for it! I happen to have a button  
>> with the letters "delete" on it, and I've been using it more and  
>> more lately.
>>
>> As for how to move forward? How about we allow development to go on  
>> as desired, and we'll discuss and modify best practices over time.  
>> I will revert the changes to the example component (in the spirit  
>> of Commit-Then-Review that some are so fond of... well there's my  
>> review and a commit to boot!). BTW, thanks Andrew for isolating  
>> those in a single commit. For examples going forward whle this is  
>> still up in the air, examples of use new artifacts can be added (ie  
>> new service, screen, etc), or a patch can be kept on a jira issue  
>> for those who want to try it out. Once we have decided on best  
>> practices moving forward, then we can change the example component.  
>> Not sure how people want to move forward, but for now I have  
>> attached the patch here (note that this can also be produced with a  
>> "svn diff -r 770083:r770408 > AuthzExampleComponentSupport.patch"  
>> from the ofbiz/framework/exmaple directory):
>>
>> https://issues.apache.org/jira/browse/OFBIZ-2383
>>
>> For other components let's not be too hasty. I won't get into a  
>> commit war over the example component, but for the rest I'll gladly  
>> do so since I think these changes have a negative ROI and this  
>> whole thing has turned into a big old chest-thumping mess. That  
>> being the case, sorry for joining in and thumping my own chest.
>>
>> Hopefully we can discuss some security objectives and common cases  
>> we want to support, and then evaluate this new proposed approach  
>> against them and/or establish a new approach based on this. There  
>> definitely ARE areas where it is currently cumbersome to implement  
>> specific security related requirements.
>>
>> -David
>>
>>
>> On May 1, 2009, at 10:00 PM, Andrew Zeneski wrote:
>>
>>> In the past, what 8 years that I have been working on OFBiz, not  
>>> once have I had the masochistic urge to work on something which  
>>> did not already have some sort  of design. Never will you fine me  
>>> wishing to refactor something without having the requirements  
>>> already known. So, you will never find me coming to the table  
>>> empty handed, and that is exactly what this sort of "request" is  
>>> asking.
>>>
>>> Nor, do I want to review and discuss with someone an idea until  
>>> they have their thoughts put together. So, what you can expect  
>>> from me now, in the past and in the future is exactly your first  
>>> statement. "Here is my design, what do you think..."
>>>
>>>
>>> On May 1, 2009, at 10:56 PM, Adrian Crum wrote:
>>>
>>>>
>>>> It's not the same! There is a big difference between "Here's my  
>>>> design, what do you think?" and "I'm interested in refactoring  
>>>> the security framework. Could you help me with the design?"
>>>>
>>>> -Adrian
>>>>
>>>> --- On Fri, 5/1/09, Scott Gray <[hidden email]> wrote:
>>>>
>>>>> From: Scott Gray <[hidden email]>
>>>>> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
>>>>> To: [hidden email]
>>>>> 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
>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>> From: Scott Gray
>>>>> <[hidden email]>
>>>>>>> Subject: Re: Authz API Discussion (was re: svn
>>>>> commit: r770084)
>>>>>>> To: [hidden email]
>>>>>>> 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
>>>>>>> <[hidden email]> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>