It's because the menus for the limited privilege set are set to "minimum", which does not include a new record command. You can give them the new record command by giving them full menus, creating custom menus, or adding a "new record" button to you layout. I did the last of these, and was able to add a new record as rosalie.
I wish everyone would ask their question, describe their setup and outline their issue in such a structured manner, AND provide a sample file.
I can Create now a New Record Using my Account Rosalie by Changing my menus.
Now, my problem again is how can my Users sees their own record when they Log in? I tried creating another account "Rose" with same Privilege Set "Limited" but I was able to see the records that I created Using the Account "Rosalie"
Thank you so much.
Thanks Erolst, because I would like to solve my question quickly.
Taking a look at your file one problem is that you don't have any extended privileges if you are on a network or using WebDirect.
I think the other problem may be Users::AccountName = Get ( AccountName ).
Instead you may need to have Get(AccountName) = Products_UserName "a new field in products for storing the account name such as Products_UserName" Then each product should have that users name.
Hope this helps.
Please forgive the newbie..Can you please explain me this line... "a new field in products for storing the account name such as Products_UserName" Then each product should have that users name.
Products_UserName will be a text field or a calculation field?
Is the relationship between my two tables okey?
Thank you so much.
Rosalie, there are several 'auto-enter' settings for: text, number (serial), date, time, timestamp. The text can be Account Name (login) and Name (the name of the computer).
See if this kb article helps:
Here's a training video that might help as well:
Thank you so much for the link.
How can I eliminate the <no Access> on the fields.
If you are using fm14, have you considered Hide Object When...
You can use these functions to test:
I would assign accounts to the priv. set and test for that rather than trying to test each account name.
My reading of Rosalie's post "I'm trying to set up an privilege set that a user will see only his/her created record on the database" would seem to indicate that each user would only see his/her unique record which is why I suggested testing for the user.
But, I'm a little confused. Do you want to have your user see only one product record, or a subset of product records?
I want that a User see only the product that he/she entered.
Is there a way or script that can do that upon opening the file to avoid seeing the <no access> in the fields created by other User?
Sounds like you really want to lock down your user. You can make a script that finds only that user's record and have it trigger when the file is opened. Under File>file options>script triggers and set that script to fire on open. You need to have a field in your products table to put the user's name and enter each users name, then in the opening script user the 'get user name' function, put it in a variable or global, and set up your find. Then they won't see any 'no access' records
But . . . if you really want to lock it down you will need to lock the user out of the status bar where he/she can still do finds and get in trouble. Then set up a few buttons to perform essential tasks that might be performed in the status bar.
Building on what Kurt said, you can hijack the commands involved (like Find Mode, Perform Find, Find All, Constrain, and Extend) and substitute your own scripts using Custom Menus. Such a setup will override the normal behavior of the Status Bar icons (all they do is execute the matching command in the menu).
That way, you don't have to hide the Status Bar (which is useful for lots of things other than performing Finds).
One suggestion, do your developing with a lot of records in the testing environment since security it's a very cool feature but you may incur in big performance issues.
If you are going to use the the DB over a WAN test again with many records in the DB.