sffcu.org

Linked memberships

• Does Joe represent each membership in the DB as a separate entity with its own ID, or do we reference it with both the user id and membership number?

  For example: POST to /api/users/1/membership/12345/link to link the membership, or POST to /api/associated_member/2394809834/link

• Which actions do we need?
  • link (POST {base-membership-url}/link)
  • unlink (POST {base-membership-url}/unlink)
  • invite (POST {base-membership-url}/invite)
  • edit nickname (POST {base-membership-url} with body:

    {
      "nickname": "New Nickname"
    }              
            

    Passing an empty nickname should clear it out.

• What information do we need?

  [{:member_number "123456"
    :nickname "Primary Membership"
    :access_level "full_access"
    :primary true
    :association "Joint Member"
    :relationship "Other"
    :editable true
    :status "linked"
    :contact_info {:email "[email protected]"
                   :phone_list [{:type "home"
                                 :number "234 567-8910"}
                                {:type "work"
                                 :number "344 923-1234"}]}}
   {:member_number "4323423"
    :name "Mom's account"
    :association "Joint Member"
    :relationship "Mother"
    :restricted true
    :status "available"
    :editable false
    :access_level "transactional"}
   {:member_number "923409"
    :nickname "Kelly's account"
    :access_level "full_access"
    :association "Joint Member"
    :relationship "Wife"
    :status "linked"
    :editable false
    :contact_source "123456"}]
      

  • Fields:
    • member_number
    • nickname
    • access_level (currently “full_access” or “transactional”)

      This is being used to populate the “Allowed Accounts” field, but the purpose is a bit unclear to me.

    • primary (boolean)
    • association (string)
    • relationship (string)
    • editable (boolean)
    • status (string - one of “linked”, “available”, “unenrolled”)

ok, I've deployed these endpoints.

you now have:

GET /users/{id}
GET /users/{username}
GET /users/{id}/activity
POST /users/{id}/lock
POST /users/{id}/unlock
POST /users/{id}/link/{mem_num}
POST /users/{id}/unlink/{mem_num}
POST /users/{id}/membership/{mem_num} ( POST body contains { "nickname" : "newname" } )

GET /members/{mem_num}
POST /members/{mem_num} ( POST body contains the items to update as you specified)
POST /members/{mem_num}/restrict
POST /members/{mem_num}/unrestrict
POST /members/{mem_num}/invite

FYI; I've implemented a GET /users/{username} endpoint that will return various info about the state of that user (i.e. password_locked, out_of_band_locked, out_of_band_locked_expiration, etc), and have also implemented a GET /users/{id} which returns much more info about the user specified by {id}. The problem is that ServiceStack has no way to know which endpoint you're after, the username one, or the id one. so for now I have it coded that if the passed in value is numeric, it is assumed to be an id, otherwise it's a username. This will work for now because, as I understand it, we've decided not to allow numeric usernames, but I suggest we rethink this approach because I have a feeling that at some point, we'll be forced to use numeric usernames (such as the member number) which will break this approach. We could do something like GET "/users?username=testuser" and GET "/users?id=123" which would solve the problem. Thoughts?

Also, I have not yet tested any of the POSTs, so when you can, I'd like to get a workable copy of your admin tool code so I can try them out.

Thanks

Thanks Joe - I'll be working my way through them and will let you know if anything comes up.

For the GET, I'm fine with passing the username in as a query param.

Ok Matt, I've updated the code (not deployed as of right now) so that you can do any of the following:

GET /users/{id}
GET /users?id={id}
GET /users?username={username}

In the even that both username and id are supplied, the username will be ignored.