Work manager overwrites dates set in OR

[ksmacleod99]

Expected behavior

If I adjust challenge dates/durations in OR, they should persist after I make changes to the challenge in Work Manager -- in lieu of being able to change dates via work manager, of course.

Actual behavior

If I adjust challenge dates/durations in OR, but have to go back and make a change to the challenge spec in Work Manager, the dates in OR reset to the default.

Steps to reproduce the problem

1. Create a data science challenge in work manager
2. Save it
3. Open the challenge in OR
4. Observe dates for registration and submission; they default to 4 days in the future.
5. Adjust registration and submission dates to ~4 weeks in the future
6. Save changes in OR, observe to make sure they took
7. Open the challenge in Work Manager
8. Click edit
9. Make edits, specifically to the specification
10. Save
11. Go back to the challenge in OR
12. Observe - dates will have reverted to the "default" 4 days.

Screenshot/screencast

iou

--

Environment

• OS: MacOS 11.6.1
• Browser (w/version): Chrome 96.0.4664.110 (Official Build) (x86_64)
• User role (client, copilot or manager): Manager
• Account used: ksmacleod99

[jmgasper]

@ksmacleod99 - I investigated this a bit.

When WM creates or edits a challenge, it sends a phases array, even though we don't have a UI for modifying the actual phase details as fine grained as we do in OR.

    "phases": [
        {
            "phaseId": "a93544bc-c165-4af4-b55e-18f3593b457a",
            "duration": 432000,
            "id": "714bf4e6-528f-4909-8fa7-e2226ff0598b",
            "name": "Registration",
            "isOpen": false,
            "scheduledStartDate": "2022-01-21T05:41:30.000Z",
            "scheduledEndDate": "2022-01-26T05:41:30.000Z",
            "actualStartDate": "2022-01-21T05:41:30.000Z",
            "description": "Registration Phase"
        },
        {
            "phaseId": "6950164f-3c5e-4bdc-abc8-22aaf5a1bd49",
            "duration": 432000,
            "id": "cdd8d4e5-4d6b-435b-aeb7-5de89dac88a7",
            "name": "Submission",
            "isOpen": false,
            "scheduledStartDate": "2022-01-21T05:41:30.000Z",
            "scheduledEndDate": "2022-01-26T05:41:30.000Z",
            "actualStartDate": "2022-01-21T05:41:30.000Z",
            "description": "Submission Phase"
        },
        {
            "phaseId": "aa5a3f78-79e0-4bf7-93ff-b11e8f5b398b",
            "duration": 172800,
            "id": "78a02771-df80-43a8-b465-1cfbce38a52e",
            "name": "Review",
            "isOpen": false,
            "predecessor": "6950164f-3c5e-4bdc-abc8-22aaf5a1bd49",
            "scheduledStartDate": "2022-01-26T05:41:30.000Z",
            "scheduledEndDate": "2022-01-28T05:41:30.000Z",
            "actualStartDate": "2022-01-26T05:41:30.000Z",
            "description": "Review Phase"
        },
        {
            "phaseId": "1c24cfb3-5b0a-4dbd-b6bd-4b0dff5349c6",
            "duration": 86400,
            "id": "275464c1-07b9-4f63-b6a0-b1eb8ed40596",
            "name": "Appeals",
            "isOpen": false,
            "predecessor": "aa5a3f78-79e0-4bf7-93ff-b11e8f5b398b",
            "scheduledStartDate": "2022-01-28T05:41:30.000Z",
            "scheduledEndDate": "2022-01-29T05:41:30.000Z",
            "actualStartDate": "2022-01-28T05:41:30.000Z",
            "description": "Appeals Phase"
        },
        {
            "phaseId": "797a6af7-cd3f-4436-9fca-9679f773bee9",
            "duration": 43200,
            "id": "bf50b901-0ddd-4b34-8992-bc9e9cbb7a51",
            "name": "Appeals Response",
            "isOpen": false,
            "predecessor": "1c24cfb3-5b0a-4dbd-b6bd-4b0dff5349c6",
            "scheduledStartDate": "2022-01-29T05:41:30.000Z",
            "scheduledEndDate": "2022-01-29T17:41:30.000Z",
            "actualStartDate": "2022-01-29T05:41:30.000Z",
            "description": "Appeals Response Phase"
        }

So, WM is defaulting all this based on information in the timeline-templates API:

{
    "isActive": true,
    "description": "Default Challenge Timeline",
    "id": "7ebf1c69-f62f-4d3a-bdfb-fe9ddb56861c",
    "name": "Default Challenge",
    "phases": [{
        "phaseId": "a93544bc-c165-4af4-b55e-18f3593b457a",
        "defaultDuration": 432000
    }, {
        "phaseId": "6950164f-3c5e-4bdc-abc8-22aaf5a1bd49",
        "defaultDuration": 432000
    }, {
        "phaseId": "aa5a3f78-79e0-4bf7-93ff-b11e8f5b398b",
        "predecessor": "6950164f-3c5e-4bdc-abc8-22aaf5a1bd49",
        "defaultDuration": 172800
    }, {
        "phaseId": "1c24cfb3-5b0a-4dbd-b6bd-4b0dff5349c6",
        "predecessor": "aa5a3f78-79e0-4bf7-93ff-b11e8f5b398b",
        "defaultDuration": 86400
    }, {
        "phaseId": "797a6af7-cd3f-4436-9fca-9679f773bee9",
        "predecessor": "1c24cfb3-5b0a-4dbd-b6bd-4b0dff5349c6",
        "defaultDuration": 43200
    }]

So, I think we have a couple options here:

Best

The "best" approach is to update Work Manager to allow for modifying the phase information so that we don't have to use OR for it anymore. This way the legacy processor will just move the information from WM to OR, but the user can edit the defaults and phase information in WM. Then, we just tell people not to use OR anymore (or just quickly disable that on OR altogether).

I tested updating a challenge phase setup manually in the v5 API and I have validated that the changes in the v5 API are carried over to OR, so that's one less problem to worry about. It should just be a matter of building out the UI to support the data that's already available in WM.

Ok

The "Ok" approach would be to update whatever legacy processor is running to apply OR date changes back to the challenge in the v5 API. I am not a huge fan of this because it:

1. Involves changing the legacy processor
2. Keeps us tied to OR for fine-grained phase control
3. Is likely going to be tough to keep updated in the future

This would likely just be a quick stopgap anyways, until WM supports the fine-grained phase control.