Make form uneditable based upon Access login group

[Mike MacSween]

There doesn't seem to be a way to do this. The Access security model seems
to be based around allowing the users to read/alter design of the form
(where reading includes editing the data)

I want to allow certain users (well, a member of a certain group) - and I'm
talking about mdw users and groups here to be able to edit (or not) data on
a form. But still be able to view the data even if they can't edit it, er,
them.

Is this going to be: get the users group on the load/got focus of the form,
and if they're in the right group unlock it otherwise lock it?

Yours, Mike MacSween

[Bas Cost Budde]

Why, aren't there read and write rules for tables as well?

Mike MacSween wrote:

There doesn't seem to be a way to do this. The Access security model seems
to be based around allowing the users to read/alter design of the form
(where reading includes editing the data)

I want to allow certain users (well, a member of a certain group) - and I'm
talking about mdw users and groups here to be able to edit (or not) data on
a form. But still be able to view the data even if they can't edit it, er,
them.

Is this going to be: get the users group on the load/got focus of the form,
and if they're in the right group unlock it otherwise lock it?

Yours, Mike MacSween

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
For human replies, replace the queue with a tea

[Mike MacSween]

"Bas Cost Budde" <b.*********@heuvelqop.nl> wrote in message
news:da**********@localhost.localdomain...

Why, aren't there read and write rules for tables as well?
Yes, but there don't seem to be for forms.

Mike
Mike MacSween wrote:

There doesn't seem to be a way to do this. The Access security model
seems to be based around allowing the users to read/alter design of the
form (where reading includes editing the data)

I want to allow certain users (well, a member of a certain group) - and
I'm talking about mdw users and groups here to be able to edit (or not)
data on a form. But still be able to view the data even if they can't
edit it, er, them.

Is this going to be: get the users group on the load/got focus of the
form, and if they're in the right group unlock it otherwise lock it?

Yours, Mike MacSween

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
For human replies, replace the queue with a tea

[Bas Cost Budde]

I may misunderstand the question. If you enable read rights on a table
for certain groups, and add write rights for another, in any form based
on that table the rights will be applied, right? You don't have to
bother with form rights in order to set table access. IME, that is.

Mike MacSween wrote:

"Bas Cost Budde" <b.*********@heuvelqop.nl> wrote in message
news:da**********@localhost.localdomain...

Why, aren't there read and write rules for tables as well?

Yes, but there don't seem to be for forms.

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
For human replies, replace the queue with a tea

[Mike MacSween]

"Bas Cost Budde" <b.*********@heuvelqop.nl> wrote in message
news:da**********@localhost.localdomain...

I may misunderstand the question. If you enable read rights on a table for
certain groups, and add write rights for another, in any form based on that
table the rights will be applied, right? You don't have to bother with form
rights in order to set table access. IME, that is.
Yes. The form is for courses. One form creates new courses. I want several
of the users to be able to create new courses, and in the course of creating
those courses change details, at the point of creation. For instance they
might create a course as a Coronary Heart Disease course, in error, and
realize it should be a Diabetes course. So they'll need read/write rights on
the table. But once the course has been created I want a far smaller number
of users to have the right to edit details, and delete the course, via this
other form. There's some cascading deletes going on that I want only a small
number of users to be able to initiate. That's why the table rules won't do
exactly what I want here.

Of course perhaps I ought to just consider setting the rights on the BE
tables with a finer level of granularity. Which I'm thinking about now.

Cheers, Mike

Mike MacSween wrote:

"Bas Cost Budde" <b.*********@heuvelqop.nl> wrote in message
news:da**********@localhost.localdomain...

Why, aren't there read and write rules for tables as well?

Yes, but there don't seem to be for forms.

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
For human replies, replace the queue with a tea

[Bas Cost Budde]

> Yes. The form is for courses. One form creates new courses. I want several

of the users to be able to create new courses, and in the course of creating
those courses change details [...] But once the course has been created
I want a far smaller number of users to have the right to edit details
I see. That would be hard to effect via table rules.

If you can live with the fact that bypassing the forms would allow any
user any change, you could effect some security manually. I have spent
significant effort in that direction, and it certainly can be done.

