Does IMPORT place the BO instances in context?

JonP

When a user is created in the system, I create a temporary password that is emailed to the user in the form of a URL so they can auto-login and change the password. When I set a password in an attribute that has the property "password", it encrypts it, which is good. But that creates a problem if I want to build a URL with that password.

So first I create the password in a NP BO that doesn't have the "password" property. That way I can assign it to the password attribute and use it to build the URL. That works fine except when the users are imported en mass from a CSV file.

I assumed (yeah, I know) that IMPORT is like a fancy CREATE. So I figured the instances created would be added to the context. But when I do this in a process...

IMPORT Person FROM ImportData.FileLocation WITH VALIDATION USING 'Person Import Template'
CREATE SetPassword
Person.Password=SetPassword.TempPassword
Person.TempURL='https://cm.plantain.io/app/logonOp.aw?e='+ENCRYPT_B64('domain=Plantain&userName='+Person.EmailAddress+'&password='+SetPassword.TempPassword+'&testingMode=false')

...I get the "Possibly wrong object identifier" message relating to the BO that I imported. When I run the app, the BO instances are not updated.

Jaymer

John, your rules should fire in the person business object.
So put something there that looks for when person IS NEW and then your calculations there.
That’s one of the things that slows down imports so much is all of those rules fire.

Also, I have emailed links (encrypted) as well with a password, and I have not had to jump through the hoops that you are with a temporary BO.

Jaymer

JonP

Thanks Jaymer, that's helpful to know that password can be passed unencrypted. I don't know why it was encrypting for me. I'd rather avoid the hoops, so I'll try again.

I was hoping that IMPORT instances were placed in context so I could insert the few rules I needed in the process and ditch WITH VALIDATION to speed it up. Oh well.

tford

I have a BSV that creates unique links that are sent to parents to sign up for parent / teacher conferences. In this case, passwords are created randomly because the only way a parent will log into the BSV is through clicking an link on an email sent to them by the system.

The login link is encrypted using the following rule:
Parent.Login_link='http://awareim.domainname.com:8080/AwareIM/logonOp.aw?e='+ENCRYPT_B64('domain=PTConference&userName='+Parent.LoginName+'&password='+Parent.Password_Text+'&testingMode=false')

Jaymer

JonP wrote
Thanks Jaymer, that's helpful to know that password can be passed unencrypted. I don't know why it was encrypting for me. I'd rather avoid the hoops, so I'll try again.

Jon, I'm not sure thats true - or if we're exactly on the same page there.

I also have links similar to Tom's. Here's one:

OutgoingEmail_LandingPage.Message='<a href='+
'https://'+
SystemSettings.SystemURL+
'logonOp.aw?e=' +
ENCRYPT_B64('domain=CRM&userName=LandingPage&password=temp6983&testingMode=false&
firstCommand=startProcess2,LandingPage,Tenant,'+Tenant.ID+',main')+
'>Landing Page Link </a>'

This didn't generate a password, rather its a common "public" landing page that someone uses to request more information. Its logs into a system account, captures info and then stores it in the database. I didn't want to use the Guest account login (doesn't allow parameters) as I MUST have some identifier passed in so I know which tenant to attach the entered information. (Guest would have worked fine in a non-Multi-Tenant app.) Point is, you can see the password above. Its still gets encrypted, but only once. not the "double" encryption issue if you're using the Generate_Password function. Thats why you guys have the "password.text" field. I just wanted to supply another working example into the thread.

JonP

Ah, I see now. Yes, if I hard-coded it as you did Jaymer or if I used a non-password-propertied attribute as you did Tom, then there's no double-encryption issue. But it's not as secure as if it were randomly-generated in a NP BO so that the unencrypted password never leaves RAM and gets quickly garbage collected. I suppose I can live with hard-coding since only people with access to the code will know or having an unencrypted password attribute that gets cleared as soon as I'm done with it.

tford

Interesting example, Jaymer, in having a public landing page to gather info. Thanks for sharing!

Jaymer

Thanks Tom,
Normally a word press site has a form that you know captures your name and email so they can add you to a mailing list and send you more info. Then we would’ve had to of import into aware.
So I just figured let’s go to aware directly.
That really was a pain to figure out because of the limitations that I pointed out, that if you’re using the guest login, then you really have no idea where to put this information in a multi tenant situation.
I’m glad I got it worked out, but there are a few weird things.
1) if you go to a word press site and then it takes you to that form with the input fields, it’s immediate. When you go to my webpage you get a little spinner for a sec and it actually has to log you in to Aware and go to that visual perspective.
Of course logging into a real account versus Guest isn’t the issue because even a Guest gets physically logged into Aware.
2) since we are putting the link to Aware in an I-frame, I’ve got some tweaking to do still with the size and color. The background color needs to match better the website etc. We’re actually supposed to be messing with that later today.