Security
SeedCodeComplete2.Security History
Hide minor edits - Show changes to output
Changed lines 5-6 from:
You’ll want to set up at least some basic security for the calendar. Remember that all 3 files in this solution need to have the same accounts and passwords, so as you edit those in one file, be sure to make those edits in all three files. Here are a few places to start:
to:
You’ll want to set up at least some basic security for the calendar. Remember that all three files in this solution (SeedCodeComplete.fp7, SeedCodeData.fp7 and SeedCodeMedia.fp7) need to have the same accounts and passwords, so as you edit those in one file, be sure to make those edits in all three files. Here are a few places to start:
Changed lines 3-4 from:
to:
SeedCode Complete is distributed without any security in place; there are no accounts or passwords set up whatsoever.
Changed lines 1-2 from:
!! How Do I Secure SeedCode Complete ?
to:
!! How Do I Secure SeedCode Complete?
Changed lines 11-12 from:
c) Learn more about restricting [[OnlySeeMyEvents | who can see what]].
to:
c) You'll likely want to prevent most users from getting to the Settings layout.
d) Learn more about restricting [[OnlySeeMyEvents | who can see what]].
d) Learn more about restricting [[OnlySeeMyEvents | who can see what]].
Added lines 11-12:
c) Learn more about restricting [[OnlySeeMyEvents | who can see what]].
Changed lines 9-19 from:
b) Users should also be prevented from accidentially deleting or creating new records in the Calendar Interface. An easy way to accomplish this is to use Custom Menus to remap the New Record and Delete Record commands, pointing them to a simple script like this (delete record is an example)
-> If [ Left ( Get ( LayoutTableName ) ; 8 ) = "Calendar" ]
--> Beep Show Custom Dialog [ Title: "Delete Record: Error"; Message: "You can't deleterecords this way: you're attempting to delete an interface record: click on an appointment directly to delete it.";
--> Buttons: “OK” ]
-> Else
--> Set Error Capture [ On ]
--> Delete Record/Request
-> End If
If records are created or deleted accidentally closing and reopening the calendar will check to see if these interface records have been created or deleted and the calendar will automatically correct itself.
-> If [ Left ( Get ( LayoutTableName ) ; 8 ) = "Calendar" ]
--> Beep Show Custom Dialog [ Title: "Delete Record: Error"; Message: "You can't delete
--> Buttons: “OK” ]
-> Else
--> Set Error Capture [ On ]
--> Delete Record/Request
-> End If
If records are created or deleted accidentally closing and reopening the calendar
to:
b) A few aspects of the solution can also take advantage of the fact that your users may be logging in with different account names: in this way you can, for example, restrict [[active projects]] to those projects for the logged in user. If you do create unique accounts for each user, enter their account names into their [[staff]] records.
Note that we have some custom menus in place to prevent you from accidentally creating or deleting calendar interface records. However, if interface records are created or deleted accidentally, then closing and reopening the solution will check to see if these interface records have been created or deleted and the calendar will automatically correct itself.
Note that we have some custom menus in place to prevent you from accidentally creating or deleting calendar interface records. However, if interface records are created or deleted accidentally, then closing and reopening the solution will check to see if these interface records have been created or deleted and the calendar will automatically correct itself.
Changed lines 1-8 from:
!! How Do I Secure SeedCodeCalendar ?
SeedCodeCalendar is distributed without any security in place; there are no accounts or passwords set up whatsoever. You’lllikely want to add some security to your copy as you deploy it. If you have an existing FileMaker solution to which you’re adding the calendar, you've likely already secured your events table: we have some notes about this when we talk about getting [[YourFile | ready to integrate]].
If you don’t have an existing security solution in place, you’ll want to set up at least some basic security for the calendar:
a) You’ll want to prevent you users from modifyingthe schema (field definitions, scripts, and layouts) of the calendar. Even if you allow schema modifications to the data tables like events, you’ll want to prevent such changes to the CalendarInterface and CalendarRows table where most of the interface work of the calendar takes place. You want users to be able to change the data here, but not the field definitions, scripts, and layouts.
SeedCodeCalendar is distributed without any security in place; there are no accounts or passwords set up whatsoever. You’ll
If you don’t have an existing security solution in place, you’ll want to set up at least some basic security for
a) You’ll want to prevent you users from modifying
to:
!! How Do I Secure SeedCode Complete ?
SeedCodeCalendar is distributed without any security in place; there are no accounts or passwords set up whatsoever.
You’ll want to set up at least some basic security for the calendar. Remember that all 3 files in this solution need to have the same accounts and passwords, so as you edit those in one file, be sure to make those edits in all three files. Here are a few places to start:
a) You’ll want to prevent you users from modifying the schema (field definitions, scripts, and layouts) of the solution. Even if you allow schema modifications in the data file, you’ll want to prevent such changes to the interface file (SeedCodeComplete.fp7) where most of the interface work of the calendar takes place.
SeedCodeCalendar is distributed without any security in place; there are no accounts or passwords set up whatsoever.
You’ll want to set up at least some basic security for the calendar. Remember that all 3 files in this solution need to have the same accounts and passwords, so as you edit those in one file, be sure to make those edits in all three files. Here are a few places to start:
a) You’ll want to prevent you users from modifying the schema (field definitions, scripts, and layouts) of the solution. Even if you allow schema modifications in the data file, you’ll want to prevent such changes to the interface file (SeedCodeComplete.fp7) where most of the interface work of the calendar takes place.
Added lines 1-19:
!! How Do I Secure SeedCodeCalendar ?
SeedCodeCalendar is distributed without any security in place; there are no accounts or passwords set up whatsoever. You’ll likely want to add some security to your copy as you deploy it. If you have an existing FileMaker solution to which you’re adding the calendar, you've likely already secured your events table: we have some notes about this when we talk about getting [[YourFile | ready to integrate]].
If you don’t have an existing security solution in place, you’ll want to set up at least some basic security for the calendar:
a) You’ll want to prevent you users from modifying the schema (field definitions, scripts, and layouts) of the calendar. Even if you allow schema modifications to the data tables like events, you’ll want to prevent such changes to the CalendarInterface and CalendarRows table where most of the interface work of the calendar takes place. You want users to be able to change the data here, but not the field definitions, scripts, and layouts.
b) Users should also be prevented from accidentially deleting or creating new records in the Calendar Interface. An easy way to accomplish this is to use Custom Menus to remap the New Record and Delete Record commands, pointing them to a simple script like this (delete record is an example)
-> If [ Left ( Get ( LayoutTableName ) ; 8 ) = "Calendar" ]
--> Beep Show Custom Dialog [ Title: "Delete Record: Error"; Message: "You can't delete records this way: you're attempting to delete an interface record: click on an appointment directly to delete it.";
--> Buttons: “OK” ]
-> Else
--> Set Error Capture [ On ]
--> Delete Record/Request
-> End If
If records are created or deleted accidentally closing and reopening the calendar will check to see if these interface records have been created or deleted and the calendar will automatically correct itself.
SeedCodeCalendar is distributed without any security in place; there are no accounts or passwords set up whatsoever. You’ll likely want to add some security to your copy as you deploy it. If you have an existing FileMaker solution to which you’re adding the calendar, you've likely already secured your events table: we have some notes about this when we talk about getting [[YourFile | ready to integrate]].
If you don’t have an existing security solution in place, you’ll want to set up at least some basic security for the calendar:
a) You’ll want to prevent you users from modifying the schema (field definitions, scripts, and layouts) of the calendar. Even if you allow schema modifications to the data tables like events, you’ll want to prevent such changes to the CalendarInterface and CalendarRows table where most of the interface work of the calendar takes place. You want users to be able to change the data here, but not the field definitions, scripts, and layouts.
b) Users should also be prevented from accidentially deleting or creating new records in the Calendar Interface. An easy way to accomplish this is to use Custom Menus to remap the New Record and Delete Record commands, pointing them to a simple script like this (delete record is an example)
-> If [ Left ( Get ( LayoutTableName ) ; 8 ) = "Calendar" ]
--> Beep Show Custom Dialog [ Title: "Delete Record: Error"; Message: "You can't delete records this way: you're attempting to delete an interface record: click on an appointment directly to delete it.";
--> Buttons: “OK” ]
-> Else
--> Set Error Capture [ On ]
--> Delete Record/Request
-> End If
If records are created or deleted accidentally closing and reopening the calendar will check to see if these interface records have been created or deleted and the calendar will automatically correct itself.