You must have a table structure for your user/group members, and
settings maybe per table, maybe just for this instance. I'd use the
BeforeInsert event to loosen the restraints for a new record, and
AfterInsert to tighten them. Activate can be the spot to set general
rights, derived from the user/group structure. Or probably just the Load
event.
Of course perhaps I ought to just consider setting the rights on the BE
tables with a finer level of granularity. Which I'm thinking about now.

If that provides you with sufficient functionality, it's the way I'd
recommend. I chose the word 'significant' above deliberately...
--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
For human replies, replace the queue with a tea

[Bri]

Mike MacSween wrote:

Yes. The form is for courses. One form creates new courses. I want several
of the users to be able to create new courses, and in the course of creating
those courses change details, at the point of creation. For instance they
might create a course as a Coronary Heart Disease course, in error, and
realize it should be a Diabetes course. So they'll need read/write rights on
the table. But once the course has been created I want a far smaller number
of users to have the right to edit details, and delete the course, via this
other form. There's some cascading deletes going on that I want only a small
number of users to be able to initiate. That's why the table rules won't do
exactly what I want here.

Of course perhaps I ought to just consider setting the rights on the BE
tables with a finer level of granularity. Which I'm thinking about now.

Cheers, Mike

Mike,

Change the rights on the Tables to no rights of any kind, then create
saved queries for the two different forms and set the appropriate rights
on each of the queries.

--
Bri

[Bri]

Bri wrote:

Mike MacSween wrote:

Yes. The form is for courses. One form creates new courses. I want
several of the users to be able to create new courses, and in the
course of creating those courses change details, at the point of
creation. For instance they might create a course as a Coronary Heart
Disease course, in error, and realize it should be a Diabetes course.
So they'll need read/write rights on the table. But once the course
has been created I want a far smaller number of users to have the
right to edit details, and delete the course, via this other form.
There's some cascading deletes going on that I want only a small
number of users to be able to initiate. That's why the table rules
won't do exactly what I want here.

Of course perhaps I ought to just consider setting the rights on the
BE tables with a finer level of granularity. Which I'm thinking about
now.

Cheers, Mike

Mike,

Change the rights on the Tables to no rights of any kind, then create
saved queries for the two different forms and set the appropriate rights
on each of the queries.

--
Bri

Oops, spoke too soon. OK, here's another idea. Do as above (ie deny
rights to tables, create the queries), but make them WITH OWNERACCESS
OPTION. Then create two new UserIDs that won't actually be used by
anyone. Give these UserIDs permissions to the tables as appropriate for
the two forms (one each). Then change the owner of each query to the
appropriate UserID. The Query then will have the rights assigned to the
User that is now the Owner of it. I bit fiddly, but should work.

--
Bri

[Bri]

Bri wrote:

Bri wrote:

Mike MacSween wrote:

Yes. The form is for courses. One form creates new courses. I want
several of the users to be able to create new courses, and in the
course of creating those courses change details, at the point of
creation. For instance they might create a course as a Coronary Heart
Disease course, in error, and realize it should be a Diabetes course.
So they'll need read/write rights on the table. But once the course
has been created I want a far smaller number of users to have the
right to edit details, and delete the course, via this other form.
There's some cascading deletes going on that I want only a small
number of users to be able to initiate. That's why the table rules
won't do exactly what I want here.

Of course perhaps I ought to just consider setting the rights on the
BE tables with a finer level of granularity. Which I'm thinking about
now.

Cheers, Mike

Mike,

Change the rights on the Tables to no rights of any kind, then create
saved queries for the two different forms and set the appropriate
rights on each of the queries.

--
Bri

Oops, spoke too soon. OK, here's another idea. Do as above (ie deny
rights to tables, create the queries), but make them WITH OWNERACCESS
OPTION. Then create two new UserIDs that won't actually be used by
anyone. Give these UserIDs permissions to the tables as appropriate for
the two forms (one each). Then change the owner of each query to the
appropriate UserID. The Query then will have the rights assigned to the
User that is now the Owner of it. I bit fiddly, but should work.

--
Bri

Double oops. In your second thread, Joan Wild pointed out that my first
idea here was close. Set the required permissions on the query, no
rights to tables, query is a RWOP query owned by ID that has rights to
the tables. Tested it and it works.

--
Bri