Scope of Variable on Query results

mugum

I have a query that lists issues per meeting on right clicking the meeting.
Once these issues are listed( results of the query), I need to be able to create a new issue from the query results. I can attach a process to the query results form to initiate this process.

My problem is that I have to assign to this new issue the name of the meeting, but the name of the meeting is out of scope at this point. The user should not be required to re-attach the issue to a meeting, the system should know that because the issue is being created from a list of issues from a particular meeting, then this new issue belongs to the meeting in question.

Thanks,

Mugu

tford

Assuming the Meeting is in context, use the syntax ENTER NEW Bo WITH.

I think there might be an example of this in the Library sample application.

tford

Just realized that you said that Meeting was "out of the scope" .. I assume you mean out of context.

You could have the user select the Meeting for the query using a RegularUser form & use LoggedInRegularUser.SelectedMeeting in both your Query and the process to create a new issue.

mugum

Thanks Tom.

When I right click on a meeting in the calendar, I activate the query that returns issues related to that meeting. At this point the meeting is known(in context). But as soon as the results are displayed the meeting is out of context because I'm no longer dealing with an appointment.

Is there a way of using a temporal variable where I can store the meeting name from the time I right click the meeting , then I can use it when creating a new Issue from the query results forms?

Thanks,

Mugu

tford

I activate the query that returns issues related to that meeting.

Is this run by a process? What is the FIND for the Query?

Do you know you can also add a Right Click option to the calendar appointment to add a new issue?

mugum

Yes this is run by a process.
Yes I know I can add a new issue on the calendar right click. I am currently returning the Issues for a right clicked appointment using this approach.

This is the query:FIND Issue WHERE Issue.Appointment.Subject=ThisAppointment.Subject AND Issue.IssueType='IssueToResolve' AND Issue.Appointment.StartTime=ThisAppointment.StartTime ORDER BY Issue.OpenedOn DESC

Appointment is known at the time I right click on it. Then the results are on a table(query results). From this query results I have attached a process that enables me to create a new issue. But when this form pops up, I want it to know that it is associated with the ThisAppointment on the above query.

Thanks

tford

1) Create attributes in RegularUser BO that identify a selected Appointment (Subject, IssueType, StartTime)

2) In the beginning of the process, store the info from the selected Appointment in attributes from #1

3) Use these new attributes in your query & they will also be available for when you create the new instance of Issue

mugum

Thanks Tom, that solves my variable scope issues 🙂 .

Bryan

Thanks Tom for a great work around for figuring our context in the scope of a chain of processes/rules. I am sure I will be using this in the near future.

To expand upon Tom’s original idea for context issues which I know we all run into:

It seems like we would do well to have global generic context place holders. BO shortcuts that can store any BO type on a temporary basis which could be referred to in process chain and cleared through a global function call to clear the cache.

I could see it working like this:

1 – rule that fires from selected BO – call to store selected BO in context1
2 – process triggered by the rule 1 which triggers a find statement and allows user to select another BO – call to store BO in context2
3 – process to create another BO in response to actions in 1 & 2 above which uses values from context1 & context2 and then a statement at the end of the process that clears the cache.

You could expand this to store as many context variables as needed for a particular process chain. Similar to Tom’s solution without the need to create an attribute at the RegularUser object level for each BO in your business space that needs this type of context processing.

Support,
Is there other ways to handle context that you would suggest for this build that have not been mention already?

Again thank you Tom for a great way to handle context.