Jump to content

Views of just the current login user


This topic is 6920 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I have a question: can I get FileMaker Pro 7 to just show a login user's data, versus seeing other records as well? For example, if a user logs in, I want that person to be able to just access his or her records and not anyone elses information.

Thanks,

mvang04

Link to comment
Share on other sites

Create a record creation field based on the user account name, Capture the users account name in a global and built a second occurrance of the table based on the global to account creator. Build your layouts based on that TO which in effect limites the view to that users records only.

Link to comment
Share on other sites

Thanks for responding Ken!

Okay, so I originally had a field name ID. It produced an auto number. I changed the ID field to auto enter data into the field upon creation by account name. It is global. Then, I self joinded the ID field therefore, it created an occurance of that table for me - I took the defult name -

on my layout, the ID field shows the account name - however, it shows different records. Is this because I have not defined the account name somehow?

What do I do now?

Link to comment
Share on other sites

For the relationship to work like you want you need 2 fields.

Left side should probably be an Unstored calc, = Get(AccountName), or a global set by script.

Right side is a regular Text field, NOT global, auto-enter AccountName (one of the options).

Existing records will not have any data in that field, so you must enter an account name.

[Optional:

If you want to get serious, you can also limit their Privileges, Record access to view only their own records, based on the above relationship not being empty. That way, if they somehow bypass the above navigation, they will see only <<no access>> in all the fields of other's records.

There is a glitch with this however (at least for me). Which was that if they land on another's record at startup (likely), they will have no access, hence be unable to evaluate any fields or the relationship :-[

A simple fix is to land first in a file or table where they do not have record-level restrictions, then use a similar relationship from there.

Get(AccountName), Unstored, is going to be consistent throughout the solution.

You also have to trap for Show All Records and use the relationship instead (use your own button). Priveleges, Menu access should NOT be "All" (to block command keys). Other Finds are automatically handled by FileMaker, according to the record-level restriction.]

Link to comment
Share on other sites

Question:

What privileges do we set so a user can view their records?>

I have created two test account, one full access and the other data entry only - the user who's access is limited to only data entry, I have set privileges to their account but now, they have <<No Access>> accross the board...they can't even view theirs?

Thanks!

mvang04

Link to comment
Share on other sites

  • 6 months later...

I have a similar problem and I didn't understand a good part of your solution. My particular problem is listed below.

Each user has their own Account Name/Password. Some of the users are salespeople and some are not. I have a "Customer" table that has a field called Salesperson_ID (the value is always a number). Each record in this "Customer" table has an associated Salesperson_ID automatically generated and based on a looked up value from the "Zip Code" table. I also have a "Salesperson" table has three things: name, their account login name (hand typed), and their Salesperson_ID (hand typed).

I need help creating a script that will match the Account Name that is logged in with the correct record in the "Salesperson" table. Then, if a match is found, it should find and display all records from the "Customer" table that have the same matching Salesperson_ID. If there is not match I would prefer that it either display <<No Access>> or ask for a re-login.

Thanks,

Greg

Link to comment
Share on other sites

I should restate one part of what I said. I said to base record-level restriction on the relationship of the Unstored calculation, Get (AccountName) to the person's name in the record.

That would work, but is kind of the long way around, hence slower than just using this is the limit calculation:

Get (AccountName) = person's name field

