Re: [PROPOSITION] Demos: replace old by trunk framework only

[Jacques Le Roux]

Of course, but I like to be able to get from the backend to the frontend when 
it's possible.
I don't see any troubles keeping them once it's handled that way, but 
theoretical ones .

Of course if the community prefers to remove them it's far easier and was what 
I wanted to do initially before having this idea of hiding links

Jacques


Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :

Simple, don't put any logic that points outwards from the framework. That
is sort of why we split repositories in the first place.

On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux 
wrote:


Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :

Makes sense. However, i note reading in the JIRA that "we can simply hide
the button when the ecommerce component is not present". That sounds like
logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.


Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques


On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the framework only

and

the
framework+plugins

I must add:

* since the old is often no longer supported and a release of it is
always available (today R13) for users. I think removing the old demo is
maybe
  not a big deal.
* I found several cases where people, new to OFBiz, considered OFBiz

as

what we call the framework, and were considering the plugins as

optional.

What do you think?

Jacques

Re: [PROPOSITION] Demos: replace old by trunk framework only

[Taher Alkhateeb]

Simple, don't put any logic that points outwards from the framework. That
is sort of why we split repositories in the first place.

On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux 
wrote:

> Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
> > Makes sense. However, i note reading in the JIRA that "we can simply hide
> > the button when the ecommerce component is not present". That sounds like
> > logic that points outwards which is a bad design IMHO.
> I could not find a better way yet, I'm all ears for ideas.
>
> > Anyway, I think it is a reasonable step to take. +1
> I attached a patch for today at OFBIZ-9241
>
> Jacques
>
> >
> > On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com>
> > wrote:
> >
> >> Hi,
> >>
> >> The proposition is in the title.
> >>
> >> With the changes I'm introducing with OFBIZ-9241 there will few
> >> differences in UI (and presence of js files) between the framework only
> and
> >> the
> >> framework+plugins
> >>
> >> I must add:
> >>
> >>* since the old is often no longer supported and a release of it is
> >> always available (today R13) for users. I think removing the old demo is
> >> maybe
> >>  not a big deal.
> >>* I found several cases where people, new to OFBiz, considered OFBiz
> as
> >> what we call the framework, and were considering the plugins as
> optional.
> >>
> >> What do you think?
> >>
> >> Jacques
> >>
> >>
>
>

Re: [PROPOSITION] Demos: replace old by trunk framework only

[Nicolas Malin]

I agree. +1


On 20/08/2018 19:01, Jacques Le Roux wrote:

Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
Makes sense. However, i note reading in the JIRA that "we can simply 
hide
the button when the ecommerce component is not present". That sounds 
like

logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.


Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques



On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux 


wrote:


Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the framework 
only and

the
framework+plugins

I must add:

   * since the old is often no longer supported and a release of it is
always available (today R13) for users. I think removing the old 
demo is

maybe
 not a big deal.
   * I found several cases where people, new to OFBiz, considered 
OFBiz as
what we call the framework, and were considering the plugins as 
optional.


What do you think?

Jacques

Re: HTTP Compression not working for some files (JS and CSS)

[Scott Gray]

See the note under the compression config here:
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Standard_Implementation

Regards
Scott


On 20 August 2018 at 07:38, girish.vasmat...@hotwaxsystems.com <
girish.vasmat...@hotwaxsystems.com> wrote:

>
>
> On 2018/08/20 07:20:38, Michael Brohl  wrote:
> > Hi Girish,
> >
> > how did you check that these files are not getting compressed before the
> > transfer?
> >
> > They are decompressed by the browser after the transfer so you won't see
> > that they were compressed.
> >
> > Regards,
> >
> > Michael
> >
> >
> > Am 20.08.18 um 09:12 schrieb girish.vasmat...@hotwaxsystems.com:
> > > Hi Devs!!!
> > >
> > > I see that we have enabled HTTP compression in in the HTTP and HTTPS
> connectors, but I am observing that it is not working properly for some of
> the JS and CSS files.
> > >
> > > All medium to large files (more than 50 KB or so) are not getting
> compressed. Has anyone else observed the same? I can definitely see that
> Content-Encoding:gzip response header is set for all the files that are
> compressed and the transfer size does indicate they were compressed based
> on what size I see on the disk.
> > >
> > >
> > > Thanks,
> > > Girish Vasmatkar
> > > HotWax Systems
> > >
> >
> >
> >
> Hi Michael
>
> I can see the response headers in Chrome developers tools. For some files
> for example, OfbizUtil.js, Content-Encoding:gzip indicating that it was
> compressed by the server and received in compressed format.
> For the other ones, no Content-Encoding header is present. Also, there is
> a "Size" tab and a "Transferred" tab in FireBug showing 47.13 KB and 11.79
> KB values respectively. For select2-4.0.6.js which is one of the one I
> don't see come compressed the corresponding values are 143.01 KB and 142.80
> KB and the Content-Encoding header is also absent.
>
> Thanks and Regards,
> Girish Vasmatkar
> HotWax Systems
>
>
>

Re: [PROPOSITION] Demos: replace old by trunk framework only

[Jacques Le Roux]

Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :

Makes sense. However, i note reading in the JIRA that "we can simply hide
the button when the ecommerce component is not present". That sounds like
logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.


Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques



On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux 
wrote:


Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the framework only and
the
framework+plugins

I must add:

   * since the old is often no longer supported and a release of it is
always available (today R13) for users. I think removing the old demo is
maybe
 not a big deal.
   * I found several cases where people, new to OFBiz, considered OFBiz as
what we call the framework, and were considering the plugins as optional.

What do you think?

Jacques

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

[Jacques Le Roux]

Thanks Jinghai,

This much clarifies things. I'm all for these steps by steps, in Jiras with 
patches :)

I'm not a big fan of blockchain (yet?) but let's see...

Just as off topic notes to share:

For a client I have implement the SAML2 protocol. I see it similar as SOAP in its nature: not trendy but with a large spectrum, very serious and sure 
(read well secured).

From my experience, using the Shibboleth framework is the best way to integrate 
SAML IMO. But that's really for big (global) organisations.

   
https://stackoverflow.com/questions/29843794/cas-server-with-saml-2#answer-29893206

BTW I read "No standard way to force logout, though (CAS has this feature)." at 
bottom of

   
https://stackoverflow.com/questions/2033026/sso-with-cas-or-oauth#answer-3181557

SAML has also this feature, and there is a joke about it: 
https://www.theonion.com/after-checking-your-bank-account-remember-to-log-out-1819584860

Just try to implement and then use SLO (Single Log Out) and you will maybe 
share the idea.

Have fun :)

Jacques


Le 20/08/2018 à 17:54, Shi Jinghai a écrit :

Hi Jacques,

The LDAP plugin can be split to 2 parts, LDAP and CAS client. The LDAP part can 
be removed, because Andrian Crum implemented it in framework/security, he 
insisted it's earlier than mine, I agree now. The CAS client can be merged into 
passport plugin. Personally I think the CAS protocol is the origin of OAuth2 
and many others, and it's stricter than OAuth2 as its service token can be 
used/validated only once, to prevent naughty children in Yale University reuse 
the service tokens, well typically access token in OAuth2 has a much longer 
life time (from hours to month).

The CAS plugin I mentioned is a cas-server, to make OFBiz as a central OAuth2 
provider. It's not related to OFBIZ-10307, it's a part of WebPOS2 contribution 
I promised in last year. Adding method attribute in request map (OFBIZ-10438) 
is the 1st step, CAS plugin is the 2nd step, OpenAPI (swagger) plugin is the 
3rd step, then the WebPOS2 (Angular) plugin, and perhaps a Wechat/Facebook 
(React) mini app further. Not in a hurry, we can achieve it step by step :)

Briefly, this belongs to mobile support line. I'll try to open a blockchain 
support line when community has common interests in blockchain area.

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月20日 15:59
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi Jinghai,

I'm not sure why you want to create a CAS plugin. At least it's unrelated with 
OFBIZ-1307

Also are you aware of 
https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#CASLDAP ?

Does this still work? Do we need a new plugin?

Thanks

Jacques


Le 19/08/2018 à 22:00, Shi Jinghai a écrit :

Thanks Jacques!

If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week. 
I have cas 4.2.x version running in production environment, I'll upgrade it to 
cas 5.2.x and then release it.



-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月19日 18:34
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi Jinghai,

Actually I did not pick auth0 (not to be confused with 
https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those 
need a central
Identify server (as is the SAML protocol).

I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and 
https://jwt.io/ to

Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed 
in authentication"

Thanks for your interest.

Jacques


Le 17/08/2018 à 09:02, Shi Jinghai a écrit :

Hi Jacques,

OK, I think the redis topic is jumped to next step.

I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose 
auth0[2] rather than CAS. And is the implement OAuth2 alliance?

[1] https://github.com/apereo/cas
[2] https://auth0.com/

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月16日 2:08
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi Jinghai,

The problem with the token master secret key is to guarantee its secrecy at max.

We already discussed different solutions at https://s.apache.org/7yyR and 
https://s.apache.org/IBDM

How is Redis more secure than Postgres for storing values?

Thanks

Jacques


Le 15/08/2018 à 14:37, Shi Jinghai a écrit :

Dear Jacques,

On how to store the Tokens, as a token is a key, value is the UserLogin entity 
and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in 
db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs 
invested Redis team in last year[3]. It's common view now in China that Redis 
is better than any others including 

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

[Shi Jinghai]

Hi Jacques,

The LDAP plugin can be split to 2 parts, LDAP and CAS client. The LDAP part can 
be removed, because Andrian Crum implemented it in framework/security, he 
insisted it's earlier than mine, I agree now. The CAS client can be merged into 
passport plugin. Personally I think the CAS protocol is the origin of OAuth2 
and many others, and it's stricter than OAuth2 as its service token can be 
used/validated only once, to prevent naughty children in Yale University reuse 
the service tokens, well typically access token in OAuth2 has a much longer 
life time (from hours to month).

The CAS plugin I mentioned is a cas-server, to make OFBiz as a central OAuth2 
provider. It's not related to OFBIZ-10307, it's a part of WebPOS2 contribution 
I promised in last year. Adding method attribute in request map (OFBIZ-10438) 
is the 1st step, CAS plugin is the 2nd step, OpenAPI (swagger) plugin is the 
3rd step, then the WebPOS2 (Angular) plugin, and perhaps a Wechat/Facebook 
(React) mini app further. Not in a hurry, we can achieve it step by step :)

