Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lost Time conductor clocks/time system compatibility checks #7730

Open
4 of 7 tasks
davetsay opened this issue May 14, 2024 · 0 comments
Open
4 of 7 tasks

Lost Time conductor clocks/time system compatibility checks #7730

davetsay opened this issue May 14, 2024 · 0 comments
Assignees
Labels
bug:regression It used to work. Now it doesn't :( not_viper Temporary label to define bugs that won't affect viper deployments severity:critical type:bug

Comments

@davetsay
Copy link
Contributor

Summary

Switching Clocks and Time Systems should be linked, as some clocks work only with certain time systems and not all time systems. Currently, we have lost the check on clock change, to which timesystem is allowed. This is a regression. Before, it used to gracefully switch time system for you.

Steps to Reproduce (Local only or need to have multiple clocks/time systems installed)

  1. Create multiple time systems and clocks
    1.1. Locally in code, go into UTCTimeSystem/plugin.js
    1.2. Create a new time system, then change the key and name after instantiation
    1.3. Create a new Local Clock, then change the key and name after instantiation
    1.4. Go into index.html and configured a realtime block to use the new clock and time system
  2. Run openmct locally
  3. Switch the time conductor clock to the new clock
  4. Observe borkedness. The time system remains the same, but when you click on the dropdown to change the time system, only the time system that works with the clock should be in the dropdown.

Environment

  • Open MCT Version:
  • Deployment Type:
  • OS:
  • Browser:

Impact Check List

  • Data loss or misrepresented data?
  • Regression? Did this used to work or has it always been broken?
  • Is there a workaround available?
  • Does this impact a critical component?
  • Is this just a visual bug with no functional impact?
  • Does this block the execution of e2e tests?
  • Does this have an impact on Performance?

Additional Information

@davetsay davetsay added type:bug bug:regression It used to work. Now it doesn't :( labels May 14, 2024
@davetsay davetsay self-assigned this May 14, 2024
@unlikelyzero unlikelyzero added not_viper Temporary label to define bugs that won't affect viper deployments severity:critical labels May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug:regression It used to work. Now it doesn't :( not_viper Temporary label to define bugs that won't affect viper deployments severity:critical type:bug
Projects
None yet
Development

No branches or pull requests

2 participants