On Mon, May 15, 2017 at 8:01 AM, Kirk Brooks via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> David,
> Thanks for throwing this in. It really does make more sense to use a
> longint even if it is (currently) only a binary choice.
>
Kirk:
If you're using a number to represent a hierarchy, the surest
Hi Kirk,
> On 16 May 2017, at 24:59 AEST, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> Thanks much for taking the time to share. The immediate situation I'm
> trying to work with isn't as formally hierarchical as your example plus I
> need to exclude 'restricted' data from even Re
David,
Thanks for throwing this in. It really does make more sense to use a
longint even if it is (currently) only a binary choice.
On Fri, May 12, 2017 at 6:03 PM, David Adams via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> Just as a simple point, it's nice to have access values as a number:
>
> 1
Hi Jorg,
Thanks much for taking the time to share. The immediate situation I'm
trying to work with isn't as formally hierarchical as your example plus I
need to exclude 'restricted' data from even Read Only. I'm managing the
table & field access separately. ie. permission to even see a given table
Like I said, many developers don't like 4D access system, in fact, any 4D
inbuilt-tools such as QR editor, Query Editor, Label Editor, Sequence Number,
Triggers etc. I'm weird and kept using them intensively even after
developing on 4D for 27
years. I'm happily remained to be amature:-)
Al
riginal Message-
From: 4D_Tech [mailto:4d_tech-boun...@lists.4d.com] On Behalf Of Kirk Brooks
via 4D_Tech
Sent: Friday, May 12, 2017 6:14 PM
To: 4D iNug Technical <4d_tech@lists.4d.com>
Cc: Kirk Brooks
Subject: Re: Schemes for record level access control
Right - so the ultimate permis
On Sat, May 13, 2017 at 9:04 AM,
David Adams wrote:
>
>
> Just as a simple point, it's nice to have access values as a number:
>
> 1 2 3 4 5
>
> Imagine that access increases at each step.
>
> // On after query
> C_LONGINT($1;$user_access_level)
> $user_access_level:=$1
>
> QUERY SELECTION([F
Just as a simple point, it's nice to have access values as a number:
1 2 3 4 5
Imagine that access increases at each step.
// On after query
C_LONGINT($1;$user_access_level)
$user_access_level:=$1
QUERY SELECTION([Foo];[Foo]Minimum_access_score <= $user_access_level)
So, if the user has a leve
G’day Kirk,
> On 13 May 2017, at 05:42 AEST, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> I'd like to hear from some of you who have implemented systems that allow
> for record-level access control in a 4D database.
Pick me! ;-)
You’re sure you want to discuss this on the list d
It would be a lot easier if 4D password system is activated. Just a new group
"TeamAccess_Bypass". LIke I said before, 4D password system does great help on
achieving this.
While we find 4D password system is invaluable, I know many developers don't
like it.
Alan Chan
4D iNug Technical <4d_te
Right - so the ultimate permission is the most permissive of all available.
On Fri, May 12, 2017 at 4:56 PM, Alan Chan via 4D_Tech <4d_tech@lists.4d.com
> wrote:
> I assume a member might belongs to multiple teams but will a member
> belongs to multiple clubs?
>
> Alan Chan
>
> 4D iNug Technical
If implemented correctly, performance hit could be minimum.
Do what query
if(records in selection([WhateverTable]>0)
if(<>TeamAccessRequired)\\some customers do not need this feature
Query selection with array([WhateverTable]Team;<>CurTeam)
end if
end if
<>CurTeam is loaded from team member tabl
I assume a member might belongs to multiple teams but will a member belongs to
multiple clubs?
Alan Chan
4D iNug Technical <4d_tech@lists.4d.com> writes:
>Hi Alan,
>Those are the go-to solutions. In my case we aren't using the 4D password
>system so I can't rely on that. Plus I need actual recor
Hi Jody,
That sounds like real DOD level stuff. Fortunately I don't need that level
but it gives me some ideas.
What kind of performance hit did you see as a result of all that extra
processing?
On Fri, May 12, 2017 at 4:09 PM, G-Mail via 4D_Tech <4d_tech@lists.4d.com>
wrote:
> Kirk:
>
> Of cour
Hi Alan,
Those are the go-to solutions. In my case we aren't using the 4D password
system so I can't rely on that. Plus I need actual record level
restriction. So to follow your example, I may want a Team to be able to see
themselves and other teams in their Club (just making this up) but not
teams
We restricted record access based on Team (Field related to Team and Member
table), Module (menu bar), History (Date) and other access such as cross team
and also by field level such as viewing cost, modifying sales price, bypassing
margin control
or credit control, just name a few, through 4D s
Kirk:
Of course there are all sorts of ways this could be done. It all depends on the
complexity.
We had to record by each user which records they were restricted from seeing.
We also needed to permit / restrict by a group as well.
Therefore we could not put a ‘flag’ within the record. When a r
Hi folks,
I'd like to hear from some of you who have implemented systems that allow
for record-level access control in a 4D database. This is the sort of thing
where we want to prevent unauthorized users from seeing or inferring the
'restricted' records.
Theoretically it's pretty easy - include a
18 matches
Mail list logo
