To speed up the sync and eliminate existing problems with ticket item sync.
Acceptance Criteria
Syncing:
Only retrieve records which have changed after the initial sync
Delete items which are in the deleted state since the last sync
Honor the AltSync Flag
Remove items which are no longer availableSee #4120
General Use:
Reporting should be unaffected
Ticket Item grid should be unaffected
Analysis
Migration Issues
Changing from the “model:TicketItem...” to the “model: event-queued” events will pose a problem. How can we gracefully handle that? Do we keep dual sets of event handlers for when the user switches or do we require customers to log out and then log in the clear any issues?
Adding a presync process to convert the relevant events would solve the problem. It could live in the app until all of our customers have swiched to the new sync. Sending the events to clear the event store before the sync was considered, but it becomes complicated if there are errors or there is a very large event store.
When the version gets switched over, most of our customers will not have their sharing rules for job properly configured. They will receive every ticket item in the system. Do we use a sync version to solve the problem?
We’ll use the standard deployment methods. We’ll use early notification to imps and support to let them know sync is changing. We’ll encourage customers who are not ready to switch the quarterly beta. That should give them over 6 months to work out their sharing rules.
TJ – How are we going to get the list of ticket items to retrieve? Currently we get a list of tickets then get all ticket items where ticket id IN (...)
DP – The new sharing rules for job would be implemented. The fit does not have to be perfect. In other words, if we are getting too many ticket items down, it’s not that big of a deal since the user has no way to access those items. This will become a bigger issue as we move up the chain to tickets and jobs. There is however, a problem with record Owner, which trumps sharing rules. It may be the case that once a job or ticket becomes “archived” or moves to another status, the Owner of the record should be changed. Without a feature like this, customers would be forced to implement the “optional” AltSync flag.
Code Impact
Reporting: Reporting currently reverse maps the ticket items back to their raw layout. This change should have almost no effect on reporting other than to possibly speed it up.
Mapping: The Primary area affected by mappings is the Ticket Item creation from a Price Book Item. The auditor would need to be replaced. Some of this work may already be under way.
Indexing: Since we cannot currently index ticket items anyway, there will be no loss. We gain indexing even though there is currently no way to leverage it. The reference.js module’s resolveTicketItem method needs to be removed so the sobjects store will take it over.
Sync: Regarding sync, we will whitelist Ticket Items under the new Sync. This change should handler AltSync, removal of deleted records and incremental changes. It will not fix problems with items which are no longer shared.
Relationships: Relationship management for the new ticket items needs to be changed to the way it’s handled for quotes. This would affect the setting of parents in the pipelines and the ticket relationship on the newly created items.
Rule Engine: Because of quoting most of the rule-engine has been switched to using the mappings module for getting fields by name. So very little should have to change to make it work.
UI: This is the most complex piece of this story:
The ticket item list module would have to be changed to pull it’s data from the new sobjects store.
The old mapped layouts would no longer be available for displaying the data. Parts of the layout/layout module should be rewritten to take raw layouts as well as the old munged layouts. Namely the flatten method.
For editing individual ticket items we could easily replace the detail and edit modals which we currently use. If we do that we would need an extra story for the lock fields.
Permissions: Items which are no longer shared would have to be removed. Currently we do a red sync every time which wipes everything and rewrites it. Ticket Items currently reside at the bottom of the Job sharing tree.
Do we use a manifest to remove the extra items?
If so, do we try and do it at the job level? That would imply an extra step during the sync process to remove the extra jobs/ticket/items.
Another possibility might be to use an apex rest endpoint that keeps track of what it gives you from sync to sync, and tells you what to remove. There are problems with this, namely: multiple device logins.
Should we be concerned with items which use unavailable RecordTypes?
Note: Until #4120 is complete there will be unreachable zombie ticket items. This problem currently exists with quotes.
Related Stories
Here are the defects which this eliminates:
3774
There is also a problem similar to defect #3361 but it applies to tickets.
These are stories that should be split off to make this task easier:
Replace the Readonly/Required field overrides for specific fields, see ticket-item-map.js in fetch for the list of fields.
Simplify Locking Fields for ticket items.
Change the way PricebookItem and Ticket are hidden on the layouts for Ticket Item.
Replace usage of alias fields with mapping calls
Rule-engine, snapshot and reconcile
Ticket View Models
Ticket Item Picker
Separate Ticket Items from the Ticket in the ViewModels.
Query for Child Items by Tracking Number
Separate Ticket Logs from Ticket
Separate Ticket Checklist from Ticket
Replace the relationship mechanism for a new one which uses shallow objects with tracking number.
Move the responsibility for removing recommended snapshot rows to ticket/reconcile from store/snapshot. Note: this may not be a prereq for getting incremental sync.
Start raising new model:event-queued for model:TicketItemCreated
Start raising new model:event-queued for model:TicketItemAltered
Start raising new model:event-queued for model:TicketItemRemoved
Use raw layout for ticket items (add a sync component for the raw layout and description)
Sync Raw Data and Remove old sync data from fetch.
Tasks
{{table query: SELECT Number, Name, Owner, 'Task Status' WHERE Type = Task and Story = THIS CARD}}
Defects
{{ table query: SELECT Number, Name, Owner, 'Status' WHERE Type = Defect and 'Related Story' = THIS CARD }}
githubbob42
commented
5 years ago
Mingle Card: 4116 Justification
To speed up the sync and eliminate existing problems with ticket item sync.
Acceptance Criteria
Syncing:
General Use:
Analysis
Migration Issues
Changing from the “model:TicketItem...” to the “model: event-queued” events will pose a problem. How can we gracefully handle that? Do we keep dual sets of event handlers for when the user switches or do we require customers to log out and then log in the clear any issues?
When the version gets switched over, most of our customers will not have their sharing rules for job properly configured. They will receive every ticket item in the system. Do we use a sync version to solve the problem?
TJ – How are we going to get the list of ticket items to retrieve? Currently we get a list of tickets then get all ticket items where ticket id IN (...)
DP – The new sharing rules for job would be implemented. The fit does not have to be perfect. In other words, if we are getting too many ticket items down, it’s not that big of a deal since the user has no way to access those items. This will become a bigger issue as we move up the chain to tickets and jobs. There is however, a problem with record Owner, which trumps sharing rules. It may be the case that once a job or ticket becomes “archived” or moves to another status, the Owner of the record should be changed. Without a feature like this, customers would be forced to implement the “optional” AltSync flag.
Code Impact
Reporting: Reporting currently reverse maps the ticket items back to their raw layout. This change should have almost no effect on reporting other than to possibly speed it up.
Mapping: The Primary area affected by mappings is the Ticket Item creation from a Price Book Item. The auditor would need to be replaced. Some of this work may already be under way.
Indexing: Since we cannot currently index ticket items anyway, there will be no loss. We gain indexing even though there is currently no way to leverage it. The reference.js module’s resolveTicketItem method needs to be removed so the sobjects store will take it over.
Sync: Regarding sync, we will whitelist Ticket Items under the new Sync. This change should handler AltSync, removal of deleted records and incremental changes. It will not fix problems with items which are no longer shared.
Relationships: Relationship management for the new ticket items needs to be changed to the way it’s handled for quotes. This would affect the setting of parents in the pipelines and the ticket relationship on the newly created items.
Rule Engine: Because of quoting most of the rule-engine has been switched to using the mappings module for getting fields by name. So very little should have to change to make it work.
UI: This is the most complex piece of this story:
Permissions: Items which are no longer shared would have to be removed. Currently we do a red sync every time which wipes everything and rewrites it. Ticket Items currently reside at the bottom of the Job sharing tree.
Note: Until #4120 is complete there will be unreachable zombie ticket items. This problem currently exists with quotes.
Related Stories
Here are the defects which this eliminates:
3774
There is also a problem similar to defect #3361 but it applies to tickets.
These are stories that should be split off to make this task easier:
Tasks
{{table query: SELECT Number, Name, Owner, 'Task Status' WHERE Type = Task and Story = THIS CARD}}
Defects
{{ table query: SELECT Number, Name, Owner, 'Status' WHERE Type = Defect and 'Related Story' = THIS CARD }}
Test Plan