Unassigning a delivery service request that is already unassigned results in null

[ericholguin]

I'm submitting a ...

• [X] bug report
• [ ] new feature / enhancement request
• [ ] improvement request (usability, performance, tech debt, etc.)
• [ ] other

Traffic Control components affected ...

• [ ] CDN in a Box
• [ ] Documentation
• [ ] Grove
• [ ] Traffic Control Client
• [ ] Traffic Monitor
• [X] Traffic Ops
• [ ] Traffic Ops ORT
• [ ] Traffic Portal
• [ ] Traffic Router
• [ ] Traffic Stats
• [ ] Traffic Vault
• [ ] unknown

Current behavior:

When a delivery service request is already unassigned, and sending a PUT request to deliveryservice_requests/{{id}}/assign with {"assigneeId": null} in the body returns:

HTTP/1.1 200 OK
{
    "alerts": [
        {
            "text": "deliveryservice_request was updated.",
            "level": "success"
        }
    ],
    "response": {
        "authorId": null,
        "author": null,
        "changeType": null,
        "createdAt": null,
        "id": 4,
        "lastEditedBy": null,
        "lastEditedById": null,
        "lastUpdated": null,
        "deliveryService": null,
        "status": null
    }
}

Expected / new behavior:

The response for when a user is assigned is the same as the response when a user is unassigned, the only difference is that the unassigned response output does not include the assigneeId and assignee key. The Response should be:

HTTP/1.1 200 OK
{
    "alerts": [
        {
            "text": "deliveryservice_request was updated.",
            "level": "success"
        }
    ],
"response": {
        .
        .
        .
        },
        "status": "submitted"
    }
}

Minimal reproduction of the problem with instructions:

Anything else:

[ocket8888]

Anybody know if this is a regression?

[mitchell852]

Anybody know if this is a regression?

I doubt it. Probably always been this way.