DayBackForFileMaker

Only See My Events

DayBackForFileMaker.OnlySeeMyEvents History

Hide minor edits - Show changes to output

September 26, 2018, at 11:01 PM by KC Embrey - Added #HardCode
Added line 19:
[[#HardCode]]
April 02, 2018, at 09:54 PM by KC Embrey - Fixed broken apostrophe characters and spelling/grammar issues
Changed lines 21-22 from:
-> Another approach is to intercept the find request the calendar performs when looking for records. This is what we think of as a hidden filter. To do this edit the script "Event Find" and locate the comment "Hard code any 'hidden' filters here" toward the middle of the script. The following If () statements show you how to add find criteria specific to each of your [[multiple sources | sources]]. Set fields here following the If or Else If branch for your source, reading the script comments for guidance.
to:
-> Another approach is to intercept the find request the calendar performs when looking for records. This is what we think of as a hidden filter. To do this edit the script "Event Find" and locate the comment "Hard code any ''hidden'' filters here" toward the middle of the script. The following If () statements show you how to add find criteria specific to each of your [[multiple sources | sources]]. Set fields here following the If or Else If branch for your source, reading the script comments for guidance.
Changed lines 29-32 from:
This is very easily done; you�ll use FileMaker�s built in Access Privileges to create rules as to which records a logged in user can see, which they can edit etc. You can restrict which layouts they can see and even which specific fields they have access to.

If you haven�t worked with FileMaker�s Access Privileges before, take a moment and read the overview in FileMaker's built in help, check out Contents > Protecting databases > Creating and editing privilege sets > Editing record access privileges.
to:
This is very easily done; you'll use FileMaker's built-in Access Privileges to create rules as to which records a logged in user can see, which they can edit etc. You can restrict which layouts they can see and even which specific fields they have access to.

If you haven't worked with FileMaker's Access Privileges before, take a moment and read the overview in FileMaker's built-in help, check out Contents > Protecting databases > Creating and editing privilege sets > Editing record access privileges.
Changed lines 37-42 from:
The only tricky part here is finding some attribute of the user�s login to tie that login to a record in the calendar�s events table. The items you have at your disposal are Get ( AccountName ) and Get ( AccountPrivilegeSetName ). The privilege set name is probably going to be used for general things like �administrator� or �sales rep� and may be used in FileMaker�s Access Privileges  to limit what a user can see or edit. You may, for example, craft access privileges so that sales reps can�t access the "Under the Hood" layout in DayBack.

So you�ll probably be using Get ( AccountName ) in your access privilege calculations to compare a logged in user with the user linked to an appointment. There are two basic approaches here:

-> '''1.''' You can make the user�s Account Name match a field already in the database. So you could make sure all your accounts are created with the Account Names being real first and last names of your users. Account names would be things like �Bill Smith�. If you did that, an access privilege calc that would let the logged in user only see their appointments would look like this:
to:
The only tricky part here is finding some attribute of the user's login to tie that login to a record in the calendar's events table. The items you have at your disposal are Get ( AccountName ) and Get ( AccountPrivilegeSetName ). The privilege set name is probably going to be used for general things like 'administrator' or 'sales rep' and may be used in FileMaker's Access Privileges to limit what a user can see or edit. You may, for example, craft access privileges so that sales reps can't access the "Under the Hood" layout in DayBack.

So you'll probably be using Get ( AccountName ) in your access privilege calculations to compare a logged in user with the user linked to an appointment. There are two basic approaches here:

-> '''1.''' You can make the user' Account Name match a field already in the database. So you could make sure all your accounts are created with the Account Names being real first and last names of your users. Account names would be things like 'Bill Smith'. If you did that, an access privilege calc that would let the logged in user only see their appointments would look like this:
Changed lines 45-51 from:
-> Make sure this calc is set to evaluate from the context of the same table occurrence used for your Source No 1 layout. So there are a couple things to note about this calc. The first is that it just returns a 1 or 0; a 1 if the Account Name is one of the names of the users linked to the appointment, a 0 if it is not. That is how all your access privileges calcs should be written: to return a 1 (ie. be true) if the user can see, edit, etc. the record. The second thing to note is that we don�t use the = sign. This is because an appointment can have more than one user, so its user will never be �equal� to any one user. Instead we use FilterValues to see if the Account Name �is a member� of the users on the appointment.

-> '''2.''' The second approach is to create your own field in a users table to match the account name; you�d essentially be recording the account name in FileMaker. Do not, of course, record the user�s password in FileMaker as that would not be very secure.

-> Note that if your user name is not indexed in the events table this calc can really slow the solution down as FileMaker looks at some related information for each event it is trying to display.

-> Now of course you may want to have some users that can see everyone�s appointments: you don�t have to mess with the calc above to do this, simply assign these �power users� to a different privilege set that doesn�t limit the appointments they can view at all.
to:
-> Make sure this calc is set to evaluate from the context of the same table occurrence used for your Source No 1 layout. So there are a couple things to note about this calc. The first is that it just returns a 1 or 0; a 1 if the Account Name is one of the names of the users linked to the appointment, a 0 if it is not. That is how all your access privileges calcs should be written: to return a 1 (ie. be true) if the user can see, edit, etc. the record. The second thing to note is that we don't use the = sign. This is because an appointment can have more than one user, so its user will never be ''equal'' to any one user. Instead, we use FilterValues to see if the Account Name ''is a member'' of the users on the appointment.

-> '''2.''' The second approach is to create your own field in a users table to match the account name; you'd essentially be recording the account name in FileMaker. Do not, of course, record the user's password in FileMaker as that would not be very secure.

-> Note that if your username is not indexed in the events table this calc can really slow the solution down as FileMaker looks at some related information for each event it is trying to display.

-> Now, of course, you may want to have some users that can see everyone's appointments: you don't have to mess with the calc above to do this, simply assign these 'power users' to a different privilege set that doesn't limit the appointments they can view at all.
February 20, 2017, at 09:41 PM by KC Embrey - Updated privilege set FIleMaker help titles
Changed lines 31-33 from:
If you haven�t worked with FileMaker�s Access Privileges before, take a moment and read the overview in FileMaker's built in help, check out Contents > Protecting databases with accounts and privilege sets > Creating and managing privilege sets > Editing record access privileges.

For more information about limiting which records a user can see, continue to the "Editing record access privileges" page
: you're interested in the "Limited" option under number 4.
to:
If you haven�t worked with FileMaker�s Access Privileges before, take a moment and read the overview in FileMaker's built in help, check out Contents > Protecting databases > Creating and editing privilege sets > Editing record access privileges.

For more information about limiting which records a user can see, continue to the "To edit record access privileges for individual tables" section
: you're interested in the "Limited" option under number 4.
Changed line 37 from:
The only tricky part here is finding some attribute of the user�s login to tie that login to a record in the calendar�s events table. The items you have at your disposal are Get ( AccountName ) and Get ( PrivilegeSetName ). The privilege set name is probably going to be used for general things like �administrator� or �sales rep� and may be used in FileMaker�s Access Privileges  to limit what a user can see or edit. You may, for example, craft access privileges so that sales reps can�t access the admin tabs on the calendar.
to:
The only tricky part here is finding some attribute of the user�s login to tie that login to a record in the calendar�s events table. The items you have at your disposal are Get ( AccountName ) and Get ( AccountPrivilegeSetName ). The privilege set name is probably going to be used for general things like �administrator� or �sales rep� and may be used in FileMaker�s Access Privileges  to limit what a user can see or edit. You may, for example, craft access privileges so that sales reps can�t access the "Under the Hood" layout in DayBack.
Changed lines 9-12 from:
You can also hard-code a filter into the calendar by intercepting the SQL request our calendar makes when finding events to display: think of this as a filter the users can't change.

Both of these filter methods use the calendar's interface to restrict what shows up: users could still navigate to the event list and search for events, possibly finding events that belong to other users. If that is not acceptable you'd use FileMaker's built in Access Privileges to restrict what a user can see. This technique uses features built into FileMaker and is not specific to our calendar.
to:
You can also hard-code a filter into the calendar by intercepting the find request DayBack makes when finding events to display: think of this as a filter that users ''can't'' change.

Both of these filter methods use the calendar's interface to restrict what shows up: users could still navigate to another of your layouts and search for events, possibly finding events that belong to other users. If that is not acceptable you'd use FileMaker's built in Access Privileges to restrict what a user can see. This "Access Privileges technique" uses features built into FileMaker and is not specific to DayBack.
Changed lines 17-18 from:
The simplest way to restrict what shows up in the calendar is to employ our filters, perhaps pre-filtering the calendar when users launch it. You can learn more about pre-filtering the calendar here: [[Filters]].
to:
-> The simplest way to restrict what shows up in the calendar is to pre-filter the calendar when users launch it. You can learn more about pre-filtering here: [[Filters]].
Changed lines 21-24 from:
Another approach is to intercept the SQL request the calendar performs when looking for records. This is what we think of as a hidden filter. To do this edit the script "Build Filter ( SourceNo )" and locate the comment "Hard code a filter here" toward the beginning of the script. The next set variable script step can be used to insert a SQL where clause that will always run: look at the comments in that SetVariable calc for more info.

Remember, you probably only want this to run for some users, so either include that "userness" in your where clause or use case statements to make a different where clause for each account name
.
to:
-> Another approach is to intercept the find request the calendar performs when looking for records. This is what we think of as a hidden filter. To do this edit the script "Event Find" and locate the comment "Hard code any 'hidden' filters here" toward the middle of the script. The following If () statements show you how to add find criteria specific to each of your [[multiple sources | sources]]. Set fields here following the If or Else If branch for your source, reading the script comments for guidance.

-> Remember, you probably only want this to run for some users, so either include that "userness" in your set field steps or use Case() statements to make a different find request for each account or privilege set
.
Changed lines 29-30 from:
This is very easly done; you�ll use FileMaker�s built in Access Privileges to create rules as to which records a logged in user can see, which they can edit etc. You can restrict which layouts they can see and even which specific fields they have access to.
to:
This is very easily done; you�ll use FileMaker�s built in Access Privileges to create rules as to which records a logged in user can see, which they can edit etc. You can restrict which layouts they can see and even which specific fields they have access to.
Deleted line 53:
August 05, 2012, at 09:49 PM by 50.132.84.245 -
Changed lines 41-52 from:
1. You can make the user�s Account Name match a field already in the database. So you could make sure all your accounts are created with the Account Names being real first and last names of your users. Account names would be things like �Bill Smith�. If you did that, an access privilege calc that would let the logged in user only see their appointments would look like this:

Not isempty ( FilterValues ( List ( SampleEvents::UserNameFirstLastCalc ) ; Get ( AccountName ) ) )

Make sure this calc is set to evaluate from the context of the same table occurrence used for your Source No 1 layout. So there are a couple things to note about this calc. The first is that it just returns a 1 or 0; a 1 if the Account Name is one of the names of the users linked to the appointment, a 0 if it is not. That is how all your access privileges calcs should be written: to return a 1 (ie. be true) if the user can see, edit, etc. the record. The second thing to note is that we don�t use the = sign. This is because an appointment can have more than one user, so its user will never be �equal� to any one user. Instead we use FilterValues to see if the Account Name �is a member� of the users on the appointment.

2. The second approach is to create your own field in a users table to match the account name; you�d essentially be recording the account name in FileMaker. Do not, of course, record the user�s password in FileMaker as that would not be very secure.

Note that if your user name is not indexed in the events table this calc can really slow the solution down as FileMaker looks at some related information for each event it is trying to display.

Now of course you may want to have some users that can see everyone�s appointments: you don�t have to mess with the calc above to do this, simply assign these �power users� to a different privilege set that doesn�t limit the appointments they can view at all.
to:
-> '''1.''' You can make the user�s Account Name match a field already in the database. So you could make sure all your accounts are created with the Account Names being real first and last names of your users. Account names would be things like �Bill Smith�. If you did that, an access privilege calc that would let the logged in user only see their appointments would look like this:

-> Not isempty ( FilterValues ( List ( SampleEvents::UserNameFirstLastCalc ) ; Get ( AccountName ) ) )

-> Make sure this calc is set to evaluate from the context of the same table occurrence used for your Source No 1 layout. So there are a couple things to note about this calc. The first is that it just returns a 1 or 0; a 1 if the Account Name is one of the names of the users linked to the appointment, a 0 if it is not. That is how all your access privileges calcs should be written: to return a 1 (ie. be true) if the user can see, edit, etc. the record. The second thing to note is that we don�t use the = sign. This is because an appointment can have more than one user, so its user will never be �equal� to any one user. Instead we use FilterValues to see if the Account Name �is a member� of the users on the appointment.

-> '''2.''' The second approach is to create your own field in a users table to match the account name; you�d essentially be recording the account name in FileMaker. Do not, of course, record the user�s password in FileMaker as that would not be very secure.

-> Note that if your user name is not indexed in the events table this calc can really slow the solution down as FileMaker looks at some related information for each event it is trying to display.

-> Now of course you may want to have some users that can see everyone�s appointments: you don�t have to mess with the calc above to do this, simply assign these �power users� to a different privilege set that doesn�t limit the appointments they can view at all.

-> ''This second approach is already built into %newwin% [[https://www.seedcode.com/complete | SeedCode Complete]].''

August 05, 2012, at 09:47 PM by 50.132.84.245 -
Changed lines 9-10 from:
You can also filter the calendar by intercepting the SQL request our calendar makes when finding events to display: think of this as a filter the users can't change.
to:
You can also hard-code a filter into the calendar by intercepting the SQL request our calendar makes when finding events to display: think of this as a filter the users can't change.
May 22, 2012, at 12:24 AM by 50.132.84.245 -
Changed lines 9-10 from:
You can also filter the calendar by intercepting the find request our calendar makes when finding events to display: think of this as a filter the users can't change.
to:
You can also filter the calendar by intercepting the SQL request our calendar makes when finding events to display: think of this as a filter the users can't change. 
Changed lines 21-28 from:
Another approach is to intercept the find the calendar performs when looking for records. This is what we think of as a hidden filter. To do this edit the script "Write FileMaker Source to Variable" and locate the comment "Nothing Found?". Right before this comment insert your own find request and run it as a "constrain found set", like this:

-> Enter Find Mode []
-> Set Field [SampleEvents::Event User; Get ( AccountName )]
-> Constrain Found Set []

This will restrict events displayed to those where a field "Event User" in your table matches the account name of the currently logged in user. You can obviously change this to look for other criteria, or to only restrict events when users from certain privilege sets are logged in
.
to:
Another approach is to intercept the SQL request the calendar performs when looking for records. This is what we think of as a hidden filter. To do this edit the script "Build Filter ( SourceNo )" and locate the comment "Hard code a filter here" toward the beginning of the script. The next set variable script step can be used to insert a SQL where clause that will always run: look at the comments in that SetVariable calc for more info.

Remember, you probably only want this to run for some users, so either include that "userness" in your where clause or use case statements to make a different where clause for each account name
.
Changed lines 29-30 from:
This is very easly done; you�ll use FileMaker�s built in Access Privileges to create rules as who which records a logged in user can see, which they can edit etc. You can restrict which layouts they can see and even which specific fields they have access to.
to:
This is very easly done; you�ll use FileMaker�s built in Access Privileges to create rules as to which records a logged in user can see, which they can edit etc. You can restrict which layouts they can see and even which specific fields they have access to.
Changed lines 37-38 from:
The only tricky part here is finding some attribute of the user�s log in to tie that login to a record in the calendar�s User table. The items you have at your disposal are Get ( AccountName ) and Get ( PrivilegeSetName ). The privilege set name is probably going to be used for general things like �administrator� or �sales rep� and may be used in FileMaker�s Access Privileges  to limit what a user can see or edit. You may, for example, craft access privileges so that sales reps can�t access the admin tabs on the calendar.
to:
The only tricky part here is finding some attribute of the user�s login to tie that login to a record in the calendar�s events table. The items you have at your disposal are Get ( AccountName ) and Get ( PrivilegeSetName ). The privilege set name is probably going to be used for general things like �administrator� or �sales rep� and may be used in FileMaker�s Access Privileges  to limit what a user can see or edit. You may, for example, craft access privileges so that sales reps can�t access the admin tabs on the calendar.
March 05, 2010, at 04:40 PM by 76.22.123.157 -
Changed lines 15-20 from:
'''Overview.'''

'''Read More.'''

You can learn more about pre-filtering the calendar here: [[Filters]]
.
to:
'''Pre-Filtering.'''

The simplest way to restrict what shows up in the calendar is to employ our filters, perhaps pre-filtering the calendar when users launch it. You can learn more about pre-filtering the calendar here: [[Filters]].

'''Hard-Coding a hidden filter.'''

March 05, 2010, at 04:37 PM by 76.22.123.157 -
Added lines 1-56:
!!How Do I Let a User See Only Their Own Records?

'''Overview.'''

You can easily restrict the events a user is able to see. There are two different approaches to doing this, using Filters and using Access Privileges.

Using Filters is the simplest: you can create a new filter for the event's "owner" and then pre-filter the calendar so only events for that owner show up. If this is all you do, however, users will be able to reset the filter to see other events, which may be a good thing.

You can also filter the calendar by intercepting the find request our calendar makes when finding events to display: think of this as a filter the users can't change.

Both of these filter methods use the calendar's interface to restrict what shows up: users could still navigate to the event list and search for events, possibly finding events that belong to other users. If that is not acceptable you'd use FileMaker's built in Access Privileges to restrict what a user can see. This technique uses features built into FileMaker and is not specific to our calendar.

! Using Filters

'''Overview.'''

'''Read More.'''

You can learn more about pre-filtering the calendar here: [[Filters]].

Another approach is to intercept the find the calendar performs when looking for records. This is what we think of as a hidden filter. To do this edit the script "Write FileMaker Source to Variable" and locate the comment "Nothing Found?". Right before this comment insert your own find request and run it as a "constrain found set", like this:

-> Enter Find Mode []
-> Set Field [SampleEvents::Event User; Get ( AccountName )]
-> Constrain Found Set []

This will restrict events displayed to those where a field "Event User" in your table matches the account name of the currently logged in user. You can obviously change this to look for other criteria, or to only restrict events when users from certain privilege sets are logged in.

! Using Access Privileges

'''Overview.'''

This is very easly done; you�ll use FileMaker�s built in Access Privileges to create rules as who which records a logged in user can see, which they can edit etc. You can restrict which layouts they can see and even which specific fields they have access to.

If you haven�t worked with FileMaker�s Access Privileges before, take a moment and read the overview in FileMaker's built in help, check out Contents > Protecting databases with accounts and privilege sets > Creating and managing privilege sets > Editing record access privileges.

For more information about limiting which records a user can see, continue to the "Editing record access privileges" page: you're interested in the "Limited" option under number 4.

'''Tips & Tricks.'''

The only tricky part here is finding some attribute of the user�s log in to tie that login to a record in the calendar�s User table. The items you have at your disposal are Get ( AccountName ) and Get ( PrivilegeSetName ). The privilege set name is probably going to be used for general things like �administrator� or �sales rep� and may be used in FileMaker�s Access Privileges  to limit what a user can see or edit. You may, for example, craft access privileges so that sales reps can�t access the admin tabs on the calendar.

So you�ll probably be using Get ( AccountName ) in your access privilege calculations to compare a logged in user with the user linked to an appointment. There are two basic approaches here:

1. You can make the user�s Account Name match a field already in the database. So you could make sure all your accounts are created with the Account Names being real first and last names of your users. Account names would be things like �Bill Smith�. If you did that, an access privilege calc that would let the logged in user only see their appointments would look like this:

Not isempty ( FilterValues ( List ( SampleEvents::UserNameFirstLastCalc ) ; Get ( AccountName ) ) )

Make sure this calc is set to evaluate from the context of the same table occurrence used for your Source No 1 layout. So there are a couple things to note about this calc. The first is that it just returns a 1 or 0; a 1 if the Account Name is one of the names of the users linked to the appointment, a 0 if it is not. That is how all your access privileges calcs should be written: to return a 1 (ie. be true) if the user can see, edit, etc. the record. The second thing to note is that we don�t use the = sign. This is because an appointment can have more than one user, so its user will never be �equal� to any one user. Instead we use FilterValues to see if the Account Name �is a member� of the users on the appointment.

2. The second approach is to create your own field in a users table to match the account name; you�d essentially be recording the account name in FileMaker. Do not, of course, record the user�s password in FileMaker as that would not be very secure.

Note that if your user name is not indexed in the events table this calc can really slow the solution down as FileMaker looks at some related information for each event it is trying to display.

Now of course you may want to have some users that can see everyone�s appointments: you don�t have to mess with the calc above to do this, simply assign these �power users� to a different privilege set that doesn�t limit the appointments they can view at all.

(855) SEEDCODE
support@seedcode.com
Follow us: