• Replies 5 replies
  • Subscribers 247 subscribers
  • Views 74 views
  • Users 0 members are here
Related

Create Additional Login for a User

Simon Davidson
$organization

I want to use the WebAPI to add another login to an existing constituent however I can't find an obvious way of doing this, without resorting to ExecuteLocalProcedure.

I thought UpdateLogin was close but it seems that will replace the current login.  Does anyone know a procedure I can use?

If we have to resort to a LocalProcedure are there any considerations I need to make with a user having two logins?

Thanks

Parents
  • $organization

    Hi Simon,

     

    There is no API method that will create a login on an existing customer account.  A local procedure is the direction you would have to take for something like that.  The API only allows new logins to be created via the Register method which of course also creates a new customer account as well (which you do not want in this case).  

     

    I will add that if the reason you are adding additional logins to the customer is because the account represents a household where multiple individuals will need to login, this should not be an issue under v11.  We anticipate that you would keep your logins under the individual’s account, so each individual in the household would only have one login on their record.

     

     

    Gregg Stickney

    Application Support Specialist

    Tessitura Network

    +1 888 643 5778 x 318

    gstickney@tessituranetwork.com

     

     

    From: Tessitura Web Forum [mailto:forums-tessitura-web@tessituranetwork.com] On Behalf Of Simon Davidson
    Sent: Wednesday, November 16, 2011 9:53 AM
    To: Gregg Stickney
    Subject: [Tessitura Web Forum] Create Additional Login for a User

     

    I want to use the WebAPI to add another login to an existing constituent however I can't find an obvious way of doing this, without resorting to ExecuteLocalProcedure.

    I thought UpdateLogin was close but it seems that will replace the current login.  Does anyone know a procedure I can use?

    If we have to resort to a LocalProcedure are there any considerations I need to make with a user having two logins?

    Thanks




    You were sent this email automatically because you subscribed to the Tessitura Web forum. You may reply to this message to post to the Web forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

  • $organization in reply to Gregg Stickney

    Hi Gregg,

    Thanks for your response.

    Were not really worried about the new constituent model as it only impacts 0.3% of our data!  What were investigating here is Facebook connect.  The way we are setup currently is that there are 2 organisations setup to access a single Tessitura instances (without control groups), and customer logins are shared between the two sites.  Customers have got used to this and know that a single login gets them onto both sites.

    What has now happened is that one organisation has had a budget approved for a new website, and one of the features they want is Facebook Connect logins.  The way the developer has said this works is that when a brand new user registers on the site, fake Tessitura login details are created and stored in a seperate database.  However when an existing user opts to add Facebook Connect to their existing account, there existing details are stored in the seperate database.  Now if that same user, goes to the 2nd organisation, logs in with their old details and decides to change their password, they break the login system...so not good.

    So what I was trying to do, is that when an existing user adds Facebook Connect, rather than changing existing login details, additional ones are created.  That way they can still use their old username on the 2nd organisations site without causing any issues.

    If the only way to do this is via ExecuteLocal that's no problem as the stored procedure is relatively simple to write, I just didn't want to re-invent the wheel...

Reply
  • $organization in reply to Gregg Stickney

    Hi Gregg,

    Thanks for your response.

    Were not really worried about the new constituent model as it only impacts 0.3% of our data!  What were investigating here is Facebook connect.  The way we are setup currently is that there are 2 organisations setup to access a single Tessitura instances (without control groups), and customer logins are shared between the two sites.  Customers have got used to this and know that a single login gets them onto both sites.

    What has now happened is that one organisation has had a budget approved for a new website, and one of the features they want is Facebook Connect logins.  The way the developer has said this works is that when a brand new user registers on the site, fake Tessitura login details are created and stored in a seperate database.  However when an existing user opts to add Facebook Connect to their existing account, there existing details are stored in the seperate database.  Now if that same user, goes to the 2nd organisation, logs in with their old details and decides to change their password, they break the login system...so not good.

    So what I was trying to do, is that when an existing user adds Facebook Connect, rather than changing existing login details, additional ones are created.  That way they can still use their old username on the 2nd organisations site without causing any issues.

    If the only way to do this is via ExecuteLocal that's no problem as the stored procedure is relatively simple to write, I just didn't want to re-invent the wheel...

Children
  • Former Member
    Former Member $organization in reply to Simon Davidson

    Hi Simon

    You're probably already aware of this gotcha, but if both logins are associated with the same email address, they'll need to have different Login Types - shouldn't be a problem if your'e creating them with a Local Proc.

    But if I was doing this, I guess I'd be asking why the FB Connect details couldn't be stored in the Tess database anyway - so they could be used by any website, not just the one that has the data stored. It should be easy enough to write some code to store and retrieve them, on the same basis as handling other local data.

    Ken

  • $organization in reply to Former Member

    Hi Ken,

    Thanks for your reply.

    I had already created a seperate login for this, and applied a control group to it so staff in house couldn't accidentally break it.

    You've raised a good point about where the Facebook Connect details are stored, thanks for your advice will raise this with our developers.

  • $organization in reply to Simon Davidson

    I'm not sure if this helps but when I implemented facebook connect on the Bell Shakespeare website, we decided to ignore trying to associate the login with an existing account.

    All facebook logins created a new account and the facebook login (123456@facebook.com) was stored against a Facebook login in the customer account.

    We'd then merge these accounts with existing accounts where possible.