This is an initial PR to start feedback. There are still a number of outstanding issues, but given the time constraints I'd like to start the code review ASAP.

Description of changes

1. Introduces the time conductor public API into master for the first time
2. Defines new UI for the realtime/historical time conductor
3. Uses D3 for rendering the ticks. Introduces a new MctAxis directive to support this.
4. Introduces time systems, supported for now through a new legacy API extension point "TimeSystem", and supporting classes (eg. TickSource). Implements a default UTCTimeSystem, and a default LocalClock.
5. Central to the implementation is the TimeConductorController. Created some supporting classes around TimeConductorController such as TimeConductorMode. Possibly overkill here. Tried different variations with fewer class definitions, but this kept the code the cleanest even if it does result in a relatively large number of classes.

Note that after a discussion with @charlesh88 it was decided that it is better from a user perspective to select mode first, which will filter the available time systems. Time systems are filtered for real-time and LAD modes based on whether they define any appropriate tick sources.

Also note that although present in the UI, the zoom controller is non functional. It will be implemented if time permits, otherwise will be hidden via CSS.

Would suggest starting from the TimeConductorController and working outward from there.

To do:

• [x] 1. Add support for formats to the D3 ticks. Currently uses the default D3 formatting, which imposes 12 hour time, and won't work for sols.
• [x] 2. Bring across telemetry decorator from old time conductor
• [x] 3. Need styles for snow for the time conductor v2 https://github.com/nasa/openmct/pull/1089#issuecomment-236656967
• [x] 4. UTC time system should be a separate bundle from the conductor-v2, so that it can be disabled in other deployments https://github.com/nasa/openmct/pull/1089#issuecomment-236658245
• [x] 5. When switching to time systems that have a different format, the date time inputs do not update to use the correct format https://github.com/nasa/openmct/pull/1089#issuecomment-236674799
• [x] 6. Disable the zoom slider https://github.com/nasa/openmct/pull/1089#issuecomment-236732799 @charlesh88
• [x] 7. Selecting a mode doesn't filter time systems https://github.com/nasa/openmct/pull/1089#issuecomment-236732799
• [x] 8. ~~Time systems without defaults totally break the time conductor~~ (deferred to #1091) https://github.com/nasa/openmct/pull/1089#issuecomment-236732878
• [x] 9. Tick generation fails when time system values are not dates
• [x] 10. ~~Ticks overlap when scale formatting is not available~~ (deferred to #1091) https://github.com/nasa/openmct/pull/1089#issuecomment-236732799
• [x] 11. Time conductor should be visible in edit mode and retain state on navigation https://github.com/nasa/openmct/pull/1089#issuecomment-237057156 and https://github.com/nasa/openmct/pull/1089#issuecomment-237057366.
• [x] 12. Specify delta format (needed for SCLK support)
• [x] 13. Unlisten to tick source on Time System change
• [x] 14. When a timesystem supports both LAD and Realtime, selecting realtime attaches a listener to the LAD clock instead of the realtime clock.
• [x] 15. Need to be able to set defaults per mode. a short hack would be to add mode: "fixed" or mode: "follow" to the Default and then pick the defaults that apply to the current mode.
• [x] 16. After navigating, unable to select time system .
• [x] 17. Changing mode sets time system to default even if previous time system was a valid choice.
• [x] 18. Better documentation (missing typedefs etc.)
• [x] 19. Lint and build errors
• [x] 20. Tests
• [x] 21. Squash commits

From https://github.com/nasa/openmctweb/issues/161#issuecomment-155162928 no 2.

While in edit mode, flag the currently selected item (as well as all linked instances of the object currently being edited) in the tree with a "pending update" visual status. This requires some UI design.

Comments

As simple as a CSS class, styling could be updated and iterated on. "dirty object" isn't a user concern, but "currently being edited" is; we shouldn't spend too much time on this for v1. @larkin

I'd broaden this to include any objects that have unsaved changes from Edit mode, including their links (not just the selected object.) This happens often in a timeline, but can happen in a Layout too (you can Edit Properties on a panel in a layout) @VWoeltjen

After talking with a few customers it would be great to have a simple plugin for registering URL-based status indicators, i.e. those that poll a URL and show "connected/disconnected" or similar based on the availability of the URL.

Basic functionality might be

var googleIndicator = new openmct.plugins.IndicatorPlugin({ 
    url: 'https://google.com', 
    icon: 'database',
    label: 'Google',
    interval: 15000
});
openmct.install(googleIndicator);

And then you'd get an indicator icon that would go red/green based on whether or not it is connected to the server.

Adds URLIndicator to the build, testable adding

openmct.install(new openmct.plugins.URLIndicatorPlugin({
url: 'http://localhost:8080/',
icon: 'check',
interval: 15000,
label: 'Localhost'
}))

to the openmct file.

Assigned to @simistern

Multiple user requests; related to https://github.jpl.nasa.gov/MissionControl/vista/issues/203

Allow a view to export itself as a PDF, JPG or PNG. Mainly intended for use with plot views, but my be applicable to other view types.

• Should be able to be invoked from the object's view as a context action.
• JPG and PNG would be a fixed resolution TBD, but probably something decently hi-res like 1920 x 1440.
• PDF export should set the aspect ratio of the view to 4:3 and export using vector drawing and characters.
• It may be better to allow invocation of the browser's Print function, especially for PDF output, as that allows the browser to do a lot of the heavy lifting and results in the usage of more vector elements that are resolution independent.

If someone is interested in helping with this, we need to discuss details before any work is started. Thanks!

Early PR for visibility and comments.

Ch-ch-ch-ch-changes ★

1. Have defined a new attribute of Types called "regions". Regions are sections of the browse and edit screens for an object that, while fixed in location, have content that is completely customizable on a per-type basis. Regions are represented in code by a new Region class. Within Regions are RegionParts. A Region can have any number of RegionParts defined. The layout of both Regions and RegionParts are defined by representations. Whether a region part is visible within a region can depend on object state, and is determined by a policy of category region.
2. Defined a new TypeRegionDecorator that defines standard regions for objects to avoid having to add region sections to all type definitions. Only have to explicitly define regions if a type has special requirements, such as the new plot display options.
3. Defined a new EditableRegionPolicy which provides a convenience method for determining whether a region part should be visible in edit/browse mode based on a modes attribute in RegionPart definition.
4. Modified the browse and edit screens to define an Inspector region. Currently this is the only region defined, however I will also defined 'object view' and 'elements' regions. Within the object inspector is the standard properties and location sections.
5. Added a very basic mct-form definition to the plot options region part. mct-form needs some modification to support plot options - see below

Next Steps

General

• Define a new type for plots. Currently the plot options region part is defined for panels because there is no plot object type
• Integrate with @larkin's plot changes. In particular, how to communicate changes in plot view options to the plot itself. My thinking is that because plot view options will be persisted as configuration on the options, the plot can just listen to mutation events on the object and reload the config. We need to coordinate on this though.
• The RegionController is a little clunky at the moment. At the very least it needs a more performant approach to filtering region parts.
• Define regions for object view and elements
• Incorporate regions into NEM refactoring as it allows for separation of markup for browse and edit mode versions of a screen.

Modifications needed in mct-form

• Support re-ordering of labels and controls (currently labels are always to the left of controls, this is incompatible with the screen mockups)
• Support the addition of a glyph / icon in between control and label. @charlesh88 - where are these images going to come from?
• Style changes necessary to make forms look nice in the inspector sidebar. @charlesh88 Are you working on markup / style changes for this at the moment? If not I could use some help with this.
• Currently overflow is messy in the sidebar with the elements section and doesn't work. @charlesh88 might need some help with this also.

Closes

Describe your changes:

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [ ] Is this change backwards compatible? For example, developers won't need to change how they are calling the API or how they've extended core plugins such as Tables or Plots.

Author Checklist

• [x] Changes address original issue?
• [ ] Unit tests included and/or updated with changes?
• [x] Command line build passes?
• [x] Has this been smoke tested?
• [x] Testing instructions included in associated issue OR is this a dependency/testcase change?

Reviewer Checklist

• [ ] Changes appear to address issue?
• [x] Changes appear not to be breaking changes?
• [x] Appropriate unit tests included?
• [x] Code style and in-line documentation are appropriate?
• [x] Commit messages meet standards?
• [ ] Has associated issue been labelled unverified? (only applicable if this PR closes the issue)
• [ ] Has associated issue been labelled bug? (only applicable if this PR is for a bug fix)

Closes #5031 and #4922 and #5476

Describe your changes:

• Uses webpack-dev-server instead of our custom app.js express application.
• Cleans up our use of NODE_ENV variables
• Updates our testing configurations to avoid using HMR when collecting code coverage
• Removes the need for cross_env
• Removes our Memory size override for Node when running the unit tests as node 14 has increased the default to our previously specified size

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [x] Is this change backwards compatible? For example, developers won't need to change how they are calling the API or how they've extended core plugins such as Tables or Plots.

Author Checklist

• [x] Changes address original issue?
• [ ] Tests included and/or updated with changes?
• [x] Command line build passes?
• [x] Has this been smoke tested?
• [x] Testing instructions included in associated issue OR is this a dependency/testcase change?

Reviewer Checklist

• [x] Changes appear to address issue?
• [x] Changes appear not to be breaking changes?
• [x] Appropriate unit tests included?
• [x] Code style and in-line documentation are appropriate?
• [x] Commit messages meet standards?
• [ ] Has associated issue been labelled unverified? (only applicable if this PR closes the issue)
• [ ] Has associated issue been labelled bug? (only applicable if this PR is for a bug fix)

In-progress PR for the Indicators API. For a simple indicator (90% of cases) it works like so:

//var myIndicator = openmct.indicators.create(1000); // With optional priority 
var myIndicator = openmct.indicators.create();
myIndicator.text("Hello World!");
myIndicator.iconClass("icon-info");

In this scenario, Open MCT mostly manages how the indicator looks (though css classes can be applied with the appropriate function calls), and is completely responsible for updating the UI when the setter functions are called. The behavior of the indicator is left to external code under the control of the developer, with the setter functions used to update its onscreen appearance. See the updated Follow Indicator and URL Status Indicator for examples of its use.

For a completely custom indicator you can pass a function into the call to openmct.indicators.create(function). The only requirement for the function you provide is that it must return a DOM node for insertion alongside the other indicators. In this mode, no indicator object is returned, and the caller is entirely responsible for the look, behavior, and ongoing updating of the indicator. eg.

//openmct.indicators.create(1000, function () { // With optional priority
openmct.indicators.create(function () {
    var domNode = document.createElement('div');
    domNode.innerText = new Date().toString();
    setInterval(function () {
        domNode.innerText = new Date().toString();
    }, 1000);
    return domNode;
});

Looking for comments on the approach taken here.

To do

• [x] Allow definition of priorities for indicators
• [x] Wrap nodes returned by custom display functions. (Currently indicators MUST have certain classes attached otherwise they won't display properly).
• [x] API Documentation
• [x] Code cleanup
• [x] Tidy up commits
• [ ] ~~Convert default indicator to Vue component? (Currently using vanilla JS).~~ Deferring for now. Not really sure it makes sense to do this anyway, it would end up being more code than the current implementation I suspect.
• [x] Unit tests
• [x] JSHint / JSCS

Addresses #1273

• Added autocomplete control. To use it just need to pass options as either an array of strings or an object with name and value.
• User will be able to set timezone via autocomplete control. Default timezone is UTC.

Author Checklist

1. Changes address original issue? Y
2. Unit tests included and/or updated with changes? Y
3. Command line build passes? Y
4. Changes have been smoke-tested? Y

When a user is using the locator widget (e.g. move, copy, link, etc), and they select a location that is invalid, the locator refreshes with no contents selected.

With scratchpad enabled, you can reproduce like so:

1. Create a folder inside of the "scratchpad" folder.
2. Create an object inside of the "my items" folder.
3. right click on the object you created in "my items" and select "move".
4. in the locator widget, expand the scratchpad folder.
5. Select the folder you created in the "scratchpad" folder as the destination.

Behavior: the locator tree collapses, the folder you attempted to select is no longer visible. There is no message indicating why it doesn't work.

Here's a short gif showing current behavior:

Throwing this in le guin for triage, we can move it to a later sprint after looking at it.

@charlesh88 think we'd need some design about how to show users that their selection is invalid. Or should we grey out invalid choices? Need some messaging to users about why this can't be done.

Closes #5792

Describe your changes:

Known Issues: Adding/Removing series to different Y axis buckets requires navigating away and back to the overlay plot.

Changes:

• Move the Y axis name to the bottom of the y-axis area
• Move the gear icon below the name of the y-axis
• Add a visibility toggle to the y-axis
• Add color swatches to indicate which series are part of the y axis (no hover interaction is done for MVP)

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [x] Is this change backwards compatible? For example, developers won't need to change how they are calling the API or how they've extended core plugins such as Tables or Plots.

Author Checklist

• [x] Changes address original issue?
• [ ] Tests included and/or updated with changes?
• [x] Command line build passes?
• [x] Has this been smoke tested?
• [x] Testing instructions included in associated issue OR is this a dependency/testcase change?

Reviewer Checklist

• [ ] Changes appear to address issue?
• [ ] Reviewer has tested changes by following the provided instructions?
• [ ] Changes appear not to be breaking changes?
• [ ] Appropriate automated tests included?
• [ ] Code style and in-line documentation are appropriate?
• [ ] Has associated issue been labelled unverified? (only applicable if this PR closes the issue)
• [ ] Has associated issue been labelled bug? (only applicable if this PR is for a bug fix)

Summary

The Forms API was designed to allow developers to extend the built-in form capabilities of Open MCT with custom controls that can be integrated within standard Open MCT object properties forms.

Gauges misuse the custom form component API to shoehorn an entire custom form into the object properties dialog. This presents many problems including re-implementing form handling that Open MCT already does, and prevents reuse custom form components

Expected vs Current Behavior

Gauges should use the forms API to register any custom form components, but rely on the built-in Open MCT form framework for handling form rendering and validation. If there are shortcomings in the built-in framework, then it should be improved to handle these specific cases so that future plugin developers can benefit from it.

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?
• [X] 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?

Is your feature request related to a problem? Please describe. Open MCT allows toggling the x-axis so that the data for that range is plotted against the selected x-axis domain as opposed to the domain (time system) specified in the time conductor.

It would be useful to share this view with others by sharing the url.

Describe the solution you'd like After toggling the x-axis, share the current url so that navigating to that url will show the plot in the toggled x-axis state.

1. set params on toggle (would have to specify which plot to toggle)
2. read in params (in plot view?)
3. plot view (need to request data, then plot the correct view)

Additional context If data is plotted in Earth Received Time, it may be useful to view the data plotted in Spacecraft Event Time. And then, it would be useful to share this exact view with colleagues.

Workaround Navigate to view. Toggle x-axis manually.

Closes #6096

Describe your changes:

Enable dragging of series elements directly into YAxis buckets within the PlotElementsPool

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [x] Is this change backwards compatible? For example, developers won't need to change how they are calling the API or how they've extended core plugins such as Tables or Plots.

Author Checklist

• [x] Changes address original issue?
• [ ] Tests included and/or updated with changes?
• [x] Command line build passes?
• [x] Has this been smoke tested?
• [ ] Testing instructions included in associated issue OR is this a dependency/testcase change?

Reviewer Checklist

• [ ] Changes appear to address issue?
• [ ] Reviewer has tested changes by following the provided instructions?
• [ ] Changes appear not to be breaking changes?
• [ ] Appropriate automated tests included?
• [ ] Code style and in-line documentation are appropriate?
• [ ] Has associated issue been labelled unverified? (only applicable if this PR closes the issue)
• [ ] Has associated issue been labelled bug? (only applicable if this PR is for a bug fix)

Description

This design extends the design of the Admin's Indicator panel to include a table of responses, so that a layout or telemetry view doesn't need to be used to see detailed per-position responses. This view will not be limited to any Time Conductor settings. This design also introduces the idea of a "Clear Poll Question" button, which clears any active poll questions as well as status responses in regard to that question.

Tasks

• [ ] Status Response Table @scottbell looking into this Each response includes the following information: We need to define in what way the table will be sorted. Currently, we are leaning towards sorting alphabetically by Operator Positions' name. Position of the Operator Current status Age of response (Time since the status was last updated). OP Status popup is resizable.
• [ ] Clear Poll Question Button @michaelrogers looking into this Clear button that clears any active poll questions and status responses in regard to that question. If cleared, the table of status responses will become empty. This ability to clear a poll question and disable any statuses would be useful because otherwise, a poll question will always be active, even if OPS are not.
• [ ] [Table] Implement loading spinner animation on row until fully loaded while waiting for data from YAMCS when first starting up

Notes

• Sorting not needed for 1.1 version of the table, but possibly for v2.0 based on user feedback.

Summary

Dragging a series into a multiple-y-axis supporting overlay plot's 2nd y axis group does not work.

Expected vs Current Behavior

Expected: The series should be added to the top of the 2nd y axis bucket Actual: Error is observed as follows:

[Vue warn]: Error in v-on handler: "TypeError: this.elementsCache[keyString] is undefined"

found in

---> <ElementItemGroup> at src/ui/inspector/ElementItemGroup.vue
       <PlotElementsPool> at src/ui/inspector/PlotElementsPool.vue
         <Pane> at src/ui/layout/pane.vue
           <Multipane> at src/ui/layout/multipane.vue
             <Inspector> at src/ui/inspector/Inspector.vue
               <Pane> at src/ui/layout/pane.vue
                 <Multipane> at src/ui/layout/multipane.vue
                   <Layout> at src/ui/layout/Layout.vue
                     <Root> [vue.js:634](webpack://openmct/node_modules/vue/dist/vue.js?7193)
TypeError: this.elementsCache[keyString] is undefined
    updateCacheAndMutate PlotElementsPool.vue:269
    moveTo PlotElementsPool.vue:257
    group PlotElementsPool.vue:35
    VueJS 4
    emitDrop ElementItemGroup.vue:91
    VueJS 39
    applySearch PlotElementsPool.vue:230
    applySearch PlotElementsPool.vue:229
    addElement PlotElementsPool.vue:217
    emit CompositionCollection.js:342
    #emit CompositionCollection.js:338
    add CompositionCollection.js:227
    load CompositionCollection.js:243
    load CompositionCollection.js:243
    showSelection PlotElementsPool.vue:152
    mounted PlotElementsPool.vue:118
    VueJS 19
    mounted BrowseBar.vue:248
    emit index.js:137
    edit Editor.js:44
    edit BrowseBar.vue:290
    click BrowseBar.vue:133
    VueJS

Steps to Reproduce

1. Create a Sine Wave Generators and a State Generator
2. Create an overlay plot that supports multiple y axes
3. Drag one sine wave generator to the plot and save it
4. Edit the Overlay plot so that the elements pool is visible
5. Drag the State Generator directly on top of the 2nd y axis bucket/group
6. Observe the error above.

Environment

• Open MCT Version: Feature branch - multiple y axes
• Deployment Type: Local
• OS: All
• Browser: All

Impact Check List

• [ ] Data loss or misrepresented data?
• [ ] Regression? Did this used to work or has it always been broken?
• [x] Is there a workaround available?
• [x] 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