|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Password setup showing hisotry of records changedI need to set up security and have never done this before. I am an
intermediate to advanced level user whose new boss wants to have a form have permissions for the following (I am giving ideas at the same time): 1.)The form will only let the user change the record (probably based on the autonumber and the Logged by field) that he or she entered. 2)The form will have a history table (possibly as a subtable named Changes History for each record, when that record was changed, the date and time, etc.) Once you set up the security for each user, when they log on to the database and go that record to change it, will it stamp their user ID in the Changes History subtable simultaneously not letting them change a record that they didn't create? Allen Browne has an audit trail sample on his site you can use:
www.allenbrowne.com/AppAudit.html Do users need to see other's records? If they don't then you can base your form on a query that uses the CurrentUser() function as a criteria on the 'user ID' field. If they do need to see other's records (but not edit them), then you can write code in the Current event of the form to check if the user ID = CurrentUser() and change the AllowEdits/AllowDeletions properties of the form. -- Joan Wild Microsoft Access MVP Show quote "Adriana" <Adri***@discussions.microsoft.com> wrote in message news:B5A76744-407F-4728-BE5E-53A27CA259BE@microsoft.com... >I need to set up security and have never done this before. I am an > intermediate to advanced level user whose new boss wants to have a form have > permissions for the following (I am giving ideas at the same time): > > 1.)The form will only let the user change the record (probably based on the > autonumber and the Logged by field) that he or she entered. > 2)The form will have a history table (possibly as a subtable named Changes > History for each record, when that record was changed, the date and time, > etc.) > > Once you set up the security for each user, when they log on to the database > and go that record to change it, will it stamp their user ID in the Changes > History subtable simultaneously not letting them change a record that they > didn't create? Ok that makes sense. But could you help me with the code? Does this involve
setting up the security as well? I set up security with the security wizard, but now it won't let me do anything even though I set myself up as an Admin. Guess I'll have to import all the objects to a new database sicne that's the only way to get around this problem. Show quote "Joan Wild" wrote: > Allen Browne has an audit trail sample on his site you can use: > www.allenbrowne.com/AppAudit.html > > Do users need to see other's records? If they don't then you can base your form on a query that uses the CurrentUser() function as a criteria on the 'user ID' field. If they do need to see other's records (but not edit them), then you can write code in the Current event of the form to check if the user ID = CurrentUser() and change the AllowEdits/AllowDeletions properties of the form. > > -- > Joan Wild > Microsoft Access MVP > "Adriana" <Adri***@discussions.microsoft.com> wrote in message news:B5A76744-407F-4728-BE5E-53A27CA259BE@microsoft.com... > >I need to set up security and have never done this before. I am an > > intermediate to advanced level user whose new boss wants to have a form have > > permissions for the following (I am giving ideas at the same time): > > > > 1.)The form will only let the user change the record (probably based on the > > autonumber and the Logged by field) that he or she entered. > > 2)The form will have a history table (possibly as a subtable named Changes > > History for each record, when that record was changed, the date and time, > > etc.) > > > > Once you set up the security for each user, when they log on to the database > > and go that record to change it, will it stamp their user ID in the Changes > > History subtable simultaneously not letting them change a record that they > > didn't create? > If you don't want to implement user level security, I believe Allen's example uses the Windows username - you can go that route instead. I believe that his example has a link to the code to get the Windows username instead.
Re: One more thing...users do need to see other's records but not edit them, just their own. Would that be based from a drop down box that shows all the users (this drop down box comes from an Employees table that I concatenated to show first and last name). No you wouldn't need to do that. You can use the same function that Allen refers to get the Windows username and change the form's properties based on that. This way you don't need to have the user select their 'name' from a list - what would stop them from choosing a different name than themselves? -- Joan Wild Microsoft Access MVP Show quote "Adriana" <Adri***@discussions.microsoft.com> wrote in message news:0B4A9DFA-602B-410C-8B1C-B00B419BF682@microsoft.com... > Ok that makes sense. But could you help me with the code? Does this involve > setting up the security as well? I set up security with the security wizard, > but now it won't let me do anything even though I set myself up as an Admin. > Guess I'll have to import all the objects to a new database sicne that's the > only way to get around this problem. > One more thing...users do need to see other's records but not edit them, just
their own. Would that be based from a drop down box that shows all the users (this drop down box comes from an Employees table that I concatenated to show first and last name). Show quote "Joan Wild" wrote: > Allen Browne has an audit trail sample on his site you can use: > www.allenbrowne.com/AppAudit.html > > Do users need to see other's records? If they don't then you can base your form on a query that uses the CurrentUser() function as a criteria on the 'user ID' field. If they do need to see other's records (but not edit them), then you can write code in the Current event of the form to check if the user ID = CurrentUser() and change the AllowEdits/AllowDeletions properties of the form. > > -- > Joan Wild > Microsoft Access MVP > "Adriana" <Adri***@discussions.microsoft.com> wrote in message news:B5A76744-407F-4728-BE5E-53A27CA259BE@microsoft.com... > >I need to set up security and have never done this before. I am an > > intermediate to advanced level user whose new boss wants to have a form have > > permissions for the following (I am giving ideas at the same time): > > > > 1.)The form will only let the user change the record (probably based on the > > autonumber and the Logged by field) that he or she entered. > > 2)The form will have a history table (possibly as a subtable named Changes > > History for each record, when that record was changed, the date and time, > > etc.) > > > > Once you set up the security for each user, when they log on to the database > > and go that record to change it, will it stamp their user ID in the Changes > > History subtable simultaneously not letting them change a record that they > > didn't create? > |
|||||||||||||||||||||||