Briefly, this belongs to mobile support line. I'll try to open a blockchain 
support line when community has common interests in blockchain area.

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 
发送时间: 2018年8月20日 15:59
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi Jinghai,

I'm not sure why you want to create a CAS plugin. At least it's unrelated with 
OFBIZ-1307

Also are you aware of 
https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#CASLDAP ?

Does this still work? Do we need a new plugin?

Thanks

Jacques


Le 19/08/2018 à 22:00, Shi Jinghai a écrit :
> Thanks Jacques!
>
> If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next 
> week. I have cas 4.2.x version running in production environment, I'll 
> upgrade it to cas 5.2.x and then release it.
>
>
>
> -邮件原件-
> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
> 发送时间: 2018年8月19日 18:34
> 收件人: dev@ofbiz.apache.org
> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed 
> in authentication
>
> Hi Jinghai,
>
> Actually I did not pick auth0 (not to be confused with 
> https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those 
> need a central
> Identify server (as is the SAML protocol).
>
> I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and 
> https://jwt.io/ to
>
> Please refer to OFBIZ-10307 "Navigate from a domain to another with automated 
> signed in authentication"
>
> Thanks for your interest.
>
> Jacques
>
>
> Le 17/08/2018 à 09:02, Shi Jinghai a écrit :
>> Hi Jacques,
>>
>> OK, I think the redis topic is jumped to next step.
>>
>> I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why 
>> choose auth0[2] rather than CAS. And is the implement OAuth2 alliance?
>>
>> [1] https://github.com/apereo/cas
>> [2] https://auth0.com/
>>
>> Kind Regards,
>>
>> Shi Jinghai
>>
>>
>> -邮件原件-
>> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
>> 发送时间: 2018年8月16日 2:08
>> 收件人: dev@ofbiz.apache.org
>> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed 
>> in authentication
>>
>> Hi Jinghai,
>>
>> The problem with the token master secret key is to guarantee its secrecy at 
>> max.
>>
>> We already discussed different solutions at https://s.apache.org/7yyR and 
>> https://s.apache.org/IBDM
>>
>> How is Redis more secure than Postgres for storing values?
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 15/08/2018 à 14:37, Shi Jinghai a écrit :
>>> Dear Jacques,
>>>
>>> On how to store the Tokens, as a token is a key, value is the UserLogin 
>>> entity and/or other info, a key-value db, Redis[1] is a good choice. Redis 
>>> is no.7 in db ranking in Aug 2018[2], becomes more and more popular. 
>>> Goldman Sachs invested Redis team in last year[3]. It's common view now in 
>>> China that Redis is better than any others including Gemfire of Pivotal, 
>>> the railway ticket system of China replaced its 3 Gemfire clusters with 3 
>>> Redis clusters last year and then there are much less complains on how 
>>> difficulties to buy spring festival tickets.
>>>
>>> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>>>
>>> [1] https://redis.io/
>>> [2] https://db-engines.com/en/ranking
>>> [3] 
>>> https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
>>> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>>>
>>> BTW, I'll try to review the patches.
>>>
>>> Kind Regards,
>>>
>>> Shi Jinghai
>>>
>>> -邮件原件-
>>> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
>>> 发送时间: 2018年8月15日 15:09
>>> 收件人: dev@ofbiz.apache.org
>>> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in 
>>> authentication
>>>
>>> 

Re: OFBiz Contributors Best Practices was [Re: svn commit: r1838320 ...]

[Jacques Le Roux]

Hi Gil,

Inline..

Le 20/08/2018 à 11:48, Gil Portenseigne a écrit :

Hello Jacques, All,

I do not agree about creating a new jira, since the improvement has
design flaw (i will add a comment into the Jira introducing it) in my
opinion leading to breaking thread safety in ModelForm.java.

That's indeed something we can't take lightly


And Taking into consideration Michael preference for reverting,
the best way to go in my opinion, is to revert and rework the feature.
I'd be glad to help out with that :).

That sounds like the best solution in this case indeed.


All details here : https://s.apache.org/C9VF (within the quotation for
thread safe matter)

For clarifying the policy and writing it down +1

OK thanks, l'll wait other opinions, and hopefully help, before rephrasing.

Jacques


Gil

Le dimanche 19 août 2018 à 14:49:31 (+0200), Jacques Le Roux a écrit :

Hi All,

Yesterday Suraj asked me on HipChat what to do about OFBIZ-7598
 where Gil spotted an
issue. Here is my answer:

Hi @SurajKhurana , we have not a clearly established policy for that case. 
Should we reuse the current Jira or should we rather create a new Jira
to fix the issue? It seems to me though that we should rather create a new 
Jira because, after the commit, it's a fix not an improvement . This
Jira should have a "Broken By" link referring to the original Jira. I see 
that Gil reopened the original Jira so better to close it also. It makes
things more clear.
While at it, I'll create a thread about this point in dev ML to get a 
consensus before writing this policy in

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices



I shamelessly hijack this thread because it seems related to me and Michael
have good points below (he also was the 1st to clearly suggest the solution
I advised to Suraj in HipChat).
And I believe that, to avoid rehearsing things, we should rewrite, as concisely 
as possible, what Michael suggests below (not an easy thing)

Thoughts?

And I agree with Nicolas, helping others is always good. At some point you will 
maybe even find helping yourself in the future.
Damn sometimes I can't even understand my own code... never happened to
you?... This may help: https://twitter.com/romiem/status/1030438339390910464
https://twitter.com/romiem/status/1030438
339390910464 (I sure have the last book on end)

Enjoy the rest of your weekend :)

Jacques

Le 19/08/2018 à 11:28, Michael Brohl a écrit :

I have not the time to dig into the specific details right now so will just 
give my thoughts on the process in general because of the citations:

1. we have to distinguish between (a) completely new functionality or
major refactorings and (b) the enhancement of functionality which is
already in the code base

2. for (a), we should first have consenus that we want the proposed
solution and we should look for a complete, well designed and carefully
tested solution before the first commit will be done. This is to prevent
the introduction of new problematic code.

3. for (b), I think every improvement of existing code/functionality
helps and should be committed if there are no flaws in the design or
technical solution and it does not break existing funtionality. of
course, it should be complete within the *scope* of the improvement.

4. if the solution for (b) does not cover other wishes or things which
could be enhanced also, this would be no reason to not commit the
improvement. If people have further requirements, they can provide
concepts and solutions/patches anytime to make things better.

In this case, for me it is important if Suraj's commit

a. breaks anything?

b. is vetoed by other committers in view of code quality or design flaws?

If none of these questions get a "yes", then I see no reason to revert.

If you have additional requirements, you are encouraged to provide solutions or 
concepts for them.

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 19.08.18 um 09:25 schrieb Pierre Smits:

Please read the comment in the related ticket [1]

https://issues.apache.org/jira/browse/OFBIZ-7482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584721#comment-16584721



Best regards,

Pierre Smits

Apache Trafodion , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

On Sat, Aug 18, 2018 at 9:01 PM, Michael Brohl 
wrote:


How do these citations relate to Suraj‘s work?

Please provide arguments in your own words if you think someone‘s work has
flaws and should be reverted.

Thanks,
Michael



Am 18.08.2018 um 13:54 schrieb Pierre Smits :

As Michael 

Re: [PROPOSITION] Demos: replace old by trunk framework only

[Taher Alkhateeb]

Makes sense. However, i note reading in the JIRA that "we can simply hide
the button when the ecommerce component is not present". That sounds like
logic that points outwards which is a bad design IMHO.

Anyway, I think it is a reasonable step to take. +1

On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux 
wrote:

> Hi,
>
> The proposition is in the title.
>
> With the changes I'm introducing with OFBIZ-9241 there will few
> differences in UI (and presence of js files) between the framework only and
> the
> framework+plugins
>
> I must add:
>
>   * since the old is often no longer supported and a release of it is
> always available (today R13) for users. I think removing the old demo is
> maybe
> not a big deal.
>   * I found several cases where people, new to OFBiz, considered OFBiz as
> what we call the framework, and were considering the plugins as optional.
>
> What do you think?
>
> Jacques
>
>

[PROPOSITION] Demos: replace old by trunk framework only

[Jacques Le Roux]

Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few differences in UI (and presence of js files) between the framework only and the 
framework+plugins


I must add:

 * since the old is often no longer supported and a release of it is always 
available (today R13) for users. I think removing the old demo is maybe
   not a big deal.
 * I found several cases where people, new to OFBiz, considered OFBiz as what 
we call the framework, and were considering the plugins as optional.

What do you think?

Jacques

Re: 答复: New Impersonate Feature : OFBIZ-10515

[Jacques Le Roux]

Anyway an admin can do that and much other things by directly poking in the DB

So not really a concern for me

Jacques


Le 20/08/2018 à 14:04, Pierre Smits a écrit :

Consider this:
- having it enabled by default (as suggested by many)
- enabling a user with higher privileges (suggested to be the OFBiz Admin)
to impersonate someone with lower privileges
- this user with higher privileges can now create/alter/etc... transactions
in accounting, ordermgr, warehousing, ecommence, etc. through OFBiz as the
impersonated user
- this user can prevent - through OFBiz - that others can see
UserLoginHistory.
- impersonation is in many countries - by law - a criminal offence
- this goes directly against GDPR

Caution is the Mother of the Porcelain Cabinet (as a saying in the
Netherlands goes). Especially when introducing features that have an impact
on security aspects.


Best regards,

Pierre Smits

Apache Trafodion , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

On Mon, Aug 20, 2018 at 12:04 PM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:


I don't have a strong opinion on this, and I am open. My personal
preference is pehaps to just 'login as' instead of impersonate with normal
user login history. The reason for my preference is having the least amount
of code written and least security worries. I find the impersonate feature
also lovely and quite useful. So both directions are okay for me.

On Mon, Aug 20, 2018, 12:07 PM Gil Portenseigne <
gil.portensei...@nereide.fr>
wrote:


Hello Taher,

Thanks for your ideas, i think that had helped making it pop into
Nicolas answer to Pierre (that i just annoted).

I hope the idea, that seem a mix of yours could be good enough, a

property

that :
* by default allow any impersonation to be done in non-preproduction env,
  without logging out the user. (less security requirement)
