• Join - It's Free

Returning flags for field locks?

Started by Dan Cornett on Thursday, February 11, 2016
Problem with this page?

Participants:

  • Geni Pro
  • Private User
    Geni Pro
  • Private User
    Geni Pro

Related Projects:

Showing all 7 posts

Would it be feasible to return, along with field values, an indicator (for each field) whether or not it is locked?

Only when requested, of course, with an optional argument on the request, so it wouldn't "break" current applications.

(Only relevant for a profile's "basic" fields, of course.)

I expect it would be easy for contained objects, such as events or unions, since they could just add another field in the object. This shouldn't break anything, requested or not.

"birth":{"date":{"day":29,"month":6,"year":1951,"locked": true}}

I think the difficult ones would actually be names, gender, living, occupation, since they're not defined in separate objects.

{"first_name":"John","last_name":"Smith","gender":"male"}

There is no easy place to associate the lock per item. Something like this would break stuff

{"gender": {"value":"male","locked": true}} (would break stuff)

So I'd think you'd have to have a separate element for such data that defines the locks in an array. This could easily be added in the "field" get request.

{"locked":["names","gender","occupation"]}

This method could also probably handle events and unions as well if you didn't want to use the first method.

{"locked":["birth_date","union-1343234"]}

That second approach seems the most generic ... and simplest then for apps to add in to existing code.

We added a locked_fields field, but you have to specifically ask for it.

Just add it to your field list:

/api/profile-15122213?fields=name,locked_fields

Nice! Thanks Scott :)

Private User, writing code for this and noticed that "is_alive" is titled "living" in the locked_fields. That's perfectly fine, but it seemed inconsistent. Just wanted to bring it up in case it was unintentional.

living is an APIv1 alias for is_alive. We're keeping is_alive around for backward compatibility with APIv0.

For gets, you can use living instead of is_alive, but for updates, you need to use is_alive.

Showing all 7 posts

Create a free account or login to participate in this discussion