Unable to patch an Enum based on description

[chriswithpants]

I'm trying to patch the Status field on something, where Status is an Enum. We're using EnumMember on our enum values to specify how the client should see them, e.g.

public Enum Status
{
    [EnumMember(Value="open")]
    Open = 1,

    [EnumMember(Value="in_progress")]
    InProgress = 1,

    [EnumMember(Value="closed")]
    Closed = 1,
}

When we try to patch this status to in_progress it can't map that back to the Status.InProgress.

[
    {
        op: "replace", path: "/status", value: "in_progress"
    }
]

I'm happy to put a PR in for this, but thought I'd get your take on how you'd like to see this implemented first. Thought you might have some preferences about using JsonProperty Description EnumMember etc attributes, things like that.

[zihotki]

Why can't you submit an integer value instead of a string? String for enums will require to write a plenty of code to handle only that specific case.

[chriswithpants]

We could totally use ints, and have previously, but for this project we're using the string values instead.

[zihotki]

On the afterthought and after reading documentation about EnumMember it seems to me that it is a good candidate to include in the library since it's a standard way of serializing/deserializing enums amongst various serialization libraries - contracts, json.net, etc.

[myquay]

I think EnumMember is the way to go - it looks like a good candidate when an API wants to support a string value instead of an integer for legibility etc.

[imukai]

Did this ever gain any traction? @chriswithpants did you have an interim solution you could post? Doesn't look like this library is getting much love anymore.

[myquay]

I think this would be good to add - happy to review a PR for inclusion :)