* else, impersonation will logout the user impersonated, and restrict
  impersonation to one only for this user, during impersonation time.

The audit could be done in UserLoginHistory entity, storing
impersonation period.

Regards

Gil

Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :

One idea that comes to my mind which might be useful is that we add a
flag in general.properties that by default enables this feature, and
we can then specify in the documentation that to secure OFBiz we need
to disable this feature so that it can be used in development but
disabled in production for people who prefer to be on the safe side. I
also like the suggestions from Pierre on perhaps having some kind of
audit trail, just like we have a log of party visits, we can have a
log of impersonation visits for example.

Another idea, is perhaps to avoid completely persisting the session
into the system. In other words, once I impersonate some user, it's
done, I AM that user and I cannot go back. I have to log out and log
back in to access the system again as an admin. That might be a bit
more secure because we don't touch the session data.

All food for thought, and I appreciate getting more feedback from the

community.

On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits 

wrote:

Impressive...

This seems to be an in-OFBiz equivalent of an OS take-over tool like
Microsoft's Remote Desktop. The business case (and use cases) are

explained

insufficiently in this thread or in the ticket ([1]) why

incorporating

this

in the repo should be favourable over having the adopting business
implement implement the OS take-over tool. What I feel missing here

(and in

the ticket) is the reference to the previous thread, which might

explain

the business case. I suggest to have a link to this thread also in

the

ticket

Based on a cursory review of the patch, it is lacking serious aspects

that

will boost the confidence of any business adopter that this feature

will

not jeopardise their business operations. As it is now, I find the

patch to

basic to be committed to the repo and be included in any new release.

As I see it it allows anybody with the IMPERSONATE_ADMIN permission

take

over any other ID and perform actions under that ID at anytime. I did

not

see any functionality (I am spitballing here) that:

1. would exclude any particular ID from being taken over (as a

default

configuration)
2. would allow a user to disable the feature for their own account
(overriding the default permission of impersonation)
3. would allow a user to explicitly allow its ID to be taken over

by

someone else, AND limit it for a specific amount of time

