J
Joan Wild
Gary said:
Not at all
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Not at all
J
Joan Wild
Gary said:One of my challenges is tables created by the Owner, that a
subsequent macro will delete. However, the person invoking the macro
will be a User and not the Owner or an Admin User.
I suspect I can recreate the macro by either emptying the table and
appending or making that User the owner.
I favour making the User (non owner, non admin) the owner... then the
macros will all simply just run.
I would do the former actually. You can create two RWOP queries ( one to
delete the records, the other to append). Then you don't have to make the
user the owner. And if you want to use macros, you just create a macro to
run the two queries in succession.
G
Gary Dikkema
Again you are spot on!
I found that your method is the ONLY way to do it. I couldn't make the User
the owner as the Dev MDW doesn't have Users, only Groups.
I also learned the meaning of Groups. It's really to bridge the application
between the Dev and the Dist MDw's.
I found that your method is the ONLY way to do it. I couldn't make the User
the owner as the Dev MDW doesn't have Users, only Groups.
I also learned the meaning of Groups. It's really to bridge the application
between the Dev and the Dist MDw's.
G
Gary Dikkema
So here's what I found out. Someone yank my chain if I am WRONG!
I created the database and pulled down my code into it. I used the DEV.MDW
for all the dev work including access rights. I used the Security FAQ to
ensure I created a unique admin account, and some Groups for my application.
I then took away Admins group from the Admin account. I made sure the User
group had access to nothing. I ensured my Groups that I set up had the
proper accesses to components as needed; i.e.: 'power' groups had everything
they needed; 'view' groups have access to only the macros/queries/reports
required.
I then created a DIST MDW file and worked on the database using it.
I created a SiteAdmin user and the Groups as set up in the DEV MDW. I then
created Users and linked them to the appropriate Groups.
I noticed that I had to add the admin user account from the DEV MDW into the
DIST MDW so that I could use the SiteAdmin user as a admin account to
manipulate some queries that my 'power' and 'view' users had no access to. I
found this strange considering the SiteAdmin was an admin user. However,
without the admin user account from the DEV MDW I noticed all the modules
had an <Unknown> owner.
Perhaps someone can correct me here if this action should not be done.
I seem to have a double lock down system that seems to work well.
The only way I can flip that Bypass flag is to ensure I use an Admin user
account (I used the DIST MDW).
I am happy!
I hope no one (TC or Joan) will burst my bubble and tell me I still have
something screwed up. <VBG> However, if I do, by all means burst the bubble!
Thanks again for all of the help! You took a newbie an awful long way!
Sincerely,
Gary D
I created the database and pulled down my code into it. I used the DEV.MDW
for all the dev work including access rights. I used the Security FAQ to
ensure I created a unique admin account, and some Groups for my application.
I then took away Admins group from the Admin account. I made sure the User
group had access to nothing. I ensured my Groups that I set up had the
proper accesses to components as needed; i.e.: 'power' groups had everything
they needed; 'view' groups have access to only the macros/queries/reports
required.
I then created a DIST MDW file and worked on the database using it.
I created a SiteAdmin user and the Groups as set up in the DEV MDW. I then
created Users and linked them to the appropriate Groups.
I noticed that I had to add the admin user account from the DEV MDW into the
DIST MDW so that I could use the SiteAdmin user as a admin account to
manipulate some queries that my 'power' and 'view' users had no access to. I
found this strange considering the SiteAdmin was an admin user. However,
without the admin user account from the DEV MDW I noticed all the modules
had an <Unknown> owner.
Perhaps someone can correct me here if this action should not be done.
I seem to have a double lock down system that seems to work well.
The only way I can flip that Bypass flag is to ensure I use an Admin user
account (I used the DIST MDW).
I am happy!
I hope no one (TC or Joan) will burst my bubble and tell me I still have
something screwed up. <VBG> However, if I do, by all means burst the bubble!
Thanks again for all of the help! You took a newbie an awful long way!
Sincerely,
Gary D
T
test
(snip)
Then just log-on as the Owner of those tables, then give the relevant other
users Delete permission to those tables. This will let those users delete
those tables, even though they are not the owner of those tables, and, they
are not "an Admin user" - whatever that is!
Gary, every workgroup file has an Admins >group<, and an Admin >user<. The
members of the Admins group >of the workgroup file that was used to create
the database<, have special priviligies. These are the "super users", if you
want to use that term. The Admin user might or might not be a "super user".
Referring to "an Admin user", is a sure recipe for further confusion! If you
want to refer to the "super users", refer to "the members of the Admins
group of the workgroup file that was used to create the database". Do not
call them "Admin users"!!
Cheers,
TC
One of my challenges is tables created by the Owner, that a subsequent macro
will delete. However, the person invoking the macro will be a User and not
the Owner or an Admin User.
Then just log-on as the Owner of those tables, then give the relevant other
users Delete permission to those tables. This will let those users delete
those tables, even though they are not the owner of those tables, and, they
are not "an Admin user" - whatever that is!
Gary, every workgroup file has an Admins >group<, and an Admin >user<. The
members of the Admins group >of the workgroup file that was used to create
the database<, have special priviligies. These are the "super users", if you
want to use that term. The Admin user might or might not be a "super user".
Referring to "an Admin user", is a sure recipe for further confusion! If you
want to refer to the "super users", refer to "the members of the Admins
group of the workgroup file that was used to create the database". Do not
call them "Admin users"!!
Cheers,
TC
G
Gary Dikkema
test said:(snip)
Then just log-on as the Owner of those tables, then give the relevant
other
users Delete permission to those tables. This will let those users delete
those tables, even though they are not the owner of those tables, and,
they
are not "an Admin user" - whatever that is!
Could have sworn I tried that more than once. It was another trying day
where the light sort of came on, got extinguished and then came back on ...
finally.
Creating Queries that delete content and then modifying Make queries to
Append got me the results I wanted.
Gary, every workgroup file has an Admins >group<, and an Admin >user<. The
members of the Admins group >of the workgroup file that was used to create
the database<, have special priviligies. These are the "super users", if
you
want to use that term.
So we have two levels of Admin users... thanks!
The Admin user might or might not be a "super user".
Referring to "an Admin user", is a sure recipe for further confusion! If
you
want to refer to the "super users", refer to "the members of the Admins
group of the workgroup file that was used to create the database". Do not
call them "Admin users"!!
I have so much to learn.
You're right; using correct terminology to define problems is bound to get
me better answers.
Thanks so much!
J
Joan Wild
Gary said:So we have two levels of Admin users... thanks!
I have so much to learn.
You're right; using correct terminology to define problems is bound
to get me better answers.
You may find Jack MacDonald's paper is helpful in driving home the message
about Admin User and Admins Group.
www.geocities.com/jacksonmacd
J
Joan Wild
Gary said:I created the database and pulled down my code into it. I used the
DEV.MDW for all the dev work including access rights. I used the
Security FAQ to ensure I created a unique admin account, and some
Groups for my application. I then took away Admins group from the
Admin account. I made sure the User group had access to nothing. I
ensured my Groups that I set up had the proper accesses to components
as needed; i.e.: 'power' groups had everything they needed; 'view'
groups have access to only the macros/queries/reports required.
Please tell us that isn't the order in which you did things.
I then created a DIST MDW file and worked on the database using it.
What do you mean 'worked on the database'. Do you mean testing, or did you
play with permissions while using this mdw?
I created a SiteAdmin user and the Groups as set up in the DEV MDW. I
then created Users and linked them to the appropriate Groups.
I noticed that I had to add the admin user account from the DEV MDW
into the DIST MDW so that I could use the SiteAdmin user as a admin
account to manipulate some queries that my 'power' and 'view' users
had no access to. I found this strange considering the SiteAdmin was
an admin user.
Your SiteAdmin user serves a single purpose - to add users. It shouldn't be
manipulating queries.
However, without the admin user account from the DEV
MDW I noticed all the modules had an <Unknown> owner.
As it should be. Are you saying that once you added the Admin User from the
dev.mdw, those modules no longer showed <Unknown>? If that's the case then
you did not secure it properly. The Admin User should not own *anything*.
It is quite acceptable for objects to show owner - unknown.
The only way I can flip that Bypass flag is to ensure I use an Admin
user account (I used the DIST MDW).
No user in the Dist.mdw should be able to flip the bypass flag.
G
Gary Dikkema
Thanks!
Joan Wild said:You may find Jack MacDonald's paper is helpful in driving home the message
about Admin User and Admins Group.
www.geocities.com/jacksonmacd
G
Gary Dikkema
See inline.
No, actually I created the security group DEV first... the rest looks about
right.
Seems I have failed to add a group req'd for loading test scenarios which I
call 'scaffolding' from my dev days...
I played or tested the permissions. That's when the use of Groups struck
home.
OK. That's what the Security FAQs says. However, how is that done when the
Bypass flag is flipped and the database locked down? Thru use of custom
code? or is the Bypass flag not set?
I think I see what I did wrong, please read on. Hopefully I have articulated
it precisely.
I added the owner who is a member of the Admins group.
I had this all working as per your comments, I then added some
'scaffolding'queries etc and then they didn't run as they should have have.
So I added back my owner who is a member of the Admins group. I need to
ponder this some more. I think I know what I did wrong; you've pointed it
out but I need to get my head around it and add a scaffolding group with the
right permissions... I think! And then yank the owner account with admin
rights from the Dist MDW. And then add a user with 'scaffolding' rights to
execute the req'd modules... I think. That's how the rest of the stuff
works.
Because they don't own the Database? Not even the SiteAdmin user who is a
member of the Admins group? So what all should the SiteAdmin have rights to?
Perhaps nothing except for being a member of the Admins group?
Back to the Dist MDW to do some further work...
Thanks Joan!
Joan Wild said:Please tell us that isn't the order in which you did things.
No, actually I created the security group DEV first... the rest looks about
right.
Seems I have failed to add a group req'd for loading test scenarios which I
call 'scaffolding' from my dev days...
What do you mean 'worked on the database'. Do you mean testing, or did
you
play with permissions while using this mdw?
I played or tested the permissions. That's when the use of Groups struck
home.
Your SiteAdmin user serves a single purpose - to add users. It shouldn't
be
manipulating queries.
OK. That's what the Security FAQs says. However, how is that done when the
Bypass flag is flipped and the database locked down? Thru use of custom
code? or is the Bypass flag not set?
I think I see what I did wrong, please read on. Hopefully I have articulated
it precisely.
As it should be. Are you saying that once you added the Admin User from
the
dev.mdw, those modules no longer showed <Unknown>? If that's the case
then
you did not secure it properly. The Admin User should not own *anything*.
It is quite acceptable for objects to show owner - unknown.
I added the owner who is a member of the Admins group.
I had this all working as per your comments, I then added some
'scaffolding'queries etc and then they didn't run as they should have have.
So I added back my owner who is a member of the Admins group. I need to
ponder this some more. I think I know what I did wrong; you've pointed it
out but I need to get my head around it and add a scaffolding group with the
right permissions... I think! And then yank the owner account with admin
rights from the Dist MDW. And then add a user with 'scaffolding' rights to
execute the req'd modules... I think. That's how the rest of the stuff
works.
No user in the Dist.mdw should be able to flip the bypass flag.
Because they don't own the Database? Not even the SiteAdmin user who is a
member of the Admins group? So what all should the SiteAdmin have rights to?
Perhaps nothing except for being a member of the Admins group?
Back to the Dist MDW to do some further work...
Thanks Joan!
G
Gary Dikkema
Joan,
Allright!
I now have this as per your last paragraph.
The only troubling thing is why the SiteAdmin user account, who has admin
group permissions, should NOT be able to flip the Bypass flag.
I thought all users with admin rights could do that?
Where am I going wrong on this?
Allright!
I now have this as per your last paragraph.
The only troubling thing is why the SiteAdmin user account, who has admin
group permissions, should NOT be able to flip the Bypass flag.
I thought all users with admin rights could do that?
Where am I going wrong on this?
G
Gary Dikkema
To answer my own question, the only method I can see is to only allow the
Admins group open/run permissions and even then I am NOT so sure this is the
answer.
Anyone?
TIA.
Gary D
Admins group open/run permissions and even then I am NOT so sure this is the
answer.
Anyone?
TIA.
Gary D
G
Gary Dikkema
I do believe I have found the problem.
Created a new DISTR MDW security file...
Followed the instructions and now my application is locked down.
More testing for accuracy to follow.
Created a new DISTR MDW security file...
Followed the instructions and now my application is locked down.
More testing for accuracy to follow.
J
Joan Wild
Gary said:See inline.
No, actually I created the security group DEV first... the rest looks
about right.
It's not clear from your description, but you should have created a new
database while logged in as the user you put into the Admins Group. It
sounds as though you didn't do this in the correct order. It's important to
follow the steps in the FAQ *in order*.
OK. That's what the Security FAQs says. However, how is that done
when the Bypass flag is flipped and the database locked down? Thru
use of custom code? or is the Bypass flag not set?
The siteAdmin user can start Access using the dist.mdw, and not open any
database. They'll have access to the security accounts menu to add users
and assign to groups. (I've lost track of what version you are using - they
may have to open a database, but it can be any database, even a new one).
I added the owner who is a member of the Admins group.
Not necessary.
I had this all working as per your comments, I then added some
'scaffolding'queries etc and then they didn't run as they should have
have.
You should explain this some more. There is no reason that the owner of
these queries be in your dist.mdw.
So I added back my owner who is a member of the Admins group. I
need to ponder this some more. I think I know what I did wrong;
you've pointed it out but I need to get my head around it and add a
scaffolding group with the right permissions... I think! And then
yank the owner account with admin rights from the Dist MDW. And then
add a user with 'scaffolding' rights to execute the req'd modules...
I think. That's how the rest of the stuff works.
Because they don't own the Database? Not even the SiteAdmin user who
is a member of the Admins group? So what all should the SiteAdmin
have rights to? Perhaps nothing except for being a member of the
Admins group?
Yes. Only a user who is a member of the Admins Group in the dev.mdw can
flip it back, and only while logged in using the dev.mdw; and you're not
shipping that. Remember that the Admins Group is *different* in each
workgroup file.
J
Joan Wild
Gary said:I now have this as per your last paragraph.
The only troubling thing is why the SiteAdmin user account, who has
admin group permissions, should NOT be able to flip the Bypass flag.
I thought all users with admin rights could do that?
No. The SiteAdmin user is a member of the Admins Group in the dist.mdw
Only a user who is a member of the Admins Group in the dev.mdw (which is the
one you would use to flip the bypass) can flip it back. The Admins Group is
not the same in each mdw.
G
Gary Dikkema
THANK YOU Joan!
Somehow in my zealousness to complete the project yesterday... I messed up!
Call it fatigue.
I read the Security FAQ and it said this may take a week or more to sink in
and I'm sure I said... no way!
Well OK so now I am BSng a bit. <VBG>
But you are right, the new DISTR MWD I created has NO access to my main
database. It has access only to the groups and users that will be accessing
my database. My concerns are gone; no way to touch and pilfer my code now!
Slickest double lock system that I have ever seen; now that I see it working
properly.
I will read and review your other post(s) later...
Somehow in my zealousness to complete the project yesterday... I messed up!
Call it fatigue.
I read the Security FAQ and it said this may take a week or more to sink in
and I'm sure I said... no way!
Well OK so now I am BSng a bit. <VBG>
But you are right, the new DISTR MWD I created has NO access to my main
database. It has access only to the groups and users that will be accessing
my database. My concerns are gone; no way to touch and pilfer my code now!
Slickest double lock system that I have ever seen; now that I see it working
properly.
I will read and review your other post(s) later...
T
TC
(snip)
Gary, you are still using undefined terminology. You really will get nowhere
until you start to use the terms correctly.
- What are "admin group permissions"? There is an Admin user, and an Admins
group. There is no "admin" group unless you create one yourself.
- What are "admin rights"? There is a permission or right called "Delete
Data". There is a permission or right called "Read Design". There are
various other permissions or rights. But there is no permission or right
called "admin".
By "admin group permissions", and "admin rights", you probably mean: "the
permissions automatically given to members of the Admins group of the
workgroup file that created the database". If so, I recommend you use the
full & proper terminology. Otherwise, it all gets too confusing for
everyone!
Cheers,
TC
The only troubling thing is why the SiteAdmin user account, who has admin
group permissions, should NOT be able to flip the Bypass flag.
I thought all users with admin rights could do that?
Gary, you are still using undefined terminology. You really will get nowhere
until you start to use the terms correctly.
- What are "admin group permissions"? There is an Admin user, and an Admins
group. There is no "admin" group unless you create one yourself.
- What are "admin rights"? There is a permission or right called "Delete
Data". There is a permission or right called "Read Design". There are
various other permissions or rights. But there is no permission or right
called "admin".
By "admin group permissions", and "admin rights", you probably mean: "the
permissions automatically given to members of the Admins group of the
workgroup file that created the database". If so, I recommend you use the
full & proper terminology. Otherwise, it all gets too confusing for
everyone!
Cheers,
TC
T
TC
Joan Wild said:No. The SiteAdmin user is a member of the Admins Group in the dist.mdw
Only a user who is a member of the Admins Group in the dev.mdw (which is the
one you would use to flip the bypass) can flip it back. The Admins Group is
not the same in each mdw.
A perfect example of the importance of using the correct terminology, Gary!
Cheers,
TC
G
Gary Dikkema
Yep! A key piece!
TC said:A perfect example of the importance of using the correct terminology,
Gary!
Cheers,
TC
G
Gary Dikkema
Actually I probably meant any user account with the Admins user group.
Actually, my double lockdown finally works... so I got somewhere TC! <VBG>
However, you're right! In the terminology dept I suck! Old concepts are hard
to part with and I seem to get a piece almost right in some emails and then
nothing in others. <VBG>
So tell me what 'right' is required to allow a Macro to delete an Object...
a table object? I suspect you have to be this person who created the
Database, as per your last paragraph?
And RWOP is used how and where? I had to remove RWOP from queries to allow
a user who had full rights to tables and queries and macros the ability to
execute those queries. As soon as I flipped the query from Owner to User
things worked.
It's another early morning and hopefully some of the above makes sense to
you. I also had other questions, but can't seem to remember them. <VBG>
Thanks!
Actually, my double lockdown finally works... so I got somewhere TC! <VBG>
However, you're right! In the terminology dept I suck! Old concepts are hard
to part with and I seem to get a piece almost right in some emails and then
nothing in others. <VBG>
So tell me what 'right' is required to allow a Macro to delete an Object...
a table object? I suspect you have to be this person who created the
Database, as per your last paragraph?
And RWOP is used how and where? I had to remove RWOP from queries to allow
a user who had full rights to tables and queries and macros the ability to
execute those queries. As soon as I flipped the query from Owner to User
things worked.
It's another early morning and hopefully some of the above makes sense to
you. I also had other questions, but can't seem to remember them. <VBG>
Thanks!
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.