Extended Searches (Unwanted Query Links)

[aware_support]

Looks like a bug - it should work and it should export everything that on the screen. We'll investigate and post a message here.

[john]

Thanks very much for that. While your there the printing doesn't appear to be working either.

I have the code:
PRINT DOCUMENT CustomSearchesTempDoc
Where the document should be a Report on whats on the screen (Data Determined At Runtime For The Report) I think?? It also says operation successful but nothing happens. I realise this could be me?

Thanks
John

[aware_support]

What does the LogViewer and Aware IM Server output say?

[john]

A HA . .

Silly me. It is working. It is just printing from the server PC and exporting to the Server C drive. I didn't expect this. As I am running in a hosting environment I am not regularly in front of the server.

I do require this to go from to the client PC. Is this easy to do for both cases?

Also my comment about exporting what is on the screen was not understood.

My Code for the process:
EXPORT Temp TO 'c:/TEMP/Test.csv'
Is it not possible to replace the word "temp" with a reference to the current data i.e.
EXPORT <<CURRENT DATA>> TO 'c:/TEMP/Test.csv'
something to that affect. Does the information currently stored in my query results not have a name that I can reference (in my process) instead of referencing "Temp" (my business object). The reason why I keep asking is because it would be nice if I could use the same process for all of the my forms, which I am now creating to get rid of the "UNWANTED QUERY LINKS" and Record Count problem.
Do I have to write a seperate process referencing each Business Object for my export commands?

I really hope that makes sense because I would really like a definate yes or know on this one

Thanks
John

[aware_support2]

> Is it not possible to replace the word "temp" with a reference to the current data ...
No. Export action needs a specific object type. You do need a separate process for different object types. In addition, the instances to be exported must be first placed in the context, which can be done by running a query. If you want to run a process that exports data, the process should have a couple of rules like these:

FIND Temp WHERE (...)
EXPORT Temp TO 'c:/TEMP/Test.csv'

The process must include the query step even if it is started from a presentation that displays the instances you want to be exported. The query in the process should be the same as the one used to display the presentation.

> I do require this to go from to the client PC.
You need to add a document template (say, called MyTempData) of type Text containing a tag with LINE function in it as described earlier in this topic. Then your process will have only one rule in it:

DISPLAY DOCUMENT MyTempData

The results will be displayed in the web browser on the client PC so the user may save the results to a local file, copy/paste into another application, etc.

[john]

Hi

Thanks for that. I couldn't understand this because the export button on the Standard Forms allows the user to specify the location where the Exported CSV would be saved to. Things are obviously a lot more difficult when you intend using your own forms.

A much quicker way would just be to allow the developer to choose what links are available on the standard forms some how, but that is just a suggestion.

I will put this one to bed now

Thanks for all your help
John

[aware_support]

We fixed the invalid count problem in read protection starting from build 862

[ab042]

I was looking forward to this one. Thank you

But it doesn't appear to be working. I republished and edited both the query and the BO and republished and it still shows like it did in previous versions.

Is there something else we need to do for this COUNT fix to work?

[aware_support]

How does your READ PROTECT rule look like?
(there are still some limitations here and your case may fall into this category, but maybe there is a way to modify your rule to avoid the limitations)

[ab042]

If LoggedInSystemUser.AccessLevel<>'Administrator' AND
Contact.Division.Division<>LoggedInSystemUser.Division Then
READ PROTECT Contact FROM ALL
===================
Before I started screwing with it, it was work (same as before latest build) and was showing the records correctly just the wrong counts.

Now since I've been playing with it I can't get the restrict to apply at all. Regardless of what I search for its wrong and it appears to display most if not all the records all the time. If I remove the above rule all the searches for the different queries work except they shows what should be restricted records to the users.

FYI: It would be very helpful if the LOG showed the action on this rule. I could better debug. I also noticed that the LOG settings don't always appear to stick and I find myself setting the log options from time to time as I go in and out of the log view.

[aware_support]

The Log Viewer must show these actions - they are under a special node that precedes the node with all other rules. Please check out the output of the log viewer and the Aware IM server - it must have a clue to why this doesn't work (or send it to us).

There is one suspicious construct in your rule: LoggedInSystemUser.Division. For this to work you must make sure that ALL members of the SystemUser group have Division attribute defined. Is this the case in your configuration? Or the correct construct should be LoggedInContact.Division? This could explain why this doesn't work.

You could also simplify your rule by removing the first condition and checking READ PROTECT FROM ALL EXCEPT Administrator (this shouldn't affect whether it works or not)

[john]

Hi

I am just returning because you said the record count may now be resolved. I am getting a bit bogged down making forms for everything. Could you have a look at my Read Protect rule and tell me if you see this working??

If NOT(Temp IS NEW) AND CHARS_FROM_LEFT(LoggedInAgency.AgencyID, 3) <> CHARS_FROM_LEFT(Temp.TempID, 3) Then
READ PROTECT Temp FROM Agency

It looks like this because the Temp ID's start with the first three characters of the Agency ID. For example WIN0001. This is down to another system wehave here.

If you see this working, where do I download the latest version from. Is this just the link for version 2 on the home page?

Thanks
John

[aware_support]

Checking IS NEW is a problem. Can you replace it with checking the value of some attribute that is undefined when an object is new and defined afterwards, so that instead of checking IS NEW you would check If Temp.SomeAttribute is equal to the value

If you don't have such an attribute you can create one - don't show it on forms but add a rule that would initialise this attribute when an object is new: If Temp.SpecialAttribute IS NEW Temp.SpecialAttribute='Some value' and then check for Temp.SpecialAttribute='Some value' in READ PROTECT rule.

Are you using Derby? If so, CHARS_LEFT would be OK.

You see, we are now adding read protection conditions to every query automatically, so that we can know the valid count after executing the query. The problem is that not all conditions that can be used in rules, can be used in queries - for example, such conditions as IS NEW, WAS CHANGED, some functions cannot be used in queries. When they cannot, we revert to the old way of dealing with read protection (which produces invalid count).

[john]

Hi

The code If NOT (Temp IS NEW) was given to me further up this feed because when I READ PROTECT business objects I cant enter new instances of my objects into the system.

I am getting a bit confused. I cant see how checking the status of an attribute would work as this wouldn't be created until the instance of the object was created surely?

Like I say I am cofused. I will leave you to ponder this one but for now I will carry on creating my own forms

Thanks
John

[aware_support]

Sorry for the confusion. The IS NEW advice was given to you before we added a fix to READ PROTECT.

You want the system not to protect when the object is being created. Is that right? If so, a condition that checks for the value of the attribute would return false and so protection wouldn't work when the object is being created (this condition is equivalent to checking IF NOT (IS NEW)).

After the object has been created the attribute value will have been set and so the protection condition would return true and the protection would work.