(overriding aspect

#2 above).
4. would prohibit the impersonator to take over an ID when the

user

of

the ID is NOT logged in (which should be an additional 

Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

[Jacques Le Roux]

Thanks Deepak,

I also suppose the session has always a delegator in.

Because we can always get a delegator from the dispatcher, not the reverse, if I would get this way, to keep things consistent, I would verify that 
session has always a dispatcher in, and document it in the screen variable wiki page.


Of course handling it only in these 3 cases is not bad too, just that there are 
maybe other cases I'm unaware of.

Jacques


Le 20/08/2018 à 13:05, Deepak Dixit a écrit :

Thanks Jacques,

I added this in my TODO list, I agree with Michael's comment.
I'll check and create a ticket if needed.

Thanks & Regards
--
Deepak Dixit


On Mon, Aug 20, 2018 at 12:36 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Deepak,

I used this way because it starts in Groovy with
 ProductSearchSession.getProductSearchResult(request, delegator,
prodCatalogId)
the session is not in the request, and there is no alternative signature
for ProductSearchSession::getProductSearchResult
As I did not want to get too deep in that I preferred this simple way at
the root in Groovy

Please amend it if you see a better way to do it.

Thanks

Jacques



Le 20/08/2018 à 06:33, Deepak Dixit a écrit :


Hi Jacques,

I think instead of setting dispatcher in groovy files I think we can fix
the work done under OFBIZ-9164

Instead of getting dispatcher from a session we can get this from the
request or can use the different method signature of
searchGetConstraintStrings method.
{code}

LocalDispatcher dispatcher = (LocalDispatcher)
request.getAttribute("dispatcher");

{code}



Thanks & Regards
--
Deepak Dixit


On Sun, Aug 19, 2018 at 9:00 PM,  wrote:

Author: jleroux

Date: Sun Aug 19 15:30:42 2018
New Revision: 1838381

URL: http://svn.apache.org/viewvc?rev=1838381=rev
Log:
Fixed: Search in Ecommerce no longer works
(OFBIZ-10531)

I guess that when I worked on OFBIZ-9164 I broke that.

I found 3 occurences where the dispatcher was not in the session because
the
session comes from the request and the request has not it in.

Modified:
  ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
  ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
  ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy

Modified: ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev=
1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19 15:30:42
2018
@@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
   module = "KeywordSearch.groovy"

   // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
   ProductSearchSession.processSearchParameters(parameters, request)
   prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
   result = ProductSearchSession.getProductSearchResult(request,
delegator,
prodCatalogId)

Modified: ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/product/groovyScripts/catalog/find/KeywordSearc
h.groovy?rev=
1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19 15:30:42 2018
@@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
   module = "KeywordSearch.groovy"

   // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
   ProductSearchSession.processSearchParameters(parameters, request)
   prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
   result = ProductSearchSession.getProductSearchResult(request,
delegator,
prodCatalogId)

Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
ecommerce/groovyScripts/catalog/LayeredNavigation.
groovy?rev=1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy (original)
+++ 

Re: 答复: New Impersonate Feature : OFBIZ-10515

[Pierre Smits]

Consider this:
- having it enabled by default (as suggested by many)
- enabling a user with higher privileges (suggested to be the OFBiz Admin)
to impersonate someone with lower privileges
- this user with higher privileges can now create/alter/etc... transactions
in accounting, ordermgr, warehousing, ecommence, etc. through OFBiz as the
impersonated user
- this user can prevent - through OFBiz - that others can see
UserLoginHistory.
- impersonation is in many countries - by law - a criminal offence
- this goes directly against GDPR

Caution is the Mother of the Porcelain Cabinet (as a saying in the
Netherlands goes). Especially when introducing features that have an impact
on security aspects.


Best regards,

Pierre Smits

Apache Trafodion , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

On Mon, Aug 20, 2018 at 12:04 PM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

> I don't have a strong opinion on this, and I am open. My personal
> preference is pehaps to just 'login as' instead of impersonate with normal
> user login history. The reason for my preference is having the least amount
> of code written and least security worries. I find the impersonate feature
> also lovely and quite useful. So both directions are okay for me.
>
> On Mon, Aug 20, 2018, 12:07 PM Gil Portenseigne <
> gil.portensei...@nereide.fr>
> wrote:
>
> > Hello Taher,
> >
> > Thanks for your ideas, i think that had helped making it pop into
> > Nicolas answer to Pierre (that i just annoted).
> >
> > I hope the idea, that seem a mix of yours could be good enough, a
> property
> > that :
> > * by default allow any impersonation to be done in non-preproduction env,
> >  without logging out the user. (less security requirement)
> > * else, impersonation will logout the user impersonated, and restrict
> >  impersonation to one only for this user, during impersonation time.
> >
> > The audit could be done in UserLoginHistory entity, storing
> > impersonation period.
> >
> > Regards
> >
> > Gil
> >
> > Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :
> > > One idea that comes to my mind which might be useful is that we add a
> > > flag in general.properties that by default enables this feature, and
> > > we can then specify in the documentation that to secure OFBiz we need
> > > to disable this feature so that it can be used in development but
> > > disabled in production for people who prefer to be on the safe side. I
> > > also like the suggestions from Pierre on perhaps having some kind of
> > > audit trail, just like we have a log of party visits, we can have a
> > > log of impersonation visits for example.
> > >
> > > Another idea, is perhaps to avoid completely persisting the session
> > > into the system. In other words, once I impersonate some user, it's
> > > done, I AM that user and I cannot go back. I have to log out and log
> > > back in to access the system again as an admin. That might be a bit
> > > more secure because we don't touch the session data.
> > >
> > > All food for thought, and I appreciate getting more feedback from the
> > community.
> > > On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits 
> > wrote:
> > > >
> > > > Impressive...
> > > >
> > > > This seems to be an in-OFBiz equivalent of an OS take-over tool like
> > > > Microsoft's Remote Desktop. The business case (and use cases) are
> > explained
> > > > insufficiently in this thread or in the ticket ([1]) why
> incorporating
> > this
> > > > in the repo should be favourable over having the adopting business
> > > > implement implement the OS take-over tool. What I feel missing here
> > (and in
> > > > the ticket) is the reference to the previous thread, which might
> > explain
> > > > the business case. I suggest to have a link to this thread also in
> the
> > > > ticket
> > > >
> > > > Based on a cursory review of the patch, it is lacking serious aspects
> > that
> > > > will boost the confidence of any business adopter that this feature
> > will
> > > > not jeopardise their business operations. As it is now, I find the
> > patch to
> > > > basic to be committed to the repo and be included in any new release.
> > > >
> > > > As I see it it allows anybody with the IMPERSONATE_ADMIN permission
> > take
> > > > over any other ID and perform actions under that ID at anytime. I did
> > not
> > > > see any functionality (I am spitballing here) that:
> > > >
> > > >1. would exclude any particular ID from being taken over (as a
> > default
> > > >configuration)
> > > >2. would allow a user to disable the feature for their own account
> > > >(overriding the default permission of impersonation)
> > > >3. would allow a user to explicitly allow its ID to be taken over
> by

Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

[Deepak Dixit]

Thanks Jacques,

I added this in my TODO list, I agree with Michael's comment.
I'll check and create a ticket if needed.

Thanks & Regards
--
Deepak Dixit


On Mon, Aug 20, 2018 at 12:36 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Deepak,
>
> I used this way because it starts in Groovy with
> ProductSearchSession.getProductSearchResult(request, delegator,
> prodCatalogId)
> the session is not in the request, and there is no alternative signature
> for ProductSearchSession::getProductSearchResult
> As I did not want to get too deep in that I preferred this simple way at
> the root in Groovy
>
> Please amend it if you see a better way to do it.
>
> Thanks
>
> Jacques
>
>
>
> Le 20/08/2018 à 06:33, Deepak Dixit a écrit :
>
>> Hi Jacques,
>>
>> I think instead of setting dispatcher in groovy files I think we can fix
>> the work done under OFBIZ-9164
>>
>> Instead of getting dispatcher from a session we can get this from the
>> request or can use the different method signature of
>> searchGetConstraintStrings method.
>> {code}
>>
>> LocalDispatcher dispatcher = (LocalDispatcher)
>> request.getAttribute("dispatcher");
>>
>> {code}
>>
>>
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>>
>>
>> On Sun, Aug 19, 2018 at 9:00 PM,  wrote:
>>
>> Author: jleroux
>>> Date: Sun Aug 19 15:30:42 2018
>>> New Revision: 1838381
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1838381=rev
>>> Log:
>>> Fixed: Search in Ecommerce no longer works
>>> (OFBIZ-10531)
>>>
>>> I guess that when I worked on OFBIZ-9164 I broke that.
>>>
>>> I found 3 occurences where the dispatcher was not in the session because
>>> the
>>> session comes from the request and the request has not it in.
>>>
>>> Modified:
>>>  ofbiz/ofbiz-framework/trunk/applications/order/
>>> groovyScripts/entry/catalog/KeywordSearch.groovy
>>>  ofbiz/ofbiz-framework/trunk/applications/product/
>>> groovyScripts/catalog/find/KeywordSearch.groovy
>>>  ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
>>> catalog/LayeredNavigation.groovy
>>>
>>> Modified: ofbiz/ofbiz-framework/trunk/applications/order/
>>> groovyScripts/entry/catalog/KeywordSearch.groovy
>>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
>>> applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev=
>>> 1838381=1838380=1838381=diff
>>> 
>>> ==
>>> --- ofbiz/ofbiz-framework/trunk/applications/order/
>>> groovyScripts/entry/catalog/KeywordSearch.groovy (original)
>>> +++ ofbiz/ofbiz-framework/trunk/applications/order/
>>> groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19 15:30:42
>>> 2018
>>> @@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
>>>   module = "KeywordSearch.groovy"
>>>
>>>   // note: this can be run multiple times in the same request without
>>> causing problems, will check to see on its own if it has run again
>>> +request.getSession().setAttribute("dispatcher",dispatcher)
>>>   ProductSearchSession.processSearchParameters(parameters, request)
>>>   prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
>>>   result = ProductSearchSession.getProductSearchResult(request,
>>> delegator,
>>> prodCatalogId)
>>>
>>> Modified: ofbiz/ofbiz-framework/trunk/applications/product/
>>> groovyScripts/catalog/find/KeywordSearch.groovy
>>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
>>> applications/product/groovyScripts/catalog/find/KeywordSearc
>>> h.groovy?rev=
>>> 1838381=1838380=1838381=diff
>>> 
>>> ==
>>> --- ofbiz/ofbiz-framework/trunk/applications/product/
>>> groovyScripts/catalog/find/KeywordSearch.groovy (original)
>>> +++ ofbiz/ofbiz-framework/trunk/applications/product/
>>> groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19 15:30:42 2018
>>> @@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
>>>   module = "KeywordSearch.groovy"
>>>
>>>   // note: this can be run multiple times in the same request without
>>> causing problems, will check to see on its own if it has run again
>>> +request.getSession().setAttribute("dispatcher",dispatcher)
>>>   ProductSearchSession.processSearchParameters(parameters, request)
>>>   prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
>>>   result = ProductSearchSession.getProductSearchResult(request,
>>> delegator,
>>> prodCatalogId)
>>>
>>> Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
>>> catalog/LayeredNavigation.groovy
>>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
>>> ecommerce/groovyScripts/catalog/LayeredNavigation.
>>> groovy?rev=1838381=1838380=1838381=diff
>>> 
>>> ==
>>> --- ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
>>> catalog/LayeredNavigation.groovy (original)
>>> +++ ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
>>> catalog/LayeredNavigation.groovy Sun 

Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

[Jacques Le Roux]

Please open a Jira if you think that

   we normally expect the dispatcher to be always in the session

I don't know if a such rule exists. And this is not related with the work I did 
in OFBIZ-9164

Jacques

Le 20/08/2018 à 12:06, Taher Alkhateeb a écrit :

Agreed, surface level fixes are not good, you might have a logic flaw
underneath. We should always go for root cauae analysis.

On Mon, Aug 20, 2018, 1:00 PM Michael Brohl 
wrote:


Jacques,

inline...

Am 20.08.18 um 11:27 schrieb Jacques Le Roux:

Hi Michael,

Yes but at this point the session misses the dispatcher, that's why I use

request.getSession().setAttribute("dispatcher",dispatcher)

to put it in. As shown at



https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context

  the dispatcher is always available in screen context. Not sure why
the session misses the dispatcher there, I did not want to digg in...

I think you should do that. If we normally expect the dispatcher to be
always in the session and it is not in this case, there might be an
error somewhere.
Implementing a workaround just covers this error but does not fix it.

Regards,
Michael


Jacques


Le 20/08/2018 à 09:12, Michael Brohl a écrit :

Hi Jacques,

maybe I am missing something but you should be able to get the
session with request.getSession(), no?

Regards,

Michael


Am 20.08.18 um 09:06 schrieb Jacques Le Roux:

Hi Deepak,

I used this way because it starts in Groovy with
 ProductSearchSession.getProductSearchResult(request, delegator,
prodCatalogId)
the session is not in the request, and there is no alternative
signature for ProductSearchSession::getProductSearchResult
As I did not want to get too deep in that I preferred this simple
way at the root in Groovy

Please amend it if you see a better way to do it.

Thanks

Jacques


Le 20/08/2018 à 06:33, Deepak Dixit a écrit :

Hi Jacques,

I think instead of setting dispatcher in groovy files I think we
can fix
the work done under OFBIZ-9164

Instead of getting dispatcher from a session we can get this from the
request or can use the different method signature of
searchGetConstraintStrings method.
{code}

LocalDispatcher dispatcher = (LocalDispatcher)
request.getAttribute("dispatcher");

{code}



Thanks & Regards
--
Deepak Dixit


On Sun, Aug 19, 2018 at 9:00 PM,  wrote:


Author: jleroux
Date: Sun Aug 19 15:30:42 2018
New Revision: 1838381

URL: http://svn.apache.org/viewvc?rev=1838381=rev
Log:
Fixed: Search in Ecommerce no longer works
(OFBIZ-10531)

I guess that when I worked on OFBIZ-9164 I broke that.

I found 3 occurences where the dispatcher was not in the session
because
the
session comes from the request and the request has not it in.

Modified:
  ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
  ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
  ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy

Modified: ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/


applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev=

1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19
15:30:42 2018
@@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
   module = "KeywordSearch.groovy"

   // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
   ProductSearchSession.processSearchParameters(parameters, request)
   prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
   result = ProductSearchSession.getProductSearchResult(request,
delegator,
prodCatalogId)

Modified: ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/


applications/product/groovyScripts/catalog/find/KeywordSearch.groovy?rev=

1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19
15:30:42 2018
@@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
   module = "KeywordSearch.groovy"

   // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again

Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

[Taher Alkhateeb]

Agreed, surface level fixes are not good, you might have a logic flaw
underneath. We should always go for root cauae analysis.

On Mon, Aug 20, 2018, 1:00 PM Michael Brohl 
wrote:

> Jacques,
>
> inline...
>
> Am 20.08.18 um 11:27 schrieb Jacques Le Roux:
> > Hi Michael,
> >
> > Yes but at this point the session misses the dispatcher, that's why I use
> >
> >request.getSession().setAttribute("dispatcher",dispatcher)
> >
> > to put it in. As shown at
> >
> >
> https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context
> >
> >  the dispatcher is always available in screen context. Not sure why
> > the session misses the dispatcher there, I did not want to digg in...
>
> I think you should do that. If we normally expect the dispatcher to be
> always in the session and it is not in this case, there might be an
> error somewhere.
> Implementing a workaround just covers this error but does not fix it.
>
> Regards,
> Michael
>
> >
> > Jacques
> >
> >
> > Le 20/08/2018 à 09:12, Michael Brohl a écrit :
> >> Hi Jacques,
> >>
> >> maybe I am missing something but you should be able to get the
> >> session with request.getSession(), no?
> >>
> >> Regards,
> >>
> >> Michael
> >>
> >>
> >> Am 20.08.18 um 09:06 schrieb Jacques Le Roux:
> >>> Hi Deepak,
> >>>
> >>> I used this way because it starts in Groovy with
> >>> ProductSearchSession.getProductSearchResult(request, delegator,
> >>> prodCatalogId)
> >>> the session is not in the request, and there is no alternative
> >>> signature for ProductSearchSession::getProductSearchResult
> >>> As I did not want to get too deep in that I preferred this simple
> >>> way at the root in Groovy
> >>>
> >>> Please amend it if you see a better way to do it.
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>>
> >>>
> >>> Le 20/08/2018 à 06:33, Deepak Dixit a écrit :
>  Hi Jacques,
> 
>  I think instead of setting dispatcher in groovy files I think we
>  can fix
>  the work done under OFBIZ-9164
> 
>  Instead of getting dispatcher from a session we can get this from the
>  request or can use the different method signature of
>  searchGetConstraintStrings method.
>  {code}
> 
>  LocalDispatcher dispatcher = (LocalDispatcher)
>  request.getAttribute("dispatcher");
> 
>  {code}
> 
> 
> 
>  Thanks & Regards
>  --
>  Deepak Dixit
> 
> 
>  On Sun, Aug 19, 2018 at 9:00 PM,  wrote:
> 
> > Author: jleroux
> > Date: Sun Aug 19 15:30:42 2018
> > New Revision: 1838381
> >
> > URL: http://svn.apache.org/viewvc?rev=1838381=rev
> > Log:
> > Fixed: Search in Ecommerce no longer works
> > (OFBIZ-10531)
> >
> > I guess that when I worked on OFBIZ-9164 I broke that.
> >
> > I found 3 occurences where the dispatcher was not in the session
> > because
> > the
> > session comes from the request and the request has not it in.
> >
> > Modified:
> >  ofbiz/ofbiz-framework/trunk/applications/order/
> > groovyScripts/entry/catalog/KeywordSearch.groovy
> >  ofbiz/ofbiz-framework/trunk/applications/product/
> > groovyScripts/catalog/find/KeywordSearch.groovy
> >  ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
> > catalog/LayeredNavigation.groovy
> >
> > Modified: ofbiz/ofbiz-framework/trunk/applications/order/
> > groovyScripts/entry/catalog/KeywordSearch.groovy
> > URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> >
> applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev=
> >
> > 1838381=1838380=1838381=diff
> > 
> > ==
> > --- ofbiz/ofbiz-framework/trunk/applications/order/
> > groovyScripts/entry/catalog/KeywordSearch.groovy (original)
> > +++ ofbiz/ofbiz-framework/trunk/applications/order/
> > groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19
> > 15:30:42 2018
> > @@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
> >   module = "KeywordSearch.groovy"
> >
> >   // note: this can be run multiple times in the same request without
> > causing problems, will check to see on its own if it has run again
> > +request.getSession().setAttribute("dispatcher",dispatcher)
> >   ProductSearchSession.processSearchParameters(parameters, request)
> >   prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
> >   result = ProductSearchSession.getProductSearchResult(request,
> > delegator,
> > prodCatalogId)
> >
> > Modified: ofbiz/ofbiz-framework/trunk/applications/product/
> > groovyScripts/catalog/find/KeywordSearch.groovy
> > URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> >
> applications/product/groovyScripts/catalog/find/KeywordSearch.groovy?rev=
> >
> > 1838381=1838380=1838381=diff
> > 

Re: 答复: New Impersonate Feature : OFBIZ-10515

[Taher Alkhateeb]

I don't have a strong opinion on this, and I am open. My personal
preference is pehaps to just 'login as' instead of impersonate with normal
user login history. The reason for my preference is having the least amount
of code written and least security worries. I find the impersonate feature
also lovely and quite useful. So both directions are okay for me.

On Mon, Aug 20, 2018, 12:07 PM Gil Portenseigne 
wrote:

> Hello Taher,
>
> Thanks for your ideas, i think that had helped making it pop into
> Nicolas answer to Pierre (that i just annoted).
>
> I hope the idea, that seem a mix of yours could be good enough, a property
> that :
> * by default allow any impersonation to be done in non-preproduction env,
>  without logging out the user. (less security requirement)
> * else, impersonation will logout the user impersonated, and restrict
>  impersonation to one only for this user, during impersonation time.
>
> The audit could be done in UserLoginHistory entity, storing
> impersonation period.
>
> Regards
>
> Gil
>
> Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :
> > One idea that comes to my mind which might be useful is that we add a
> > flag in general.properties that by default enables this feature, and
> > we can then specify in the documentation that to secure OFBiz we need
> > to disable this feature so that it can be used in development but
> > disabled in production for people who prefer to be on the safe side. I
> > also like the suggestions from Pierre on perhaps having some kind of
> > audit trail, just like we have a log of party visits, we can have a
> > log of impersonation visits for example.
> >
> > Another idea, is perhaps to avoid completely persisting the session
> > into the system. In other words, once I impersonate some user, it's
> > done, I AM that user and I cannot go back. I have to log out and log
> > back in to access the system again as an admin. That might be a bit
> > more secure because we don't touch the session data.
> >
> > All food for thought, and I appreciate getting more feedback from the
> community.
> > On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits 
> wrote:
> > >
> > > Impressive...
> > >
> > > This seems to be an in-OFBiz equivalent of an OS take-over tool like
> > > Microsoft's Remote Desktop. The business case (and use cases) are
> explained
> > > insufficiently in this thread or in the ticket ([1]) why incorporating
> this
> > > in the repo should be favourable over having the adopting business
> > > implement implement the OS take-over tool. What I feel missing here
> (and in
> > > the ticket) is the reference to the previous thread, which might
> explain
> > > the business case. I suggest to have a link to this thread also in the
> > > ticket
> > >
> > > Based on a cursory review of the patch, it is lacking serious aspects
> that
> > > will boost the confidence of any business adopter that this feature
> will
> > > not jeopardise their business operations. As it is now, I find the
> patch to
> > > basic to be committed to the repo and be included in any new release.
> > >
> > > As I see it it allows anybody with the IMPERSONATE_ADMIN permission
> take
> > > over any other ID and perform actions under that ID at anytime. I did
> not
> > > see any functionality (I am spitballing here) that:
> > >
> > >1. would exclude any particular ID from being taken over (as a
> default
> > >configuration)
> > >2. would allow a user to disable the feature for their own account
> > >(overriding the default permission of impersonation)
> > >3. would allow a user to explicitly allow its ID to be taken over by
> > >someone else, AND limit it for a specific amount of time
> (overriding aspect
> > >#2 above).
> > >4. would prohibit the impersonator to take over an ID when the user
> of
> > >the ID is NOT logged in (which should be an additional default
> aspect).
> > >
> > > This feature seems 'impersonator' driven as the permission would not
> be on
> > > a case-by-case scenario, but rather on a semi-permanent permission
> > > assignment and by a user who has the - technical -  permission to set
> such
> > > a permission.
> > >
> > > What I furthermore feel lacking or underdeveloped is the audit and
> logging
> > > trail regarding this feature. Nowhere can be seen what actions (for the
> > > authentic ID) have been undertaken by the impersonator while the
> > > impersonation was in progress. Neither in logfiles, nor in screens in
> the
> > > Partymgr component (e.g. for the user to see).
> > >
> > > I advise the community to be very careful to commit this, without
> > > consideration of the above, into the repo.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/OFBIZ-10515
> > >
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > Apache Trafodion , Vice President
> > > Apache Directory , PMC Member
> > > Apache Incubator 

Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

[Michael Brohl]

Jacques,

inline...

Am 20.08.18 um 11:27 schrieb Jacques Le Roux:

Hi Michael,

Yes but at this point the session misses the dispatcher, that's why I use

   request.getSession().setAttribute("dispatcher",dispatcher)

to put it in. As shown at

https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context

 the dispatcher is always available in screen context. Not sure why 
the session misses the dispatcher there, I did not want to digg in...


I think you should do that. If we normally expect the dispatcher to be 
always in the session and it is not in this case, there might be an 
error somewhere.

Implementing a workaround just covers this error but does not fix it.

Regards,
Michael



Jacques


Le 20/08/2018 à 09:12, Michael Brohl a écrit :

Hi Jacques,

maybe I am missing something but you should be able to get the 
session with request.getSession(), no?


Regards,

Michael


Am 20.08.18 um 09:06 schrieb Jacques Le Roux:

Hi Deepak,

I used this way because it starts in Groovy with
    ProductSearchSession.getProductSearchResult(request, delegator, 
prodCatalogId)
the session is not in the request, and there is no alternative 
signature for ProductSearchSession::getProductSearchResult
As I did not want to get too deep in that I preferred this simple 
way at the root in Groovy


Please amend it if you see a better way to do it.

Thanks

Jacques


Le 20/08/2018 à 06:33, Deepak Dixit a écrit :

Hi Jacques,

I think instead of setting dispatcher in groovy files I think we 
can fix

the work done under OFBIZ-9164

Instead of getting dispatcher from a session we can get this from the
request or can use the different method signature of
searchGetConstraintStrings method.
{code}

LocalDispatcher dispatcher = (LocalDispatcher)
request.getAttribute("dispatcher");

{code}



Thanks & Regards
--
Deepak Dixit


On Sun, Aug 19, 2018 at 9:00 PM,  wrote:


Author: jleroux
Date: Sun Aug 19 15:30:42 2018
New Revision: 1838381

URL: http://svn.apache.org/viewvc?rev=1838381=rev
Log:
Fixed: Search in Ecommerce no longer works
(OFBIZ-10531)

I guess that when I worked on OFBIZ-9164 I broke that.

I found 3 occurences where the dispatcher was not in the session 
because

the
session comes from the request and the request has not it in.

Modified:
 ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
 ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
 ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy

Modified: ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev= 


1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19 
15:30:42 2018

@@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)

Modified: ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/product/groovyScripts/catalog/find/KeywordSearch.groovy?rev= 


1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19 
15:30:42 2018

@@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)

Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/

Re: OFBiz Contributors Best Practices was [Re: svn commit: r1838320 ...]

[Gil Portenseigne]

Hello Jacques, All,

I do not agree about creating a new jira, since the improvement has
design flaw (i will add a comment into the Jira introducing it) in my
opinion leading to breaking thread safety in ModelForm.java.
And Taking into consideration Michael preference for reverting,
the best way to go in my opinion, is to revert and rework the feature.
I'd be glad to help out with that :).

All details here : https://s.apache.org/C9VF (within the quotation for
thread safe matter)

