Read Only
DayBackForFileMaker.ReadOnly History
Hide minor edits - Show changes to output
Changed lines 27-31 from:
DayBack will respect any %newwin% [[https://help.filemaker.com/app/answers/detail/a_id/7161 | record-level-access]] restrictions you put in place in your FileMaker tables, and these can make some records read only (for certain users) while leaving others editable. However, this read-only status won't be reflected in the calendar's interface. So a user would be able to start dragging and event to a new day, for example, only to see a dialog come up letting them know they don't have rights to edit the event. In summary, record-level-access can be used to prevent users from editing some events, but those events will still look like they are editable until the user tries to save their changes.
to:
DayBack will respect any %newwin% [[https://help.filemaker.com/app/answers/detail/a_id/7161 | record-level-access]] restrictions you put in place in your FileMaker tables, and these can make some records read only (for certain users) while leaving others editable. However, this read-only status won't be reflected in the calendar's interface. So a user would be able to start dragging and event to a new day, for example, only to see a dialog come up letting them know they don't have rights to edit the event. In summary, record-level-access can be used to prevent users from editing some events, but those events will still look like they are editable until the user tries to save their changes.
!! Sharing read-only calendars
You can also share your calendar (or a filtered subset of your calendar) online with folks who don't have access to your FileMaker solution. More details here: [[sharing]].
!! Sharing read-only calendars
You can also share your calendar (or a filtered subset of your calendar) online with folks who don't have access to your FileMaker solution. More details here: [[sharing]].
Changed line 27 from:
DayBack will respect any record-level-access restrictions you put in place in your FileMaker tables, and these can make some records read only (for certain users) while leaving others editable. However, this read-only status won't be reflected in the calendar's interface. So a user would be able to start dragging and event to a new day, for example, only to see a dialog come up letting them know they don't have rights to edit the event. In summary, record-level-access can be used to prevent users from editing some events, but those events will still look like they are editable until the user tries to save their changes.
to:
DayBack will respect any %newwin% [[https://help.filemaker.com/app/answers/detail/a_id/7161 | record-level-access]] restrictions you put in place in your FileMaker tables, and these can make some records read only (for certain users) while leaving others editable. However, this read-only status won't be reflected in the calendar's interface. So a user would be able to start dragging and event to a new day, for example, only to see a dialog come up letting them know they don't have rights to edit the event. In summary, record-level-access can be used to prevent users from editing some events, but those events will still look like they are editable until the user tries to save their changes.
Changed lines 23-27 from:
--> if ( get (CurrentPrivilegeSetName)= "Sales" ; True ; False )
to:
--> if ( get (CurrentPrivilegeSetName)= "Sales" ; True ; False )
!! Can individual events be made read only?
DayBack will respect any record-level-access restrictions you put in place in your FileMaker tables, and these can make some records read only (for certain users) while leaving others editable. However, this read-only status won't be reflected in the calendar's interface. So a user would be able to start dragging and event to a new day, for example, only to see a dialog come up letting them know they don't have rights to edit the event. In summary, record-level-access can be used to prevent users from editing some events, but those events will still look like they are editable until the user tries to save their changes.
!! Can individual events be made read only?
DayBack will respect any record-level-access restrictions you put in place in your FileMaker tables, and these can make some records read only (for certain users) while leaving others editable. However, this read-only status won't be reflected in the calendar's interface. So a user would be able to start dragging and event to a new day, for example, only to see a dialog come up letting them know they don't have rights to edit the event. In summary, record-level-access can be used to prevent users from editing some events, but those events will still look like they are editable until the user tries to save their changes.
Changed line 1 from:
!! Can I make the WebDirect Calendar completely read-only.
to:
!! Can I make the Calendar completely read-only.
Changed lines 13-16 from:
There is a section in this script for each source (each calendar) you're working with. Find this comment...
to:
-> '''1.''' Edit the script "Load Source Settings at Startup --- Describe Your Sources Here ---"
-> '''2.''' There is a section in this script for each source (each calendar) you're working with. Find this comment...
-> '''2.''' There is a section in this script for each source (each calendar) you're working with. Find this comment...
Changed lines 19-21 from:
...and set the next line (the SetVariable line) to True.
That's how you make it read only. To make it read only for only some users, wrap "True" in an If() statement that tests for the kind of use who has read only access. For example, if you have a privilege set called "Sales" that shouldn't be able to edit this calendar, replace True with this:
That's how you make it read only. To make it read only for only some users, wrap "True" in an If() statement that tests for the kind of use who has read only access. For example, if you have a privilege set called "Sales" that shouldn't be able to edit this calendar, replace True with this:
to:
-> ...and set the next line (the SetVariable line) to True.
-> '''3.''' That's how you make it read only. To make it read only for only some users, wrap "True" in an If() statement that tests for the kind of use who has read only access. For example, if you have a privilege set called "Sales" that shouldn't be able to edit this calendar, replace True with this:
-> '''3.''' That's how you make it read only. To make it read only for only some users, wrap "True" in an If() statement that tests for the kind of use who has read only access. For example, if you have a privilege set called "Sales" that shouldn't be able to edit this calendar, replace True with this:
Added lines 10-23:
Here's how:
Edit the script "Load Source Settings at Startup --- Describe Your Sources Here ---"
There is a section in this script for each source (each calendar) you're working with. Find this comment...
--> "Read only - If set to true this source cannot be edited in the calendar"
...and set the next line (the SetVariable line) to True.
That's how you make it read only. To make it read only for only some users, wrap "True" in an If() statement that tests for the kind of use who has read only access. For example, if you have a privilege set called "Sales" that shouldn't be able to edit this calendar, replace True with this:
--> if ( get (CurrentPrivilegeSetName)= "Sales" ; True ; False )
Changed line 7 from:
to:
{-We should be releasing an in-app update after DevCon that lets you reflect read-only access in the interface (disabling drag, hiding the delete buttons etc.)-}
Changed lines 7-9 from:
(-We should be releasing an in-app update after DevCon that lets you reflect read-only access in the interface (disabling drag, hiding the delete buttons etc.)-) Read-only calendars were introduced via an [[InAppUpdates | in-app update]] in [[Version History | version]] 9.71: now your startup script can set any given calendar [[Multiple Sources | source]] as read-only, meaning that you can do this conditionally based on the logged in user.
to:
(-We should be releasing an in-app update after DevCon that lets you reflect read-only access in the interface (disabling drag, hiding the delete buttons etc.-)
Read-only calendars were introduced via an [[InAppUpdates | in-app update]] in [[Version History | version]] 9.71: now your startup script can set any given calendar [[Multiple Sources | source]] as read-only, meaning that you can do this conditionally based on the logged in user.
Read-only calendars were introduced via an [[InAppUpdates | in-app update]] in [[Version History | version]] 9.71: now your startup script can set any given calendar [[Multiple Sources | source]] as read-only, meaning that you can do this conditionally based on the logged in user.
Changed lines 7-9 from:
We should be releasing an in-app update after DevCon that lets you reflect read-only access in the interface (disabling drag, hiding the delete buttons etc.)
Stay tuned.
Stay tuned
to:
(-We should be releasing an in-app update after DevCon that lets you reflect read-only access in the interface (disabling drag, hiding the delete buttons etc.)-) Read-only calendars were introduced via an [[InAppUpdates | in-app update]] in [[Version History | version]] 9.71: now your startup script can set any given calendar [[Multiple Sources | source]] as read-only, meaning that you can do this conditionally based on the logged in user.
Changed lines 5-17 from:
Obviously you can do this with access privileges so that users can't edit the events table if the log in with a generic account (or open the file without logging in). That's functionally locked down, but it may be frustrating for users without making a few changes to smooth things out. I'd also make the following (simple) changes:
-> In Access Privileges, allow editing of all tables besides the events (and ToDo list, if you use that).
-> Pull (or conditionally hide) the "+" button from the WebDirect layouts so users don't try to create new events.
-> Edit the event popovers and pull all the buttons from the bottom besides "cancel". Rename that one "close"
-> Make all the fields on the event popover unenterable and pull the up/down buttons next to the event time.
When combined with access privileges, these changes will not only prevent users from editing events in WebDirect, it will stop them from thinking events *can* be edited.
Some tips for editing those popovers can be found [[ EventPopovers | here]].
-> In Access Privileges, allow editing of all tables besides the events (and ToDo list, if you use that).
-> Pull (or conditionally hide)
-> Edit the event popovers and pull all the buttons from the bottom besides "cancel". Rename that one "close"
-> Make all the fields on the event popover unenterable and pull the up/down buttons next to the event time.
When combined with access privileges, these changes will not only prevent users from editing events in WebDirect, it will stop them from thinking events *can* be edited.
Some tips for editing those popovers can be found [[ EventPopovers | here]].
to:
Obviously you can do this with access privileges so that users can't edit the events table if they log in with a generic account (or open the file without logging in). While that locks down your data, that change won't be reflected in DayBack's interface: users will still be able to begin creating and editing events, those actions just won't complete.
We should be releasing an in-app update after DevCon that lets you reflect read-only access in the interface (disabling drag, hiding the delete buttons etc.)
Stay tuned.
We should be releasing an in-app update after DevCon that lets you reflect read-only access in the interface (disabling drag, hiding the delete buttons etc.)
Stay tuned.
Changed line 17 from:
Some tips for editing those popovers can be found [[ .EventPopovers | here]].
to:
Some tips for editing those popovers can be found [[ EventPopovers | here]].
Added lines 1-17:
!! Can I make the WebDirect Calendar completely read-only.
Yes.
Obviously you can do this with access privileges so that users can't edit the events table if the log in with a generic account (or open the file without logging in). That's functionally locked down, but it may be frustrating for users without making a few changes to smooth things out. I'd also make the following (simple) changes:
-> In Access Privileges, allow editing of all tables besides the events (and ToDo list, if you use that).
-> Pull (or conditionally hide) the "+" button from the WebDirect layouts so users don't try to create new events.
-> Edit the event popovers and pull all the buttons from the bottom besides "cancel". Rename that one "close"
-> Make all the fields on the event popover unenterable and pull the up/down buttons next to the event time.
When combined with access privileges, these changes will not only prevent users from editing events in WebDirect, it will stop them from thinking events *can* be edited.
Some tips for editing those popovers can be found [[ .EventPopovers | here]].
Yes.
Obviously you can do this with access privileges so that users can't edit the events table if the log in with a generic account (or open the file without logging in). That's functionally locked down, but it may be frustrating for users without making a few changes to smooth things out. I'd also make the following (simple) changes:
-> In Access Privileges, allow editing of all tables besides the events (and ToDo list, if you use that).
-> Pull (or conditionally hide) the "+" button from the WebDirect layouts so users don't try to create new events.
-> Edit the event popovers and pull all the buttons from the bottom besides "cancel". Rename that one "close"
-> Make all the fields on the event popover unenterable and pull the up/down buttons next to the event time.
When combined with access privileges, these changes will not only prevent users from editing events in WebDirect, it will stop them from thinking events *can* be edited.
Some tips for editing those popovers can be found [[ .EventPopovers | here]].