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
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
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
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
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
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
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
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
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
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
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
>
>
>
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
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
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
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
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!!!
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
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
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,
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
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
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
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
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
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
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
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
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
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,
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
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
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
32 matches
Mail list logo