For clarifying the policy and writing it down +1

Gil

Le dimanche 19 août 2018 à 14:49:31 (+0200), Jacques Le Roux a écrit :
> Hi All,
> 
> Yesterday Suraj asked me on HipChat what to do about OFBIZ-7598
>  where Gil spotted an
> issue. Here is my answer:
> 
>Hi @SurajKhurana , we have not a clearly established policy for that case. 
> Should we reuse the current Jira or should we rather create a new Jira
>to fix the issue? It seems to me though that we should rather create a new 
> Jira because, after the commit, it's a fix not an improvement . This
>Jira should have a "Broken By" link referring to the original Jira. I see 
> that Gil reopened the original Jira so better to close it also. It makes
>things more clear.
>While at it, I'll create a thread about this point in dev ML to get a 
> consensus before writing this policy in
>
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
>
> 
> 
> I shamelessly hijack this thread because it seems related to me and Michael
> have good points below (he also was the 1st to clearly suggest the solution
> I advised to Suraj in HipChat).
> And I believe that, to avoid rehearsing things, we should rewrite, as 
> concisely as possible, what Michael suggests below (not an easy thing)
> 
> Thoughts?
> 
> And I agree with Nicolas, helping others is always good. At some point you 
> will maybe even find helping yourself in the future.
> Damn sometimes I can't even understand my own code... never happened to
> you?... This may help: https://twitter.com/romiem/status/1030438339390910464
> https://twitter.com/romiem/status/1030438
> 339390910464 (I sure have the last book on end)
> 
> Enjoy the rest of your weekend :)
> 
> Jacques
> 
> Le 19/08/2018 à 11:28, Michael Brohl a écrit :
> > I have not the time to dig into the specific details right now so will just 
> > give my thoughts on the process in general because of the citations:
> > 
> > 1. we have to distinguish between (a) completely new functionality or
> > major refactorings and (b) the enhancement of functionality which is
> > already in the code base
> > 
> > 2. for (a), we should first have consenus that we want the proposed
> > solution and we should look for a complete, well designed and carefully
> > tested solution before the first commit will be done. This is to prevent
> > the introduction of new problematic code.
> > 
> > 3. for (b), I think every improvement of existing code/functionality
> > helps and should be committed if there are no flaws in the design or
> > technical solution and it does not break existing funtionality. of
> > course, it should be complete within the *scope* of the improvement.
> > 
> > 4. if the solution for (b) does not cover other wishes or things which
> > could be enhanced also, this would be no reason to not commit the
> > improvement. If people have further requirements, they can provide
> > concepts and solutions/patches anytime to make things better.
> > 
> > In this case, for me it is important if Suraj's commit
> > 
> > a. breaks anything?
> > 
> > b. is vetoed by other committers in view of code quality or design flaws?
> > 
> > If none of these questions get a "yes", then I see no reason to revert.
> > 
> > If you have additional requirements, you are encouraged to provide 
> > solutions or concepts for them.
> > 
> > Thanks,
> > 
> > Michael Brohl
> > ecomify GmbH
> > www.ecomify.de
> > 
> > 
> > Am 19.08.18 um 09:25 schrieb Pierre Smits:
> > > Please read the comment in the related ticket [1]
> > > 
> > > https://issues.apache.org/jira/browse/OFBIZ-7482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584721#comment-16584721
> > > 
> > > 
> > > 
> > > Best regards,
> > > 
> > > Pierre Smits
> > > 
> > > Apache Trafodion , Vice President
> > > Apache Directory , PMC Member
> > > Apache Incubator , committer
> > > *Apache OFBiz , contributor (without privileges)
> > > since 2008*
> > > Apache Steve , committer
> > > 
> > > On Sat, Aug 18, 2018 at 9:01 PM, Michael Brohl 
> > > wrote:
> > > 
> > > > How do these citations relate to Suraj‘s work?
> > > > 
> > > > Please provide arguments in your own words if you think someone‘s work 
> > > 

