Security
SeedCodeCalendarFree.Security History
Hide minor edits - Show changes to output
Changed lines 11-12 from:
-> 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."; \\
to:
-> 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.";
--> 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.";
Changed lines 11-16 from:
--> 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” ]
Set Error Capture [ On ]
Delete Record/Request End If
Set Error Capture [ On ]
Delete Record/Request
to:
-> 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
--> 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
Changed lines 11-12 from:
>> example script
to:
--> 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” ]
Set Error Capture [ On ]
Delete Record/Request End If
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” ]
Set Error Capture [ On ]
Delete Record/Request End If
Changed lines 13-15 from:
If records are created or deleted accidentally you can use the [[reset]] script in SeedCodeCalendar to restore the original records. This script is set to run with “full access privileges” so you’re security settings won’t get in the way of it. No other scripts in the calendar are set to run with “full access privileges,” so if you really lock down the calendar you may want to add this option to some of the calendar scripts.
to:
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.
Changed lines 3-10 from:
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, the security of the calendar will need to be modified to fit in seamlessly with your existing security system. This means creating the same privilege sets and accounts in SeedCodeCalendar as you have in your existing solution.
If you don’t have an existing security solution to move into SeedCodeCalendar, 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 appointments, you’ll want to prevent such changes to the Calendar table where most of the interface work of the calendar takes place.
b) Users should also be prevented from deleting or creating new records in the Calendartable. The six [[interface]] records there are used to display the month view of the calendar; if one is deleted or an extra record is created, the calendar will no longer display properly. Preventing the accidental creation or deletion of records in the Calendar table will prevent these problems. An easy way to accomplish this is to create a new privilege set for your users and change the menu access for this privilege set to “Editing Only”. This will remove the “Delete Records” command (along with other pesky items) from the menu and force users to use your scripts to delete records.
If you don’t have an existing security solution to move into SeedCodeCalendar, you’ll want to set up at least some basic security for
a) You’ll want to prevent you users from modifying
b) Users should also be prevented from deleting or creating new records in the Calendar
to:
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)
>> example script
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)
>> example script
Changed lines 15-16 from:
to:
Added lines 1-14:
!! 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, the security of the calendar will need to be modified to fit in seamlessly with your existing security system. This means creating the same privilege sets and accounts in SeedCodeCalendar as you have in your existing solution.
If you don’t have an existing security solution to move into SeedCodeCalendar, 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 appointments, you’ll want to prevent such changes to the Calendar table where most of the interface work of the calendar takes place.
b) Users should also be prevented from deleting or creating new records in the Calendar table. The six [[interface]] records there are used to display the month view of the calendar; if one is deleted or an extra record is created, the calendar will no longer display properly. Preventing the accidental creation or deletion of records in the Calendar table will prevent these problems. An easy way to accomplish this is to create a new privilege set for your users and change the menu access for this privilege set to “Editing Only”. This will remove the “Delete Records” command (along with other pesky items) from the menu and force users to use your scripts to delete records.
If records are created or deleted accidentally you can use the [[reset]] script in SeedCodeCalendar to restore the original records. This script is set to run with “full access privileges” so you’re security settings won’t get in the way of it. No other scripts in the calendar are set to run with “full access privileges,” so if you really lock down the calendar you may want to add this option to some of the calendar scripts.
c) When you deploy the calendar be sure to remove the Show Status Area script from the Scripts menu. Also be sure to change the first line of the Adjust Window script to lock the status area when hiding it.
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, the security of the calendar will need to be modified to fit in seamlessly with your existing security system. This means creating the same privilege sets and accounts in SeedCodeCalendar as you have in your existing solution.
If you don’t have an existing security solution to move into SeedCodeCalendar, 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 appointments, you’ll want to prevent such changes to the Calendar table where most of the interface work of the calendar takes place.
b) Users should also be prevented from deleting or creating new records in the Calendar table. The six [[interface]] records there are used to display the month view of the calendar; if one is deleted or an extra record is created, the calendar will no longer display properly. Preventing the accidental creation or deletion of records in the Calendar table will prevent these problems. An easy way to accomplish this is to create a new privilege set for your users and change the menu access for this privilege set to “Editing Only”. This will remove the “Delete Records” command (along with other pesky items) from the menu and force users to use your scripts to delete records.
If records are created or deleted accidentally you can use the [[reset]] script in SeedCodeCalendar to restore the original records. This script is set to run with “full access privileges” so you’re security settings won’t get in the way of it. No other scripts in the calendar are set to run with “full access privileges,” so if you really lock down the calendar you may want to add this option to some of the calendar scripts.
c) When you deploy the calendar be sure to remove the Show Status Area script from the Scripts menu. Also be sure to change the first line of the Adjust Window script to lock the status area when hiding it.