You would use the relationship to "filter" their records, both from another table, and in a "Show All" script (which otherwise will show the <<no access>> records.

This is a little file with this stuff (and a bit more) in it.

[ I forgot to say; the "users" pw are their first name, the "manager's" (me) appears to be blank. You can change all that anyway.]

The master:

Account: dev

PW: open

(also in the text file)

AccountgPWLimit.zip

Link to comment
Share on other sites

  • 2 months later...

Hi Fenton, great stuff you got there.

And it is exactly what i was attempting to do.

But it still doesn't work for me and i don't know what to fix. I have attach a file and i tried to integrated ,as well, all the stuff you did to manage the account, wich, that part work great.

Basically i have 2 tables in the same File One call "Staff: which is: records with personnal infos of my staff, and the other call "Hours" wich is where a want people to enter the hours the have worked on. But has they opened the file i want they to see only the hours related to their account.Not all the hours from everybody.

p.s: full acces account is "admin" and PW is "open"

thx

guy

Link to comment
Share on other sites

Hi Fenton, great stuff you got there.

And it is exactly what i was attempting to do.

But it still doesn't work for me and i don't know what to fix. I have attach a file and i tried to integrated ,as well, all the stuff you did to manage the account, wich, that part work great.

Basically i have 2 tables in the same File One call "Staff: which is: records with personnal infos of my staff, and the other call "Hours" wich is where a want people to enter the hours the have worked on. But has they opened the file i want they to see only the hours related to their account.Not all the hours from everybody.

p.s: full acces account is "admin" and PW is "open"

thx

guy

Link to comment
Share on other sites

Hi Fenton, great stuff you got there.

And it is exactly what i was attempting to do.

But it still doesn't work for me and i don't know what to fix. I have attach a file and i tried to integrated ,as well, all the stuff you did to manage the account, wich, that part work great.

Basically i have 2 tables in the same File One call "Staff: which is: records with personnal infos of my staff, and the other call "Hours" wich is where a want people to enter the hours the have worked on. But has they opened the file i want they to see only the hours related to their account.Not all the hours from everybody.

p.s: full acces account is "admin" and PW is "open"

thx

guy

Link to comment
Share on other sites

Your file won't download for me:

Warning: Unexpected character in input: '' (ASCII=12) state=1 in /home/fmforums/public_html/files/152183-Test_hours.fp7.sitx on line 145

Parse error: parse error, unexpected T_STRING in /home/fmforums/public_html/files/152183-Test_hours.fp7.sitx on line 145

Perhaps you should just .zip it instead. It could be the .sitx doesn't work :-?

Link to comment
Share on other sites

Your file won't download for me:

Warning: Unexpected character in input: '' (ASCII=12) state=1 in /home/fmforums/public_html/files/152183-Test_hours.fp7.sitx on line 145

Parse error: parse error, unexpected T_STRING in /home/fmforums/public_html/files/152183-Test_hours.fp7.sitx on line 145

Perhaps you should just .zip it instead. It could be the .sitx doesn't work :-?

Link to comment
Share on other sites

Your file won't download for me:

Warning: Unexpected character in input: '' (ASCII=12) state=1 in /home/fmforums/public_html/files/152183-Test_hours.fp7.sitx on line 145

Parse error: parse error, unexpected T_STRING in /home/fmforums/public_html/files/152183-Test_hours.fp7.sitx on line 145

Perhaps you should just .zip it instead. It could be the .sitx doesn't work :-?

Link to comment
Share on other sites

There are a few things wrong.

Artist:

You have Field Access to None

These people can't do anything at all if they can't access any fields

Scripts access is None

You can't limit their found records if you can't run a script (executable only)

There is another "Catch 22," for everyone to be aware of.

Get (AccountName) CANNOT be used in a relationship if the person does not have access to the record they've landed on in the table they began on. You can't get them to a record they do have access to, because of the above.

2 solutions:

1. Use a Find instead. That is not restricted, as you are not really ON a record in Find mode.

Find for their Get (AccoutName) in the name field. Trap for no found records.

That is probably the simplest. I should have used that in my example file. But I usually use relationships for things, perhaps obsessively :-]

2. Start from (or flip to) a table where they DO have access to all records. That's what my example does. Then use a relationship from a Get (AccountName) field to the name field in the table you want to go to, which does have restrictions.

You can test for this in a table: Get (RecordAccess) = 0 means no access.

Once they are on their records in the restricted table they will never end up on other's records as long as you also script Show All. Other Finds, relationships, etc., are handled by FileMaker to keep them within their View restrictions. So the relationship will work. It's only that first landing that causes problems.

Look over your Account settings. They need fine-tuning. I never give lower-level accounts "All" editing privileges. Use "Editing Only" or even "Minimum." You will need to give them buttons for Finds, New, etc., but you should anyway.

Do give people enough access to fields so they can do what they need to do. Do give them access to scripts they need to run. Don't show the password scripts in the Scripts Menu.

Test_hours2.zip

Link to comment
Share on other sites

  • Newbies

I noticed this post was pretty old and was wondering if you could help me with the solution you provided earlier. Can I apply this solution to an existing database by importing the fields and scripts and reconnecting the associations manually? I have a sample of the database I could post but since this was an old thread I wasn't sure if I would get a response.

Link to comment
Share on other sites

Yes, the same general solution would work with any file with a similar setup. There is also an alternative method, using a Find for the AccountName instead of a relationship. (The attached file is still a multi-file solution. It could easily be in the same file. I'm just lazy I guess :-)

(P.S. The extra little files are AppleScript droplets. They let you drop the file on to open with different passwords. Convenient for testing. I guess Mac developers are just a lazy bunch in general. PC guys can toss those.)

AccountgPWLimitFind.zip

Link to comment
Share on other sites

  • 5 weeks later...
  • Newbies

Thanks for the file (gPW). I was able to build my new database from it. I originally thought that the test_hours2 one would work, but it does not from the web publishing - all accounts are visible.

Since I am new to FM7 perhaps this is a stupid question, but . . . when the web enabled database is started how can I both define what layout to start on and also can I do a find to show only the users records and not all the "no access" files?

Also, for some reason my users can not perform a find as they can not put anything into the user name field.

Thanks!

Link to comment
Share on other sites

This topic is 6920 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.