DayBackForFileMaker

Read Only

DayBackForFileMaker.ReadOnly History

Hide minor edits - Show changes to output

April 11, 2017, at 06:44 PM by 192.88.134.15 -
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]]
.
November 04, 2016, at 10:02 PM by 192.88.135.15 -
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.
November 04, 2016, at 09:59 PM by 192.88.135.15 -
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.
November 04, 2016, at 09:56 PM by 192.88.135.15 -
Changed line 1 from:
!! Can I make the WebDirect Calendar completely read-only.
to:
!! Can I make the Calendar completely read-only.
May 24, 2016, at 09:46 PM by 192.88.134.15 -
Changed lines 13-16 from:
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...
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...
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:
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:
May 24, 2016, at 09:45 PM by 192.88.134.15 -
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 )
May 01, 2016, at 03:31 PM by 192.88.134.15 -
Changed line 7 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.-)
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.)-}
May 01, 2016, at 03:31 PM by 192.88.134.15 -
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.
May 01, 2016, at 03:31 PM by 192.88.134.15 -
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
.
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.
June 29, 2015, at 04:58 PM by 142.4.217.187 -
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]].
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
.
June 29, 2015, at 04:53 PM by 142.4.217.187 -
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]].
June 03, 2014, at 03:54 PM by 50.132.85.96 -
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]].
(855) SEEDCODE
[email protected]
Follow us: