- value xml:lang=itTu non sei autorizzare a vedere questa pagina.
(Permesso EXAMPLE_VIEW o EXAMPLE_ADMIN necessario)/value
BTW, that Italian isn't quite correct...
--
David N. Welton
http://www.welton.it/davidw/
http://www.dedasys.com/
Sent from Padova, PD, Italy
On Apr 30, 2009, at 11:38 PM, David E Jones wrote:
On Apr 30, 2009, at 11:07 AM, Jacopo Cappellato wrote:
On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
... I'd be happy to discuss additional changes as well (which
aren't yet documented) like adding support to check multiple
: Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./
config/ data/ entitydef/ security/ servicedef/ widget/example/
To: dev@ofbiz.apache.org
Date: Thursday, April 30, 2009, 7:31 PM
I'm trying to come up with a use case where this sort of
logic would be applicable, but I just cannot
Andrew,
I thought we were getting away from using the required-permissions
element and using the permission-service element instead.
If this type of change is made in other components, it will break a lot
of code - because some components use permission service SECAs.
-Adrian
Adrian,
I will start a new thread to discuss this, but before I do I want to
make sure there isn't something I neglected to account for. Could you
please provide an example of such a service which uses SECA permission
services?
Andrew
On May 1, 2009, at 12:04 PM, Adrian Crum wrote:
Look in the Asset Maintenance component.
-Adrian
Andrew Zeneski wrote:
Adrian,
I will start a new thread to discuss this, but before I do I want to
make sure there isn't something I neglected to account for. Could you
please provide an example of such a service which uses SECA permission
What is the point of changing all of the security data like this? In
other words, is there some reason that the new security stuff can't
use the same permissions syntax/convention as the older security stuff?
The thing to keep in mind is that not only will there be a big effort
to make
Inline...
On Apr 30, 2009, at 12:11 PM, David E Jones wrote:
What is the point of changing all of the security data like this? In
other words, is there some reason that the new security stuff can't
use the same permissions syntax/convention as the older security
stuff?
Looks like
Andrew Zeneski wrote:
I'd be happy to discuss additional changes as well (which aren't yet
documented) like adding support to check multiple permissions at once,
returning a Map of results from that permission check. So, if you or
anyone else has a wish list for security, let me know so I can
That sounds cool. I'm not sure what that would really look like, but
nevertheless sounds really cool! :) If you need anything from me let
me know...
Andrew
On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
Andrew Zeneski wrote:
I'd be happy to discuss additional changes as well (which
On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
... I'd be happy to discuss additional changes as well (which aren't
yet documented) like adding support to check multiple permissions at
once, returning a Map of results from that permission check. So, if
you or anyone else has a wish
set field=hasPermission value=${(hasPermission['update:context1'] ||
hasPermission['update:context2']) amp;amp;
hasPermission['update:context3']} type=Boolean/
or something like that. I'm still working out the details.
-Adrian
Andrew Zeneski wrote:
That sounds cool. I'm not sure what that
Adrian,
this is really interesting.
However I think it is time to start thinking to define our own xml
friendly keywords for and || operators; I would like to express
that statement with something like this:
set field=hasPermission value=${(hasPermission['update:context1']
OR
Those keywords are not recognized by UEL.
-Adrian
Jacopo Cappellato wrote:
Adrian,
this is really interesting.
However I think it is time to start thinking to define our own xml
friendly keywords for and || operators; I would like to express that
statement with something like this:
set
From: Andrew Zeneski andrew.zene...@hotwaxmedia.com
Looks like you probably missed the big design document which explains
everything:
http://docs.ofbiz.org/x/-B0
http://docs.ofbiz.org/x/JR4
Great stuff, thanks Andrew!
Jacques
From: Adrian Crum adri...@hlmksw.com
We could. It would be an easy change to make. I would like to think about it for a while. Maybe even hear from others on the
subject.
For me it's not a problem using or || instead of AND or OR. We are all acquainted to this and this will be used only by
No problem, I thought I posted this to the dev list last week, I
wonder where I sent it...
On Apr 30, 2009, at 2:28 PM, Jacques Le Roux wrote:
From: Andrew Zeneski andrew.zene...@hotwaxmedia.com
Looks like you probably missed the big design document which
explains everything:
Not really, I just implemented what we were talking about offline, its
called findMatchingPermissions(). So, now you can check (read|update|
delete):party:1 and it will return you a map containing :
read:party:1 = (true|false)
update:party:1 = (true|false)
delete:party:1 =
I think this is a great idea and would be very useful. Could you
create a JIRA issue for this and relate it to OFBIZ-2380?
Andrew
On Apr 30, 2009, at 1:07 PM, Jacopo Cappellato wrote:
On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
... I'd be happy to discuss additional changes as well
What I have in mind with UEL is different. The plan is to be able to
write a permissions expression that can replace many lines of
mini-language code.
Btw, I decided to use UEL functions instead of extending the syntax.
-Adrian
Andrew Zeneski wrote:
Not really, I just implemented what we
On Apr 30, 2009, at 11:07 AM, Jacopo Cappellato wrote:
On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
... I'd be happy to discuss additional changes as well (which
aren't yet documented) like adding support to check multiple
permissions at once, returning a Map of results from that
David E Jones wrote:
In other words, it is nice to check permissions on the client side
and/or show permission impact in the UI, but that just improves the
UI... it doesn't actually enforce any of those permissions checks
because it is really easy to change HTML and/or spoof a request (ie
No, I'm not saying I disagree with you. You totally missed my point. I
don't think anyone is suggesting removing permissions checking from the
UI or the services. Let's get that settled right away.
Jacopo is asking for a way to control the display of screen widgets
based on the user's
I don't think it is common that permissions checked in the UI are
different than permissions checked when the input from the UI is
processed. In fact, I don't think I've ever run into that problem.
The problem I have run into over and over is that in almost every
toolkit and framework
FYI and I only realized this the other day but beanshell supports
exactly this type of feature where you can specify things @and, @or
and etc. for use in xml files http://www.beanshell.org/manual/syntax.html#Document_Friendly_Entities
I wonder if we do this it might be worth following the
I like that idea. Less chance that an unintended conversion would occur.
-Adrian
Scott Gray wrote:
FYI and I only realized this the other day but beanshell supports
exactly this type of feature where you can specify things @and, @or and
etc. for use in xml
files
26 matches
Mail list logo