Re: 答复: New Impersonate Feature : OFBIZ-10515

[Jacques Le Roux]

Le 20/08/2018 à 10:50, Gil Portenseigne a écrit :

I hope you find this feature interesting ? Reading you, i find out that
no documentation is provided yet with this feature, we need to elaborate
one, that will help up introducing it to business adopter and ‘boost
their confidence’ !

Regards,

Gil

A big +1 :)

Jacques

Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

[Jacques Le Roux]

Hi Michael,

Yes but at this point the session misses the dispatcher, that's why I use

   request.getSession().setAttribute("dispatcher",dispatcher)

to put it in. As shown at

   
https://cwiki.apache.org/confluence/display/OFBIZ/Variables+always+available+in+screen+context

 the dispatcher is always available in screen context. Not sure why the session 
misses the dispatcher there, I did not want to digg in...

Jacques


Le 20/08/2018 à 09:12, Michael Brohl a écrit :

Hi Jacques,

maybe I am missing something but you should be able to get the session with 
request.getSession(), no?

Regards,

Michael


Am 20.08.18 um 09:06 schrieb Jacques Le Roux:

Hi Deepak,

I used this way because it starts in Groovy with
    ProductSearchSession.getProductSearchResult(request, delegator, 
prodCatalogId)
the session is not in the request, and there is no alternative signature for 
ProductSearchSession::getProductSearchResult
As I did not want to get too deep in that I preferred this simple way at the 
root in Groovy

Please amend it if you see a better way to do it.

Thanks

Jacques


Le 20/08/2018 à 06:33, Deepak Dixit a écrit :

Hi Jacques,

I think instead of setting dispatcher in groovy files I think we can fix
the work done under OFBIZ-9164

Instead of getting dispatcher from a session we can get this from the
request or can use the different method signature of
searchGetConstraintStrings method.
{code}

LocalDispatcher dispatcher = (LocalDispatcher)
request.getAttribute("dispatcher");

{code}



Thanks & Regards
--
Deepak Dixit


On Sun, Aug 19, 2018 at 9:00 PM,  wrote:


Author: jleroux
Date: Sun Aug 19 15:30:42 2018
New Revision: 1838381

URL: http://svn.apache.org/viewvc?rev=1838381=rev
Log:
Fixed: Search in Ecommerce no longer works
(OFBIZ-10531)

I guess that when I worked on OFBIZ-9164 I broke that.

I found 3 occurences where the dispatcher was not in the session because
the
session comes from the request and the request has not it in.

Modified:
 ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
 ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
 ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy

Modified: ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev=
1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19 15:30:42 2018
@@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, delegator,
prodCatalogId)

Modified: ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/product/groovyScripts/catalog/find/KeywordSearch.groovy?rev=
1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19 15:30:42 2018
@@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, delegator,
prodCatalogId)

Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
ecommerce/groovyScripts/catalog/LayeredNavigation.
groovy?rev=1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy (original)
+++ ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy 

Re: 答复: New Impersonate Feature : OFBIZ-10515

[Gil Portenseigne]

Hello Taher,

Thanks for your ideas, i think that had helped making it pop into
Nicolas answer to Pierre (that i just annoted).

I hope the idea, that seem a mix of yours could be good enough, a property that 
:
* by default allow any impersonation to be done in non-preproduction env,
 without logging out the user. (less security requirement)
* else, impersonation will logout the user impersonated, and restrict
 impersonation to one only for this user, during impersonation time.

The audit could be done in UserLoginHistory entity, storing
impersonation period.

Regards

Gil

Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :
> One idea that comes to my mind which might be useful is that we add a
> flag in general.properties that by default enables this feature, and
> we can then specify in the documentation that to secure OFBiz we need
> to disable this feature so that it can be used in development but
> disabled in production for people who prefer to be on the safe side. I
> also like the suggestions from Pierre on perhaps having some kind of
> audit trail, just like we have a log of party visits, we can have a
> log of impersonation visits for example.
> 
> Another idea, is perhaps to avoid completely persisting the session
> into the system. In other words, once I impersonate some user, it's
> done, I AM that user and I cannot go back. I have to log out and log
> back in to access the system again as an admin. That might be a bit
> more secure because we don't touch the session data.
> 
> All food for thought, and I appreciate getting more feedback from the 
> community.
> On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits  wrote:
> >
> > Impressive...
> >
> > This seems to be an in-OFBiz equivalent of an OS take-over tool like
> > Microsoft's Remote Desktop. The business case (and use cases) are explained
> > insufficiently in this thread or in the ticket ([1]) why incorporating this
> > in the repo should be favourable over having the adopting business
> > implement implement the OS take-over tool. What I feel missing here (and in
> > the ticket) is the reference to the previous thread, which might explain
> > the business case. I suggest to have a link to this thread also in the
> > ticket
> >
> > Based on a cursory review of the patch, it is lacking serious aspects that
> > will boost the confidence of any business adopter that this feature will
> > not jeopardise their business operations. As it is now, I find the patch to
> > basic to be committed to the repo and be included in any new release.
> >
> > As I see it it allows anybody with the IMPERSONATE_ADMIN permission take
> > over any other ID and perform actions under that ID at anytime. I did not
> > see any functionality (I am spitballing here) that:
> >
> >1. would exclude any particular ID from being taken over (as a default
> >configuration)
> >2. would allow a user to disable the feature for their own account
> >(overriding the default permission of impersonation)
> >3. would allow a user to explicitly allow its ID to be taken over by
> >someone else, AND limit it for a specific amount of time (overriding 
> > aspect
> >#2 above).
> >4. would prohibit the impersonator to take over an ID when the user of
> >the ID is NOT logged in (which should be an additional default aspect).
> >
> > This feature seems 'impersonator' driven as the permission would not be on
> > a case-by-case scenario, but rather on a semi-permanent permission
> > assignment and by a user who has the - technical -  permission to set such
> > a permission.
> >
> > What I furthermore feel lacking or underdeveloped is the audit and logging
> > trail regarding this feature. Nowhere can be seen what actions (for the
> > authentic ID) have been undertaken by the impersonator while the
> > impersonation was in progress. Neither in logfiles, nor in screens in the
> > Partymgr component (e.g. for the user to see).
> >
> > I advise the community to be very careful to commit this, without
> > consideration of the above, into the repo.
> >
> >
> > [1] https://issues.apache.org/jira/browse/OFBIZ-10515
> >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > Apache Trafodion , Vice President
> > Apache Directory , PMC Member
> > Apache Incubator , committer
> > Apache OFBiz , contributor since 2008
> > Apache Steve , committer
> >
> > On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei  wrote:
> >
> > > +1
> > > 
> > > 发件人: Rajesh Mallah 
> > > 发送时间: 2018年8月11日 11:10
> > > 收件人: dev@ofbiz.apache.org
> > > 主题: Re: New Impersonate Feature : OFBIZ-10515
> > >
> > > This feature has valid use cases.
> > > +1
> > >
> > > On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
> > > gil.portensei...@nereide.fr> wrote:
> > >
> > > > Hello !
> > > >
> > > > I would like to introduce to you 

Re: Inventory Allocation Planning

[deepak nigam]

Here is the JIRA ticket for the same:
https://issues.apache.org/jira/browse/OFBIZ-10518

I will provide the updated patch soon.

On Sat, Aug 18, 2018 at 5:51 PM Pierre Smits  wrote:

> Without a JIRA ticket providing the necessary business and use cases, et
> al, it is difficult to address this topic.
>
> One thing to keep in mind though, is that the (ultimate) gatekeeper
> regarding fulfilment of orders is the warehouse manager.
>
>
> Best regards,
>
> Pierre Smits
>
> Apache Trafodion , Vice President
> Apache Directory , PMC Member
> Apache Incubator , committer
> *Apache OFBiz , contributor (without privileges)
> since 2008*
> Apache Steve , committer
>
> On Sat, Aug 18, 2018 at 9:01 AM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi Deepak,
> >
> > Will you later provide a patch in a Jira? It's easier for review.
> >
> > Jacques
> >
> >
> >
> > Le 17/08/2018 à 07:42, deepak nigam a écrit :
> >
> >> I have started some implementation regarding this. Here is the link for
> >> the
> >> reference,
> >>
> >> https://github.com/Deepak27021990/ofbiz-framework/tree/
> >> sales-allocation-plan
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Nigam
> >>
> >> On Thu, Aug 16, 2018 at 5:39 PM deepak nigam <
> deepak.nigam1...@gmail.com>
> >> wrote:
> >>
> >> Moving thread to the dev mailing list.
> >>>
> >>> On Thu, Aug 16, 2018 at 3:33 PM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>> Hi Deepak,
> 
>  Interesting proposition, this should be discussed in dev ML
> 
>  Thanks
> 
>  Jacques
> 
> 
>  Le 16/08/2018 à 11:28, deepak nigam a écrit :
> 
> > While creating orders from the backend, we have the option to set
> > parameters like 'Ship After Date' and 'Ship Before Date' to manage
> the
> > fulfilment cycle more efficiently. Inventory gets reserved for the
> >
>  product
> 
> > based on a FIFO basis. Sometimes the fulfilment time for the order is
> >
>  high
> 
> > and inventory unnecessarily gets locked for some time period.
> >
> > We can introduce a new parameter (at order item level) 'Reserve After
> >
>  Date'
> 
> > which will indicate the date only after which reservation can happen.
> > In
> > this way, we can manage the stock availability more efficiently.
> >
> > On Mon, Aug 13, 2018 at 10:35 AM deepak nigam <
> >
>  deepak.nigam1...@gmail.com>
> 
> > wrote:
> >
> > Thanks, James.
> >>
> >> Here is the JIRA ticket
> >>  for the same.
> >>
> > Soon I
> 
> > will share detailed design notes here and in the ticker also.
> >>
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Nigam
> >>
> >> On Mon, Aug 13, 2018 at 2:17 AM  wrote:
> >>
> >> Deepak - I did not see it in OFbiz but I did in Opentaps.  I can
> send
> >>> you a video of the functionality
> >>>
> >>>  Original Message 
> >>> Subject: Re: Inventory Allocation Planning
> >>> From: deepak nigam 
> >>> Date: Thu, August 09, 2018 2:24 am
> >>> To: u...@ofbiz.apache.org, ja...@productive1.com
> >>>
> >>> Hi James,
> >>>
> >>> Did you get a chance to confirm it in OFBiz?
> >>>
> >>>
> >>> @All,
> >>> As far as I came to know, the feature to allocate the inventory
> (not
> >>> actual reservation at this point) is not available OOTB. We can
> think
> >>> about the idea of its implementation.
> >>>
> >>>
> >>>
> >>>
> >>> Thanks & Regards
> >>> --
> >>> Deepak Nigam
> >>>
> >>>
> >>>
> >>>
> >>> On Sun, Aug 5, 2018 at 10:14 PM  wrote:
> >>>
> >>> This will only allocate the current inventory.  I see it in
> >>>opentaps...let me confirm in Ofbiz.
> >>>
> >>> Original Message 
> >>>Subject: Re: Inventory Allocation Planning
> >>>From: deepak nigam 
> >>>Date: Fri, August 03, 2018 12:40 am
> >>>To: u...@ofbiz.apache.org
> >>>
> >>>Thanks, James.
> >>>
> >>>Will this method honour the upcoming supply also? I am more
> >>>
> >> interested
> 
> >in a
> >>>supply allocation plan by using which I can allocate the
> available
> >>>
> >> and
> 
> >upcoming supply amongst the open orders.
> >>>
> >>>
> >>>Thanks & Regards
> >>>--
> >>>Deepak Nigam
> >>>
> >>>On Wed, Aug 1, 2018 at 12:26 AM Paul Mandeltort <
> >>> p...@marcospec.com
> >>>wrote:
> >>>
> >>>> Where is this screen located? Or are you referring to the
> order
> >>>> priority field in ordermgr?
> >>>>
> >>>  

Re: 答复: New Impersonate Feature : OFBIZ-10515

[Gil Portenseigne]

Hello !

I am back and glad to have so many feedback :)

