Additional filters for search by form

If you have questions or if you want to share your opinion about Aware IM post your message on this forum
Post Reply
pbrad
Posts: 781
Joined: Mon Jul 17, 2006 11:03 pm
Location: Ontario, Canada

Additional filters for search by form

Post by pbrad »

Hi,

I really like the ability to define a form for the parameter selections for a query however, is there a way to further filter the query results?

For example, use a form for the user to select Client.FirstName and Client.LastName from the form but the Client.Country is embedded into the query so as to limit records to something like Client.Country=LoggedInRegularUser.Country

Thanks,
Pete
aware_support
Posts: 7525
Joined: Sun Apr 24, 2005 12:36 am
Contact:

Post by aware_support »

Not sure I understand. Why can't you make first two parameters - "ask at run time" and hardcode the third?
Aware IM Support Team
pbrad
Posts: 781
Joined: Mon Jul 17, 2006 11:03 pm
Location: Ontario, Canada

Post by pbrad »

Unless I am way off base, if you select a form for the first two parameters of the query, you no longer have the option to define the third parameter because the 'Where' section disappears and the rule table tab is greyed out as soon as you click on the 'Use Form' checkbox.

Pete
aware_support
Posts: 7525
Joined: Sun Apr 24, 2005 12:36 am
Contact:

Post by aware_support »

I understand now. No, you can't do this with the query form. The only way is to use parameters at run-time. The user interface for the parameters entered at run-time is more flexible in version 4.0 - Aware IM will use the controls applicable to the attribute being entered. Not quite the same as using the form, though.
Aware IM Support Team
pbrad
Posts: 781
Joined: Mon Jul 17, 2006 11:03 pm
Location: Ontario, Canada

Post by pbrad »

Okay, that is what I thought but no harm in asking.

Thanks as always,
Pete
pbrad
Posts: 781
Joined: Mon Jul 17, 2006 11:03 pm
Location: Ontario, Canada

Post by pbrad »

Hi,

I have run into another issue with V4 which likely has to do with my current approach and I just need to find a new approach, I would appreciate if you could point me in the right direction.

The following is a simple example of where I am having a problem:

Old method:
Situation: I want to run a month-to-date report that is parametric. The report data has three filters
1. Beginning date of the report (user selectable but default value is the first day of current month)
2. End date of the report (user selectable but default value is the current date)
3. Report data is filtered for LoggedInRegularUser.HomeOffice (not user selectable)

Solution: I typically create a non-persisted business object, let's call it Mtdreportparameters with BeginningDate and EndDate attributes. I then attach rules to that BO to push the default values into the fields and to call a process if the BO is new to call the report. The report is based on a query that has the following criteria
1. AnotherBO.Date<=Mtdreportparameters.BeginningDate
2. AnotherBO.Date>=Mtdreportparameters.EndDate
3. AnotherBO.Office=LoggedInRegularUser.HomeOffice

So the user selects menu item called MTDReport which creates the Mtdreportparameters non persisted business object. When they hit submit the process is called which creates the mtd document which is based on a query that looks to the mtdreportparameters BO which is still in context for the criteria.

Problem:

This approach has always worked well but now with V4 I get the following error:

"The server may have started a process that requires interaction with the user. This is disallowed in the current context. Please check your configuration to make sure that there are no rules attached to an object that start a process requiring user interaction."

In searching the forum, I found this reponse to a similar issue:

"Thanks, Tom. We investigated this as well. There is a bug in version 4.0 that we will fix shortly - it does not allow you to start a process from rules attached to a business object.

BUT it is NOT a good idea to do this - while version 3.0 allows this and version 4.0 has a temporary bug in this area, you should AVOID running a process from within the rules attached to an object. This goes against the guidelines of Aware IM configuration.

In this particular case if you need a process then this process should control the creation of the object and the user should NOT be allowed to create an object other than going through the process.
_________________
Aware IM Suppport Team
--------------------------------------------------------------------------------
Further to my previous reply - this only applies to processes that invoke user interface operations. Processes that do not require interactions with the user can be called from rules of an object.
_________________
Aware IM Suppport Team"

So...

I am fine with this restriction but it means that my current approach is unusable and so is the approach to use the 'use form' checkbox because I wouldn't be able to stipulate the LoggedInRegularUser.HomeOffice criteria.

The 'Ask at runtime' option would allow me to stipulate the above criteria but would not allow me to set the default values for the report beginning and end dates. (which are appreciated productivity enhancements for users)

This is just a simple example, but I have come to rely quite a bit on using non-persisted business objects to give me full control over presenting the parameters of reports and queries. I can add static or dynamic dropdown lists, run rules against their inputs etc...

Any idea how I can achieve the same results in V4.

Sorry for the long post but it hopefully will save a bunch of responses asking for more info.

Cheers,
Pete
tford
Posts: 4238
Joined: Sat Mar 10, 2007 6:44 pm

Post by tford »

Pete,

I THINK the solution is actually pretty simple.

You can actually just store the report parameters in the RegularUser BO and use this in the query:

1. AnotherBO.Date<=LoggedInRegularUserMtdreportparameters.BeginningDate
2. AnotherBO.Date>=LoggedInRegularUserMtdreportparameters.EndDate
3. AnotherBO.Office=LoggedInRegularUser.HomeOffice

So, your menu item would call a process that would:
1- Edit the values of report parameters stored in LoggedInRegularUser
2- Run the reports

The neat thing about this approach is that the user will see the last values of the report parameters when they run the report. The last values will be the default. Of course, if you want some other values to be the default report parameters when the menu item is chosen, you can put the appropriate run in the process.

Each user's report parameters are then independent of each others & would also carry from session to the next by default.

Hope this helps.
Tom
pbrad
Posts: 781
Joined: Mon Jul 17, 2006 11:03 pm
Location: Ontario, Canada

Post by pbrad »

Hi.

Yet again, it is a good thing that we are in different time zones as it allows me time to digest my post, think about it and try more solutions.

In this case the solution to my dilemna was simple. Instead of using the menu item to create the non persisted business object and then call the process to create the document from rules in that business object I just needed to call the process from the menu item and add 'ENTER NEW mtdreportparameters with mtdreportparameters.BeginningDate=..." as the first step of the process. In hindsight this would have been a more elegant way of handling it all along.

Sorry to bother you,
Cheers,
Pete
pbrad
Posts: 781
Joined: Mon Jul 17, 2006 11:03 pm
Location: Ontario, Canada

Post by pbrad »

Thanks Tom,

We posted at the same time so I missed your response. Your concept is a good one too and I may use that in other instances.

I guess that the key message here is that if you are going to use a process that is going to end up changing what is on screen, you need to start off everything from that same process rather than from a form.

Cheers,
Pete
christopherb
Posts: 304
Joined: Fri Jun 22, 2007 8:26 pm

Post by christopherb »

Pete,
We handle most, if not all, reports in the manner as you figured out. With form(s) to match any needs for the user from the non persisted object. What it is nice when running date sensitive reports is the last value will be shown to the LoggedIn User for their own reference.

Cheers,
Cheers,

Christopher
Post Reply