CRITs API does not support setting the releasability flag on posted data

[treyka]

No description provided.

[treyka]

bump

[mgoffin]

This is correct. At this point in time there is no way to do this.

[Lambdanaut]

Working on adding this and I'm hitting an issue with the route type_ not matching up with the expected class name in class_from_id().

aka Actor != Actors :(

I could change the line in class_from_id() from

if type_ == 'Actor':

to

if type_ == 'Actor' or type_ == 'Actors':

Or something else. We need to create a mapping from route names to class type names somewhere. Thoughts?

[mgoffin]

Not sure what you are talking about. I would need to see specific code to know the problem. I suspect you are doing something incorrectly.

[Lambdanaut]

Maybe.

The add_releasability() handler takes a type_ which in the obj_update() function is gotten from the url of the PATCH request. In the case of actors, the type_ would be "actors" from api/v1/actors/. It then calls .title() on "actors" to turn it into "Actors".

When the add_releasability() function calls class_from_id(), it passes in that "Actors". "Actors" != "Actor", so it can't map it to an instantiated TLO.

[mgoffin]

If the type and ID are being derived from the PATCH request, then everything should work off of something like this:

• You are looking for ID 123 for actors
  • id_ = 123
  • type_ = Actor

Then any code in the core API should use that. One issue would be something like RawData, which we need to make a special case for and fix it.

[Lambdanaut]

So a mapping in the core api that maps actors to Actor and so-on for every url?

[mgoffin]

Working on something for this. Give me a second and I'll update :)

[mgoffin]

See if the latest commit to master fixes all of this for you.

[Lambdanaut]

NICE!

Relevant pull request: #505

[Lambdanaut]

I think this can be closed now

[mgoffin]

I'll leave it up to @treyka if he feels this satisfies his requirements. I think adding something to the system by default shouldn't come with releasability and that sending a PATCH to add it later is a good process.

[mgoffin]

Sure thing! Glad to see it was pretty easy for someone to take up exposing a handler now that PATCH is up and running. Hopefully this leads to more help! ;)

[treyka]

@Lambdanaut and I have been closely collaborating on a related project. If he's happy, I'll go with that.

Thanks a mil, @mgoffin! ^_^

[packet-rat]

[+1] "Thanks a mil, @mgoffin! ^_^"

Patrick Maroney
Cell: (609)841-5104

On May 20, 2015, at 11:14 AM, Trey Darley notifications@github.com wrote:

@Lambdanaut and I have been closely collaborating on a related project. If he's happy, I'll go with that.

Thanks a mil, @mgoffin! ^_^

—
Reply to this email directly or view it on GitHub.