Veris Runtime \ Frontend \ Widgets

Discussed - Laws:

1. A venue can have different type of terminals
2. If there is any change in screen (order, widget etc.) or widget of any terminal type then new terminal type must be created.
3. Default or preset terminal types cannot be updated, if user want to update/configure already existed terminal type then new Terminal type will created as stated in point 2.
4. TBD - Widgets are added from Admin panel, will be reviewed by the Engg Team and QA Team
5. TBD - Any Dependent widget cannot be added ahead of widget it depends (in context of screen).
6. IMP - Health Check must ensure that the Client is in Sync with the Server, w.r.t the plugins
7. IMP - In the case of independent widgets and data conflicts, the primary module for the functionality wins
8. TBD - Circular dependency needs to be identified and be dealt with set of new terminals
9. IMP - All the widgets must resolve locally first. If the mandatory data is not available locally, only then talk to backend
10. As soon as any of the widget is resolved, all the other unresolved widgets must be checked for resolution
11. IMP - Dependency resolving widget must have all the data required for dependent widgets

Possible New - Rules/ Laws:

The platform has a limited number of entities and attributes, that is the information it can share, for example

• Ex: Module - User Shares - User First Name/ Last Name Shares - User ID Shares - User Profile Picture
• Ex: Module - Invite Shares - Invite Code Shares - Invite Schedule

Imagine - while registering the widget, on the portal, widget needs to register for all the information it requires from the platform