Unresolved
Details
Assignee
Chaitanya KesirajuChaitanya KesirajuReporter
PragyaPragyaSeverity
MajorFeature
Resolved by
Piyush ShuklaPiyush ShuklaOriginal estimate
Time tracking
No time logged60h remainingSprint
NoneFix versions
Priority
Medium
Details
Details
Assignee
Chaitanya Kesiraju
Chaitanya KesirajuReporter
Pragya
PragyaSeverity
Major
Feature
Resolved by
Piyush Shukla
Piyush ShuklaOriginal estimate
Time tracking
No time logged60h remaining
Sprint
None
Fix versions
Priority
Created April 21, 2023 at 6:43 AM
Updated April 3, 2024 at 5:08 AM
Feature: Feature: As an Operator/Supervisor, when I launch Registration Client for the first time, auto Sync should be performed
Purpose: Synchronize data/Auto Sync
Synchronize data is the data required to make the Registration Client(RC) functional. Full sync is performed initially during the launch of the RC for the first time. Post this, the RC syncs only the changes from sever and this is called as the delta sync. Synchronize data is automated and can be triggered manually. This happens automatically while launching the RC and is also manually initiated by the operator.
Masterdata sync : As a part of this sync, supporting information like Dynamic fields data, templates, locations, screen authorization, blocklisted words, etc. are pulled in.
Pre-registration Data Sync : As a part of this sync, all the supporting information are pulled in. (Will be part of Phase 2)
Policy Sync : Public key and policy key syncs are done to get the certificates which are used for device trust validations, packet encryption and server signatures
Registration Client Configuration sync: Sync of properties which drives in deciding the RC UI functionality. For example: Invalid login attempts, idle timeout, thresholds, etc.
Registration Packet Status Reader : As a part of this sync, whenever the packet is uploaded then system will display the status of the packets. (Not part of auto Sync Currently)
Packet Upload batch Job Sync: As a part of this sync, the packet that are in “SYNCED” status should be uploaded one by one (FIFO) on availability of internet. (Not part of auto Sync Currently, since there will be no packets during the first sync)
UserDetails sync: User ID, along with their status is synced. Only the user details belonging to machine mapped center will be synced.
Pre Registration Packet Deletion : As part of this sync, once the packet is created and consumed then the packet will get deleted from the local. (Not part of auto Sync Currently, since there will be no packets during the first sync)
Registration Packet Deletion Job : As a part of this sync, once the packet is consumed after the registration then based on the job the packet will get deleted. (Not part of auto Sync Currently, since there will be no packets during the first sync)
Audit log Deletion Job : This sync will help to delete the audit logs from the audit table. (Not part of auto Sync Currently, since there will be no packets during the first sync)
Registration Packet sync: (Not part of auto Sync Currently, since there will be no packets during the first sync)
All the approved/rejected Registration IDs(RIDs) will be synced to the server.
All the synced RID packets will be uploaded to the server.
All the uploaded packet status will be synced from server.
Public key Sync service : Certificates used to validate the server signatures, device CA certificates, public key (specific to a center and machine, also called as policy key) used to encrypt the registration packet will be synced.
Basic Flow
As soon as the application is launched system will sync all the data (Mentioned above) automatically based on the center and the machine mapped.
After login, user can sync the data manually by clicking on ‘Synchronize Data’.
Acceptance Criteria
The flow as defined above should work seamlessly