Subject | Re: [IBO] Read Only confusion |
---|---|
Author | Helen Borrie |
Post date | 2006-03-08T00:21:10Z |
At 08:02 AM 8/03/2006, you wrote:
RequestLive False and ReadOnly unless you make them otherwise. So
what you really want is a procedure that sets RequestLive True (or
sets custom xxxSQL) on those queries *unless* the user has the specified role.
btw, there is no such thing as the user's ROLE indicating anything
via the API that you application can use to decide what ACL
privileges the user has.
have defined (or materialised) the xxxxSQL properties in the
application then you are effectively trying to give the user write
access. Make sure you set these properties (or RequestLive) at
run-time, *after* you know who is logged in.
underlying tables and/or a client-side dependency (MasterLinks or
KeyLinks). Your "selects-only" role will need REFERENCES and SELECT
privileges on any tables that FKs are pointing to.
>I have the following code that runs after a user logs on and beforeLogically, this is the wrong side to attack from. All queries are
>I open the datasets if the
>user's ROLE indicates that their access is Read Only (and their ROLE
>gives them 'SELECT' privileges
>only).
>
>== snip ==
>procedure TdmMain.MakeReadOnly;
>begin
> qryProjRevisions.RequestLive := False;
> qryProjRevisions.ReadOnly := True;
> qryRevisionCATs.RequestLive := False;
> qryRevisionCATs.ReadOnly := True;
> qryGetProjectsInfo.RequestLive := False;
> qryGetProjectsInfo.ReadOnly := True;
>end;
>========
RequestLive False and ReadOnly unless you make them otherwise. So
what you really want is a procedure that sets RequestLive True (or
sets custom xxxSQL) on those queries *unless* the user has the specified role.
btw, there is no such thing as the user's ROLE indicating anything
via the API that you application can use to decide what ACL
privileges the user has.
>In spite of this, when I try to log on as such a user I get an errorSure. A user with SELECT permissions can only select. But if you
>message which is strange in two
>respects.
>
>1. It tells me that I do not have Insert/Write permission to a Field
>in qryGetProjectsInfo.
> (actually, something called qryGetProjectsInfo.IBOqrqryGetProjectsInfo)
have defined (or materialised) the xxxxSQL properties in the
application then you are effectively trying to give the user write
access. Make sure you set these properties (or RequestLive) at
run-time, *after* you know who is logged in.
>2. The field that is subject to the complaint is not in qryGetProjectsInfoYou probably have a foreign key relationship between the two
> it is in qryProjRevisions.
underlying tables and/or a client-side dependency (MasterLinks or
KeyLinks). Your "selects-only" role will need REFERENCES and SELECT
privileges on any tables that FKs are pointing to.
>I have checked that the procedure MakeReadOnlyYep. Unfortunately, it's not quite the right medicine. :-)
>does in fact run before I attempt to open the TIBOQueries.