GoZync5

Checking Out Records

GoZync5.CheckingOutRecords History

Hide minor edits - Show changes to output

Changed line 17 from:
-> Watch this %newwin% [[http://www.youtube.com/watch?v=c-l_Rxp_wXQ |short video of checkout in action]], along with a walkthrough of how we do it.
to:
-> Watch this %newwin% [[http://www.seedcode.com/videos/?youtube=c-l_Rxp_wXQ |short video of checkout in action]], along with a walkthrough of how we do it.
June 22, 2014, at 01:50 PM by 50.132.85.96 -
Changed line 41 from:
-> '''Your Filter Criteria.''' In our example file (WorxDemo) you'll see that we mark a record with a status of "Scheduled" when it's ready to go down to the iPad and with "Checked Out" when it's been pulled. Our filter criteria in the script "Filter Records To Pull", however, pulls records of ''both'' statuses. The reason is that if you only pull "Scheduled" items, GoZync will consider those as the only ones that should be on the iPad... and will [[deletes| delete]] the ones marked Checked Out from your device. So it's best to think of the find requests as the criteria for the records that ''should be on your iPad'', not just the new ones you want to ''get to your iPad''.
to:
-> '''Your Filter Criteria.''' In our example file (WorxHosted) you'll see that we mark a record with a status of "Scheduled" when it's ready to go down to the iPad and with "Checked Out" when it's been pulled. Our filter criteria in the script "Filter Records To Pull", however, pulls records of ''both'' statuses. The reason is that if you only pull "Scheduled" items, GoZync will consider those as the only ones that should be on the iPad... and will [[deletes| delete]] the ones marked Checked Out from your device. So it's best to think of the find requests as the criteria for the records that ''should be on your iPad'', not just the new ones you want to ''get to your iPad''.
June 12, 2014, at 03:06 AM by 50.132.85.96 -
Changed line 41 from:
-> '''Your Filter Criteria.''' In our preview file (WorxDemo) you'll see that we mark a record with a status of "Scheduled" when it's ready to go down to the iPad and with "Checked Out" when it's been pulled. Our filter criteria in the script "Filter Records To Pull", however, pulls records of ''both'' statuses. The reason is that if you only pull "Scheduled" items, GoZync will consider those as the only ones that should be on the iPad... and will [[deletes| delete]] the ones marked Checked Out from your device. So it's best to think of the find requests as the criteria for the records that ''should be on your iPad'', not just the new ones you want to ''get to your iPad''.
to:
-> '''Your Filter Criteria.''' In our example file (WorxDemo) you'll see that we mark a record with a status of "Scheduled" when it's ready to go down to the iPad and with "Checked Out" when it's been pulled. Our filter criteria in the script "Filter Records To Pull", however, pulls records of ''both'' statuses. The reason is that if you only pull "Scheduled" items, GoZync will consider those as the only ones that should be on the iPad... and will [[deletes| delete]] the ones marked Checked Out from your device. So it's best to think of the find requests as the criteria for the records that ''should be on your iPad'', not just the new ones you want to ''get to your iPad''.
June 11, 2014, at 10:40 PM by 50.132.85.96 -
Changed line 37 from:
-> '''Last Zync Time''' If you're pulling records that are tagged as "scheduled" or "ready", for example, you want to sync based on that, ''regardless'' of last sync time. The script "Filter Records To Pull" has an option disregard this per table, those lines are disabled by default: you'll likely want to re-enable them when doing checkout.
to:
-> '''Last Zync Time''' If you're pulling records that are tagged as "scheduled" or "ready", for example, you want to sync based on that, ''regardless'' of last sync time. The script "Filter Records To Pull" has an option to disregard this per table, those lines are disabled by default: you'll likely want to re-enable them when doing checkout.
June 11, 2014, at 10:13 PM by 50.132.85.96 -
Changed lines 41-43 from:
-> '''Preventing edits of checked out records.''' In your hosted solution, use FileMaker's built-in access privileges to prevent editing of records where "checked out" is not empty (or zero). In relational solutions you'll want to apply this restriction to child records as well: one should not be able to edit an invoice line item if the invoice is checked out, for example.
to:
-> '''Your Filter Criteria.''' In our preview file (WorxDemo) you'll see that we mark a record with a status of "Scheduled" when it's ready to go down to the iPad and with "Checked Out" when it's been pulled. Our filter criteria in the script "Filter Records To Pull", however, pulls records of ''both'' statuses. The reason is that if you only pull "Scheduled" items, GoZync will consider those as the only ones that should be on the iPad... and will [[deletes| delete]] the ones marked Checked Out from your device. So it's best to think of the find requests as the criteria for the records that ''should be on your iPad'', not just the new ones you want to ''get to your iPad''.

-> '''Preventing Edits of Checked Out Records
.''' In your hosted solution, use FileMaker's built-in access privileges to prevent editing of records where "checked out" is not empty (or zero). In relational solutions you'll want to apply this restriction to child records as well: one should not be able to edit an invoice line item if the invoice is checked out, for example.
June 11, 2014, at 10:07 PM by 50.132.85.96 -
Changed line 39 from:
http://www.seedcode.com/rootimages/stikipad/gozync5/ifst2.png
to:
-> http://www.seedcode.com/rootimages/stikipad/gozync5/ifst2.png
June 11, 2014, at 10:07 PM by 50.132.85.96 -
Changed lines 23-24 from:
Getting this working in your solution is pretty simple. Reading up on [[downloading found sets]] will help give you some context for the changes that follow. You'll also use [[Custom Field Mapping]] to implement this, so read up on that as well (custom field mapping is one of the most powerful features of GoZync 4).
to:
Getting this working in your solution is pretty simple. Reading up on [[downloading found sets]] will help give you some context for the changes that follow. You'll also use [[Custom Field Mapping]] to implement this, so read up on that as well (custom field mapping is one of the most powerful features of GoZync).
Added lines 36-39:

-> '''Last Zync Time''' If you're pulling records that are tagged as "scheduled" or "ready", for example, you want to sync based on that, ''regardless'' of last sync time. The script "Filter Records To Pull" has an option disregard this per table, those lines are disabled by default: you'll likely want to re-enable them when doing checkout.

http://www.seedcode.com/rootimages/stikipad/gozync5/ifst2.png
June 10, 2014, at 09:45 PM by 50.132.85.96 -
Changed lines 1-4 from:
!! Can I "check out" records so only the mobile user can edit them?

Absolutely. In fact, this is one of the most useful workflows GoZync enables. ''Note that checkout is not supported in the free version of GoZync.''
to:
!! Can I mark records as "checked out" records so only the mobile user can edit them?

Absolutely. In fact, this is one of the most useful workflows GoZync enables. ''Note that checkout is not supported in the free version of GoZync, but it is in the [[DemoGoZync | GoZync Demo]].''
Changed lines 7-8 from:
-> When users pull records down from your hosted solution, the record is marked as "checked out". You can simply set a field called "out" to 1, or record something more elaborate, like the name of the user who downloaded it, and when they did so.
to:
-> When users pull records down from your hosted solution, the record is marked as "checked out". You can simply set a field called "out" to 1, or record something more elaborate, perhaps including the name of the user who downloaded it and when they did so.
Changed line 25 from:
-> '''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for Zyncing in GoZyncMobile as there won't be a matching field on the mobile side. Create a branch in the script "Custom Field Mapping: Transformation and Hooks" for your table-- you'll create a branch for both the push and the pull, that is for both "gzm_YourTable" and "gzh_YourTable".
to:
-> '''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for zyncing in GoZyncMobile.fmp12 as there won't be a matching field on the mobile side. Create a branch in the script "Custom Field Mapping: Transformation and Hooks" for your table-- you'll create a branch for both the push and the pull, that is for both "gzm_YourTable" and "gzh_YourTable".
March 28, 2014, at 09:10 PM by 50.132.84.245 -
Added lines 18-19:

-> Todd Geist also demonstrates checkout as part of his %newwin% [[https://www.geistinteractive.com/2014/03/26/filemaker-sync-3-gozync-features/ | "Three Favorite GoZync Features"]].
October 07, 2013, at 03:54 AM by 50.132.84.245 -
Changed line 15 from:
Checkout in Action.
to:
'''Checkout in Action.'''
October 07, 2013, at 03:54 AM by 50.132.84.245 -
Added lines 14-17:

Checkout in Action.

-> Watch this %newwin% [[http://www.youtube.com/watch?v=c-l_Rxp_wXQ |short video of checkout in action]], along with a walkthrough of how we do it.
July 01, 2013, at 12:56 AM by 166.147.88.40 -
Changed line 33 from:
That's it.
to:
That's all. Pretty cool, isn't it?
July 01, 2013, at 12:55 AM by 166.147.88.40 -
Changed lines 17-20 from:
Getting this working in your solution is pretty simple. Reading up on [[downloading found sets]] will help give you come context for the changes that follow. You'll also use [[Custom Field Mapping]] to implement this, so read up on that as well (custom field mapping is one of the most powerful features of GoZync).

-> '''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for Zyncing as there won't be a matching field on he mobile side. Create a branch in the script "Custom Field Mapping: Transformation and Hooks" for your table-- you'll create a branch for both the push and the pull, that is for both "gzm_YourTable" and "gzh_YourTable".
to:
Getting this working in your solution is pretty simple. Reading up on [[downloading found sets]] will help give you some context for the changes that follow. You'll also use [[Custom Field Mapping]] to implement this, so read up on that as well (custom field mapping is one of the most powerful features of GoZync 4).

-> '''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for Zyncing in GoZyncMobile as there won't be a matching field on the mobile side. Create a branch in the script "Custom Field Mapping: Transformation and Hooks" for your table-- you'll create a branch for both the push and the pull, that is for both "gzm_YourTable" and "gzh_YourTable".
Changed lines 25-26 from:
--> In the "push" branch--the one based on "gzm_YourTable"-- you'd the clear your checked out field or set it to a literal value like "0" like this:
to:
--> In the "push" branch--the one based on "gzm_YourTable"-- you'd then clear your checked out field or set it to a literal value like "0" like this:
Added lines 29-30:
-> Not that in both the push and the pull it is the ''hosted'' record we're editing when it comes to checkout. This may be a little different than other SetField() steps you have going on that script where on the pull you're often setting fields in mobile records.
July 01, 2013, at 12:52 AM by 166.147.88.40 -
Changed lines 11-14 from:
-> Then, access privileges in your solution prevent checked out records from being edited. This is great because users on the hosted solution (users "in the office") can edit records up until the moment a mobile user checks them out. Imagine: updating trouble ticket details up until the moment a mobile technician actually begins heading to the customer's location, but being prevented from changing it after that. Users would then know they need to call the mobile technician to communicate any new details about the ticket.

-> Once
the ticket is resolved and the mobile user syncs their updated ticket back to the hosted solution, the ticket is "checked back in" and is now editable again.
to:
-> You'd then enforce the checkout--and lock the record--by crafting access privileges in your hosted solution that prevent checked out records from being edited. This is great because users on the hosted solution (users "in the office") can edit records up until the moment a mobile user checks them out. Imagine: updating trouble ticket details up until the moment a mobile technician actually begins heading to the customer's location, but being prevented from changing it after that. Users in the office would then know they need to call the mobile technician to communicate any new details about the now checked out ticket.

-> Once
the ticket is resolved and the mobile user syncs their updated ticket back to the hosted solution, the ticket is "checked back in" and is now editable again by users in the office.
July 01, 2013, at 12:49 AM by 166.147.88.40 -
Changed lines 1-2 from:
!! Can I "check out" records so only the mobile own can edit them?
to:
!! Can I "check out" records so only the mobile user can edit them?
June 25, 2013, at 10:11 PM by 108.38.141.66 -
Changed lines 23-24 from:
--->SetField [ gzm_YourTable::checked_out ; 1 ]
to:
--->SetField [ gzh_YourTable::checked_out ; 1 ]
Changed lines 27-28 from:
--->SetField [ gzm_YourTable::checked_out ; 0 ]
to:
--->SetField [ gzh_YourTable::checked_out ; 0 ]
June 25, 2013, at 08:48 PM by 108.38.141.66 -
Changed lines 17-24 from:
Getting this working in your solution is pretty simple. Reading up on [[downloading found sets]] will help give you come context for the changes that follow.

->
'''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for Zyncing as there won't be a matching field on he mobile side. Edit the script "Edit Record being Pulled (TOName)" and create a branch (an If statement like the example there) which tests for the Table Occurrence name you're interested in. Then set the checked out field in that table.

-> '''Preventing edits of checked out records.
''' In your hosted solution, use FileMaker's built in access privileges to prevent editing of records where "checked out" is not empty. In relational solutions you'll want to apply this restriction to child records as well: one should not be able to edit an invoice line item if the invoice is checked out, for example.

-> '''Checking in.''' Edit the script "After Committing Entity" and you'll see branches similar to those in "Edit Record..." above. Create a branch for your table occurrence and set the "checked out" field to blank (use two quotes without a space between them).
to:
Getting this working in your solution is pretty simple. Reading up on [[downloading found sets]] will help give you come context for the changes that follow. You'll also use [[Custom Field Mapping]] to implement this, so read up on that as well (custom field mapping is one of the most powerful features of GoZync).

->
'''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for Zyncing as there won't be a matching field on he mobile side. Create a branch in the script "Custom Field Mapping: Transformation and Hooks" for your table-- you'll create a branch for both the push and the pull, that is for both "gzm_YourTable" and "gzh_YourTable".

-->
In the "pull" branch--the one based on "gzh_YourTable"-- set your checked out field to a literal value like "1" like this:

--->SetField [ gzm_YourTable::checked_out ; 1 ]

--> In
the "push" branch--the one based on "gzm_YourTable"-- you'd the clear your checked out field or set it to a literal value like "0" like this:

--->SetField [ gzm_YourTable::checked_out ; 0 ]

-> '''Preventing edits of checked out records.''' In your hosted solution,
use FileMaker's built-in access privileges to prevent editing of records where "checked out" is not empty (or zero). In relational solutions you'll want to apply this restriction to child records as well: one should not be able to edit an invoice line item if the invoice is checked out, for example.
December 17, 2012, at 10:17 PM by cm - minor edits and clarifications
Changed lines 9-12 from:
-> (Remember, users can [[downloading found sets | download just their own records]], so it's not like it would be a surprise who downloaded the record, but seeing the name can give you an extra sense of reassurance, and can remind staffers--who may not know all the business rules--who owns which records.)

-> Then, access privileges in your solution prevent checked out records from being edited. This is great because users on the hosted solution (users "in the office") can edit records up until the moment a mobile user checks them out: imagine, updating trouble ticket details up until the moment a mobile technician actually begins heading to the customer's location, but being prevented from changing it after that. Users would then know they need to call the mobile technician to communicate any new details about the ticket.
to:
-> (Remember, users can [[downloading found sets | download just their own records]], so it's not like it would be a surprise who downloaded the record, but seeing the name can give you an extra sense of reassurance, and can remind staffers – who may not know all the business rules – who owns which records.)

-> Then, access privileges in your solution prevent checked out records from being edited. This is great because users on the hosted solution (users "in the office") can edit records up until the moment a mobile user checks them out. Imagine: updating trouble ticket details up until the moment a mobile technician actually begins heading to the customer's location, but being prevented from changing it after that. Users would then know they need to call the mobile technician to communicate any new details about the ticket.
Changed lines 17-20 from:
Getting this working in your solution i s pretty simple. Reading up on [[downloading found sets]] will help give you come context for the changes that follow.

-> '''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for zyncing as there won't be a matching field on he mobile side.Edit the script "Edit Record being Pulled (TOName)" and create a branch (an If statement like the example there) which tests for the Table Occurrence name you're interested in: the set the checked out field in that table.
to:
Getting this working in your solution is pretty simple. Reading up on [[downloading found sets]] will help give you come context for the changes that follow.

-> '''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for Zyncing as there won't be a matching field on he mobile side. Edit the script "Edit Record being Pulled (TOName)" and create a branch (an If statement like the example there) which tests for the Table Occurrence name you're interested in. Then set the checked out field in that table.
July 05, 2012, at 02:24 AM by 50.132.84.245 -
Changed lines 19-24 from:
-> Checking out. Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for zyncing as there won't be a matching field on he mobile side.Edit the script "Edit Record being Pulled (TOName)" and create a branch (an If statement like the example there) which tests for the Table Occurrence name you're interested in: the set the checked out field in that table.

-> Preventing edits of checked out records. In your hosted solution, use FileMaker's built in access privileges to prevent editing of records where "checked out" is not empty. In relational solutions you'll want to apply this restriction to child records as well: one should not be able to edit an invoice line item if the invoice is checked out, for example.

-> Checking in. Edit the script "After Committing Entity" and you'll see branches similar to those in "Edit Record..." above. Create a branch for your table occurrence and set the "checked out" field to blank (use two quotes without a space between them).
to:
-> '''Checking out.''' Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for zyncing as there won't be a matching field on he mobile side.Edit the script "Edit Record being Pulled (TOName)" and create a branch (an If statement like the example there) which tests for the Table Occurrence name you're interested in: the set the checked out field in that table.

-> '''Preventing edits of checked out records.''' In your hosted solution, use FileMaker's built in access privileges to prevent editing of records where "checked out" is not empty. In relational solutions you'll want to apply this restriction to child records as well: one should not be able to edit an invoice line item if the invoice is checked out, for example.

-> '''Checking in.''' Edit the script "After Committing Entity" and you'll see branches similar to those in "Edit Record..." above. Create a branch for your table occurrence and set the "checked out" field to blank (use two quotes without a space between them).
July 05, 2012, at 02:24 AM by 50.132.84.245 -
Changed lines 3-25 from:
Yes. Coming soon.
to:
Absolutely. In fact, this is one of the most useful workflows GoZync enables. ''Note that checkout is not supported in the free version of GoZync.''

'''What checkout looks like.'''

-> When users pull records down from your hosted solution, the record is marked as "checked out". You can simply set a field called "out" to 1, or record something more elaborate, like the name of the user who downloaded it, and when they did so.

-> (Remember, users can [[downloading found sets | download just their own records]], so it's not like it would be a surprise who downloaded the record, but seeing the name can give you an extra sense of reassurance, and can remind staffers--who may not know all the business rules--who owns which records.)

-> Then, access privileges in your solution prevent checked out records from being edited. This is great because users on the hosted solution (users "in the office") can edit records up until the moment a mobile user checks them out: imagine, updating trouble ticket details up until the moment a mobile technician actually begins heading to the customer's location, but being prevented from changing it after that. Users would then know they need to call the mobile technician to communicate any new details about the ticket.

-> Once the ticket is resolved and the mobile user syncs their updated ticket back to the hosted solution, the ticket is "checked back in" and is now editable again.

'''How to implement it.'''

Getting this working in your solution i s pretty simple. Reading up on [[downloading found sets]] will help give you come context for the changes that follow.

-> Checking out. Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for zyncing as there won't be a matching field on he mobile side.Edit the script "Edit Record being Pulled (TOName)" and create a branch (an If statement like the example there) which tests for the Table Occurrence name you're interested in: the set the checked out field in that table.

-> Preventing edits of checked out records. In your hosted solution, use FileMaker's built in access privileges to prevent editing of records where "checked out" is not empty. In relational solutions you'll want to apply this restriction to child records as well: one should not be able to edit an invoice line item if the invoice is checked out, for example.

-> Checking in. Edit the script "After Committing Entity" and you'll see branches similar to those in "Edit Record..." above. Create a branch for your table occurrence and set the "checked out" field to blank (use two quotes without a space between them).

That's it.
July 05, 2012, at 01:39 AM by 50.132.84.245 -
July 02, 2012, at 05:24 PM by 50.132.84.245 -
Added lines 1-3:
!! Can I "check out" records so only the mobile own can edit them?

Yes. Coming soon.
(855) SEEDCODE
[email protected]
Follow us: