We should neither simply remove those links nor should we have anything
hard coded.
Let's look for a smarter solution. No need to hurry, better take some
time to implement something sustainable.
Regards,
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 21.08.18 um 07:00 schrieb Jacques Le Roux
Hi Jacques,
for my comments on
https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-9241 see Jira.
For the proposal, I think we should provide the demo with the framwork +
plugins. It shows the portential of the whole ecosystem and I see no
reason why we should not make it available?
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 h
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
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 b
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
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 e
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
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 proto
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
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 R
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
avai
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 b
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 wik
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, wareh
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 i
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 goo
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 poi
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 lo
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/Va
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
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,
Gi
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 a
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 logg
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 top
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 hav
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
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
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 m
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!!!
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(requ
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 ca
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 d
33 matches
Mail list logo