Navigation after create

[[email protected]]

How do you navigate to a record created via the Create statement from within a process.

I have a data entry form that on change of one of the fields will result in a duplicate record being created. I accomplish this by executing a process within a rule from the currently referenced BO The process uses the CREATE function to create the new BO. Once the object is created, I would like the user to be presented the new BO in Edit mode. I have tried the EDIT BO right after the create, but Aware doesn't like that.

How should I implement this type of functionality?

[BobK]

Try

ENTER NEW BO WITH BO.attribute = 'value'

[thom]

rgates,

this is definitely a tough one. I played around for a bit trying to get this one to work and I couldn't

If I understand this correctly, you have a "WAS CHANGED" rule on a attribute. The rule creates a "duplicate" record. I got this to work with both a CREATE and an ENTER NEW. The problem comes when you want to edit the dup record you just created.

We need to find a way to change the existing context to another instance of the same BO - Aware does not seem to let you change the context in mid process.

[[email protected]]

Yes, ENTER NEW and CREATE both result in the same error regarding user interaction.

In the past what I have done is just present the user with a query showing the record that was just created. While this works, it is a bit cumbersome.

[tford]

I have not tested this, but here are some thoughts.

1) Instead of having the WAS CHANGED rule try to create a duplicate record & then EDIT it.... have the rule just create the duplicate record and set a flag in RegularUser BO that it was created. You could also store the ID of the newly created instance.

2) In the process that's running your data entry form, add another step to look for the RegularUser flag and ID. If the flag exists, then VIEW the newly created instance. At the end of this process, you should also clear the flag.

[[email protected]]

Hi Tom.

I'm a little confused how this is any different then what I am doing. Right now the only thing the rule WAS CHANGED is doing within the BO is calling the process. The process itself CREATES the record and then tries to EDIT it. I originally had the CREATE in the BO rule, but thought that might of been the problem so that is why I moved the CREATE to the process.

[thom]

Tom,

your suggestion was the same angle I was working, although I was using systemsettings to hold my newid - still i could not get it to work, but I'll drop the WAS CHANGED rule and try using RegularUser

[tford]

Thom,

From your earlier post:

We need to find a way to change the existing context to another instance of the same BO - Aware does not seem to let you change the context in mid process

Have you tries THIS or THAT prefixes?

[thom]

I did use THIS but not THAT ....never ran into a case where i needed THAT. Just as good of time as any to discover its usage.

[tford]

Be careful in your usage of THIS and THAT .... check out the User Guide. THIS is for the first instance of the BO put into context & THAT is for the second instance of the BO put into context.

[thom]

Tom,

I got this to work (outside of the WAS CHANGED) using THIS and THAT. It was pretty straight forward with your coaching.

2 Step Process(pDupRecord)
1). CREATE NEW BO WITH BO.ATTR1=ThisBO.ATTR1, BO.ATTR2=ThisBO.ATTR2,...
2). EDIT ThatBO USING MAIN (you can also use VIEW ThatBO...)

now, when I call this process from a rule
IF BO.ATTR3 WAS CHANGED Then pDupRecord

I get a error message "Unable to edit/view unresolved object"

[tford]

My understanding is that you can NOT initiate UI stuff from rules.... either directly or indirectly.

[tford]

Try this:

BO attributes:
1) RegularUser.BOid - Number type
2) BO.Att1 - Plain Text
3) BO.Copy - Yes/No

BO rule:
If BO.Copy='Yes' Then
CREATE BO WITH BO.Att1=BO.Att1,BO.Copy='No'
LoggedInRegularUser.BOid=ThatBO.ID

Process:
LoggedInRegularUser.BOid=0

VIEW BO USING Main

If LoggedInRegularUser.BOid<>0 Then
FIND BO WHERE BO.ID=LoggedInRegularUser.BOid

If LoggedInRegularUser.BOid<>0 Then
VIEW BO USING Main



*** Run this process from a Query that lists all BO instances.

[technopak]

Hi,

If I'm understanding what you are trying to do, this is how I'd do it -

1. Create a SystemSettings attribute of type YourObject - ie a reference.

2. Create a rule on YourObject which sets the SystemSettings.YourObjectRef attribute to your newly created (or edited) object.

3. Use a FIND action to put the object referenced in SystemSettings in context.

4. Edit YourObject

So, YourObject should have a rule like this -

IF YourObject IS NEW THEN
SystemSettings.YourObjectRef=YourObject

and your process should contain the following rules -

ENTER NEW YourObject using Main
FIND YourObject WHERE SystemSettings.YourObjectRef = YourObject
Edit YourObject

You can also apply this technique to edited objects. The key thing is that you cannot call a user interaction from within the rules of an object - hence the need to finish off the create process before you edit the object.

This works for me anyway

Peter

[tford]

Sounds like you are are the right track, Peter.

I always store variables like this in LoggedInRegularUser & not SystemSettings though.

In a multi-user scenario, you could theoretically end up editing another user's record is you store it in SystemSettings.