Since Nicolas already answered, i'll add some precisions and opinions
inline.
Le mardi 14 août 2018 à 18:17:14 (+0200), Nicolas Malin a écrit :
> Hello,
> On 13/08/2018 10:09, Pierre Smits wrote:
> > Impressive...
> > 
[...]
> The feature haven't the same goal than an OS take-over tool, but just on the
> same aspect you can escape problematic like system incompatibility and time
> zone.
> All is embedded in OFBiz with tracking. And in other time, like an OS
> take-over tool you can't use it to trainyour end user. For this part it's
> better to use a WebRTC client.
+1 it's not a feature to have access to the client computer. It is a
feature that OFBiz could offer to impersonate and see through the eyes
of another userLogin.

I did not recover the previous thread, but I remember that was a basic
proposal before the implementation. Nicolas answer did offer you use cases, i
hope that will be enough for you to understand the need of such a feature
:).
[...]
> IMPERSONATE_ADMIN is a permission so only OFBiz administrator can assign it
> to an user (by the permission SECURITY).
+1 : that's a high level permission, so to grant it to a user you need
to a trusted admin :), and should be granted to trusted users ! Keep in
mind that is an administration tool, and should be used in such aspect.

Giving control to all user to the configuration of the possible
impersonation of their login is quite strange to me, i do not grasp this
need, could you elaborate ?

> 
> I understand your fear to have a high level user that surpass their rights
> and use it to damagesome process. We startedwith the idea that all high
> level user and OFBiz administrator are trusted peoples, and if not,maybe we
> need to track all actions in webtools because currently with permission
> ENTITY_MAINT this feature isn't needed.
> Most seriously, I see interesting improvement in your remarks that we
> shouldnever had two actives sessions on impersonate user. Like this when a
> user impersonate an other he will be logged out with an error "You are
> currently impersonated by XXX" and he can't login during the impersonation
> time. All operations realized during this time can be associate to the
> impersonation.
This idea is interesting in production environement to ensure that all
action made during a time frame is done by the user impersonating. But
this should be desactivable for non-production environment.

> > What I furthermore feel lacking or underdeveloped is the audit and logging
> > trail regarding this feature. Nowhere can be seen what actions (for the
> > authentic ID) have been undertaken by the impersonator while the
> > impersonation was in progress. Neither in logfiles, nor in screens in the
> > Partymgr component (e.g. for the user to see).
The above proposal should help the audit of impersonated user in
production environment. Since impersonation period is stored, and login
desactivated during this period, everything done during it belong to the
impersonator !
> > 
> > I advise the community to be very careful to commit this, without
> > consideration of the above, into the repo.

Thanks for your feedback, consideration is here :), let's build a good
secured feature as a community !

I hope you find this feature interesting ? Reading you, i find out that
no documentation is provided yet with this feature, we need to elaborate
one, that will help up introducing it to business adopter and ‘boost
their confidence’ !

Regards,

Gil

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

[Jacques Le Roux]

Hi Jinghai,

I'm not sure why you want to create a CAS plugin. At least it's unrelated with 
OFBIZ-1307

Also are you aware of 
https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#CASLDAP ?

Does this still work? Do we need a new plugin?

Thanks

Jacques


Le 19/08/2018 à 22:00, Shi Jinghai a écrit :

Thanks Jacques!

If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week. 
I have cas 4.2.x version running in production environment, I'll upgrade it to 
cas 5.2.x and then release it.



-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月19日 18:34
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi Jinghai,

