Checking Out Records
GoZync3.CheckingOutRecords History
Hide minor edits - Show changes to output
December 17, 2012, at 10:17 PM
by - 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.
-> 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:
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.
-> 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 forzyncing 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.
-> '''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
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.
-> '''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.
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).
-> 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).
-> '''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).
Changed lines 3-25 from:
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.
'''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.
Added lines 1-3:
!! Can I "check out" records so only the mobile own can edit them?
Yes. Coming soon.
Yes. Coming soon.