Actually I did not pick auth0 (not to be confused with 
https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those 
need a central
Identify server (as is the SAML protocol).

I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and 
https://jwt.io/ to

Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed 
in authentication"

Thanks for your interest.

Jacques


Le 17/08/2018 à 09:02, Shi Jinghai a écrit :

Hi Jacques,

OK, I think the redis topic is jumped to next step.

I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose 
auth0[2] rather than CAS. And is the implement OAuth2 alliance?

[1] https://github.com/apereo/cas
[2] https://auth0.com/

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月16日 2:08
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi Jinghai,

The problem with the token master secret key is to guarantee its secrecy at max.

We already discussed different solutions at https://s.apache.org/7yyR and 
https://s.apache.org/IBDM

How is Redis more secure than Postgres for storing values?

Thanks

Jacques


Le 15/08/2018 à 14:37, Shi Jinghai a écrit :

Dear Jacques,

On how to store the Tokens, as a token is a key, value is the UserLogin entity 
and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in 
db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs 
invested Redis team in last year[3]. It's common view now in China that Redis 
is better than any others including Gemfire of Pivotal, the railway ticket 
system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year 
and then there are much less complains on how difficulties to buy spring 
festival tickets.

Mr. Dai Haipeng contributed a Redis component in Jira[4].

[1] https://redis.io/
[2] https://db-engines.com/en/ranking
[3] 
https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
[4] https://issues.apache.org/jira/browse/OFBIZ-9829

BTW, I'll try to review the patches.

Kind Regards,

Shi Jinghai

-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月15日 15:09
收件人: dev@ofbiz.apache.org
主题: OFBIZ-10307: Navigate from a domain to another with automated signed in 
authentication

Hi,

Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.

I asked for reviews but only Taher answered and he asked to know the goal of 
this new feature.

It was actually developed for a client who needed to get from one OFBiz 
instance on a server (on a domain) to another OFBiz instance on another
server (on another domain) without having to sign up between the 2 while 
keeping things secure.

There could be many reasons why you want to split OFBiz application on servers. 
In their case it was for performance issues.

The technology used is as secure as possible. Like OAuth 2.0 it uses a token 
but it does not need a middle authorization server (think to  two-factor
authentication) because it's only for OFBiz instances of the same version.

To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 
"Token Based Authentication" that I use in my last patch.

For me there is only one question outstanding: how to store the Token secret. 
But this should not prevent us to commit Deepak's work.

It's now a long time (9 months) since I started this work. And my last patch is 
ready for a month.

I crossed several issues which are now all resolved. So please review and 
answer to this thread.

Without negative comments well argumented I'll commit both OFBIZ-9833 and 
OFBIZ-10307 in a week. You can always test and review later, we use RTC.

Also a veto on a commit is always possible... Of course, as ever, a good 
consensus is preferred.

Let me know if you need more information about the goal. For the technical 
details I think I already provided them the in OFBIZ-10307.

Jacques

Re: HTTP Compression not working for some files (JS and CSS)

[girish . vasmatkar]

On 2018/08/20 07:20:38, Michael Brohl  wrote: 
> Hi Girish,
> 
> how did you check that these files are not getting compressed before the 
> transfer?
> 
> They are decompressed by the browser after the transfer so you won't see 
> that they were compressed.
> 
> Regards,
> 
> Michael
> 
> 
> Am 20.08.18 um 09:12 schrieb girish.vasmat...@hotwaxsystems.com:
> > Hi Devs!!!
> >
> > I see that we have enabled HTTP compression in in the HTTP and HTTPS 
> > connectors, but I am observing that it is not working properly for some of 
> > the JS and CSS files.
> >
> > All medium to large files (more than 50 KB or so) are not getting 
> > compressed. Has anyone else observed the same? I can definitely see that 
> > Content-Encoding:gzip response header is set for all the files that are 
> > compressed and the transfer size does indicate they were compressed based 
> > on what size I see on the disk.
> >
> >
> > Thanks,
> > Girish Vasmatkar
> > HotWax Systems
> >
> 
> 
>
Hi Michael

I can see the response headers in Chrome developers tools. For some files for 
example, OfbizUtil.js, Content-Encoding:gzip indicating that it was compressed 
by the server and received in compressed format. 
For the other ones, no Content-Encoding header is present. Also, there is a 
"Size" tab and a "Transferred" tab in FireBug showing 47.13 KB and 11.79 KB 
values respectively. For select2-4.0.6.js which is one of the one I don't see 
come compressed the corresponding values are 143.01 KB and 142.80 KB and the 
Content-Encoding header is also absent.

Thanks and Regards,
Girish Vasmatkar
HotWax Systems

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

[Jacques Le Roux]

Le 19/08/2018 à 20:25, Taher Alkhateeb a écrit :

Wow, so after having a long, long email (as usual) talking about how
good the work is and you deployed for a client (my god!), now you
reverted because of a fundamental flaw pointed out by Scott.

I did not revert, it was not committed. I updated my patch and it was really a 
small change.
Initially I already planned to not use the client side to grab the loginId with OFBIZ-10206. But forgot about it because I stumbled upon many other 
issues since.

This work was challenging at many levels, believe me. I'll not drop it without 
really good arguments!


And now you want to apply lazy consensus despite my objections and the
obvious flaw which you acknowledged. This makes me skeptical of the
entire approach and the quality of the code in question. I would
prefer if you halt all work and study what you're doing instead of
falling into more mistakes.

Again, please give me good *technical* arguments. My work works and is safe, 
prove the contrary.


I'm also distressed with your phrase "Without negative comments well
argumented I'll commit both". In other words if you can't convince me
i'm pushing this code, why, because I want to. That's not how
community works.

Keep calm, you can still prevent me to commit if  you give me good argument as 
Scoot did.
And if you can't find them now you will still be able to veto if you find some 
later.
And again as explained at https://www.apache.org/foundation/voting.html#Veto 
you need arguments:

   /To prevent vetos from being used capriciously, they must be accompanied by 
a technical justification showing why the change is bad (opens a
   security exposure, negatively affects performance, //etc.//). A veto without 
a justification is invalid and has no weight./

Remember this is only trunk and will not be released before at least 1 year and 
most possibly 2, you have plenty of time.

I'm all ears

Jacques


On Sun, Aug 19, 2018 at 3:29 PM Jacques Le Roux
 wrote:

ôOps missed some words...

Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :

I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and 
https://jwt.io/ to

allow an user to connect to another OFBiz instance (using same version than 
source) on another server (target) on another domain w/o signing in.

Jacques

Re: HTTP Compression not working for some files (JS and CSS)

[Michael Brohl]

Hi Girish,

how did you check that these files are not getting compressed before the 
transfer?


They are decompressed by the browser after the transfer so you won't see 
that they were compressed.


Regards,

Michael


Am 20.08.18 um 09:12 schrieb girish.vasmat...@hotwaxsystems.com:

Hi Devs!!!

I see that we have enabled HTTP compression in in the HTTP and HTTPS 
connectors, but I am observing that it is not working properly for some of the 
JS and CSS files.

All medium to large files (more than 50 KB or so) are not getting compressed. 
Has anyone else observed the same? I can definitely see that 
Content-Encoding:gzip response header is set for all the files that are 
compressed and the transfer size does indicate they were compressed based on 
what size I see on the disk.


Thanks,
Girish Vasmatkar
HotWax Systems






smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

[Michael Brohl]

Hi Jacques,

maybe I am missing something but you should be able to get the session 
with request.getSession(), no?


Regards,

Michael


Am 20.08.18 um 09:06 schrieb Jacques Le Roux:

Hi Deepak,

I used this way because it starts in Groovy with
    ProductSearchSession.getProductSearchResult(request, delegator, 
prodCatalogId)
the session is not in the request, and there is no alternative 
signature for ProductSearchSession::getProductSearchResult
As I did not want to get too deep in that I preferred this simple way 
at the root in Groovy


Please amend it if you see a better way to do it.

Thanks

Jacques


Le 20/08/2018 à 06:33, Deepak Dixit a écrit :

Hi Jacques,

I think instead of setting dispatcher in groovy files I think we can fix
the work done under OFBIZ-9164

Instead of getting dispatcher from a session we can get this from the
request or can use the different method signature of
searchGetConstraintStrings method.
{code}

LocalDispatcher dispatcher = (LocalDispatcher)
request.getAttribute("dispatcher");

{code}



Thanks & Regards
--
Deepak Dixit


On Sun, Aug 19, 2018 at 9:00 PM,  wrote:


Author: jleroux
Date: Sun Aug 19 15:30:42 2018
New Revision: 1838381

URL: http://svn.apache.org/viewvc?rev=1838381=rev
Log:
Fixed: Search in Ecommerce no longer works
(OFBIZ-10531)

I guess that when I worked on OFBIZ-9164 I broke that.

I found 3 occurences where the dispatcher was not in the session 
because

the
session comes from the request and the request has not it in.

Modified:
 ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
 ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
 ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy

Modified: ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev= 


1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19 15:30:42 
2018

@@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)

Modified: ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/product/groovyScripts/catalog/find/KeywordSearch.groovy?rev= 


1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19 15:30:42 
2018

@@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)

Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
ecommerce/groovyScripts/catalog/LayeredNavigation.
groovy?rev=1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy (original)
+++ ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy Sun Aug 19 15:30:42 2018
@@ -47,6 +47,7 @@ if (!parameters.clearSearch || !"N".equa
  ProductSearchSession.searchClear(session)
  }

+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, 
delegator,

prodCatalogId)










smime.p7s
Description: S/MIME 

HTTP Compression not working for some files (JS and CSS)

[girish . vasmatkar]

Hi Devs!!!

I see that we have enabled HTTP compression in in the HTTP and HTTPS 
connectors, but I am observing that it is not working properly for some of the 
JS and CSS files.

All medium to large files (more than 50 KB or so) are not getting compressed. 
Has anyone else observed the same? I can definitely see that 
Content-Encoding:gzip response header is set for all the files that are 
compressed and the transfer size does indicate they were compressed based on 
what size I see on the disk.


Thanks,
Girish Vasmatkar
HotWax Systems

Re: svn commit: r1838381 - in /ofbiz: ofbiz-framework/trunk/applications/order/groovyScripts/entry/catalog/ ofbiz-framework/trunk/applications/product/groovyScripts/catalog/find/ ofbiz-plugins/trunk/e

[Jacques Le Roux]

Hi Deepak,

I used this way because it starts in Groovy with
    ProductSearchSession.getProductSearchResult(request, delegator, 
prodCatalogId)
the session is not in the request, and there is no alternative signature for 
ProductSearchSession::getProductSearchResult
As I did not want to get too deep in that I preferred this simple way at the 
root in Groovy

Please amend it if you see a better way to do it.

Thanks

Jacques


Le 20/08/2018 à 06:33, Deepak Dixit a écrit :

Hi Jacques,

I think instead of setting dispatcher in groovy files I think we can fix
the work done under OFBIZ-9164

Instead of getting dispatcher from a session we can get this from the
request or can use the different method signature of
searchGetConstraintStrings method.
{code}

LocalDispatcher dispatcher = (LocalDispatcher)
request.getAttribute("dispatcher");

{code}



Thanks & Regards
--
Deepak Dixit


On Sun, Aug 19, 2018 at 9:00 PM,  wrote:


Author: jleroux
Date: Sun Aug 19 15:30:42 2018
New Revision: 1838381

URL: http://svn.apache.org/viewvc?rev=1838381=rev
Log:
Fixed: Search in Ecommerce no longer works
(OFBIZ-10531)

I guess that when I worked on OFBIZ-9164 I broke that.

I found 3 occurences where the dispatcher was not in the session because
the
session comes from the request and the request has not it in.

Modified:
 ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
 ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
 ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy

Modified: ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/order/groovyScripts/entry/catalog/KeywordSearch.groovy?rev=
1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/order/
groovyScripts/entry/catalog/KeywordSearch.groovy Sun Aug 19 15:30:42 2018
@@ -28,6 +28,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, delegator,
prodCatalogId)

Modified: ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/product/groovyScripts/catalog/find/KeywordSearch.groovy?rev=
1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/product/
groovyScripts/catalog/find/KeywordSearch.groovy Sun Aug 19 15:30:42 2018
@@ -24,6 +24,7 @@ import org.apache.ofbiz.product.product.
  module = "KeywordSearch.groovy"

  // note: this can be run multiple times in the same request without
causing problems, will check to see on its own if it has run again
+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, delegator,
prodCatalogId)

Modified: ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
ecommerce/groovyScripts/catalog/LayeredNavigation.
groovy?rev=1838381=1838380=1838381=diff

==
--- ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy (original)
+++ ofbiz/ofbiz-plugins/trunk/ecommerce/groovyScripts/
catalog/LayeredNavigation.groovy Sun Aug 19 15:30:42 2018
@@ -47,6 +47,7 @@ if (!parameters.clearSearch || !"N".equa
  ProductSearchSession.searchClear(session)
  }

+request.getSession().setAttribute("dispatcher",dispatcher)
  ProductSearchSession.processSearchParameters(parameters, request)
  prodCatalogId = CatalogWorker.getCurrentCatalogId(request)
  result = ProductSearchSession.getProductSearchResult(request, delegator,
prodCatalogId)

Re: Component and Component Set Dependencies

[Jacques Le Roux]

Great, thanks Deepak

Jacques


Le 20/08/2018 à 06:20, Deepak Dixit a écrit :

Hi Jacques,

I'll check and share details ASAP.

On Sun, Aug 19, 2018 at 3:57 PM, Jacques Le Roux mailto:jacques.le.r...@les7arts.com>> wrote:

Hi Deepak,

Before I remove all the comments at 
https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies


 and remove in the graph the dependency from the
accounting to workeffort introduced by r1710178 ;


could you please confirm there is no longer data dependencies from 
accounting to workeffort since we moved the data to applications/datamodel?

I guess there should not be and we should try to clean this graph for maybe 
other such dependencies (only because of data) now that this step is
almost complete (after Rishi's future effort on "Shipping data duplicated

"
 thread)

Thanks

Jacques