Queries dont reflect PROTECT actions. As Designed (SOLVED)

ddumas

I am finding that Business Rules that use the PROTECT or READ PROTECT actions are not "respected" by queries.

For example, I have a Visual Perspective for the Member Access level, which displays Events. Members (have Member access level) attend Events. An event organizer chooses specific Members to attend a specific Event.

I do not want Members who login to see Events for which they are not attending . An Event has Attendees, chosen by the organizer. I added a Business Rule to READ PROTECT Event from Member if that Member is not one of the attendees.

In the visual perspective, I have a QUERY that shows all Events. I had thought that the Event READ PROTECT Business Rule above would have "blocked" Events from the query to display if that LoggedInMember was not an Event Attendee of the Events returned by the query.

I realize that I can recode the Query with a WHERE condition to satisfy blocking those Events from displaying.

If that's the only way, and if the PROTECT actions are only executed in Forms, and not queries, then it seems that you have code to WHERE conditions in every query that you need this READ PROTECTion?

Or is there another way to have use queries to reflect READ PROTECTion?

Dave

Jaymer

1st - its does work with queries.

2nd - Another consideration, and I'd encourage you to use your SQL skills to thoroughly analyze this with SQL Profiler, is to determine exactly HOW Aware uses RP to do the filtering. You're prolly going to see that it reads all records exactly as your Query's FIND stmt says, and then logically filters them in Aware. This is an undocumented, vague area in Aware. Not sure if its a strategy to use in a production environment.
Does it work in a demo video - sure.
Does it work if you have a small system with not many records - sure.
But the jury's out beyond that.

You have a VP for members.
So prolly a unique "redundant" Event query for a Member and another for Non-Members.
Just as easy to FIND Events where Member IN Events.pm_ Attendees
than to rely on some Aware voodoo where queries MIGHT start getting longer and longer as the # of rows increase.

ddumas

AH - so sounds like PROTECTs are just evaluated in CREATEs/EDITs/ENTER NEWs - essentially I am thinking anything that is under "edit". That makes sense as awareIM would otherwise have to handle the blocking of displayed rows internally, which would be performance expensive.

Good suggestion on profiler - will try that.

I also wondering if maybe queries are best handled through stored procs - I will have to looking to the syntax usage of stored procs with AwareIM. Regardless, as you say, queries do not just automagically "inherit" PROTECT logic.

Dave

ddumas

So, here is what I found (so far):

Here is my READ PROTECT rule in Event:
IF NOT(Event IS NEW) AND COUNT EventAttendees WHERE (EventAttendees.Event=Event AND LoggedInMember = EventAttendees.Member)=0 THEN
READ PROTECT Event from Member

When a Member logs into the VP for Member, the below QUERY did not "inherit" the above READ PROTECT rule in Event:
FIND ALL Event ORDER BY Event.TimeScheduled
All Events were displayed, even those where the LoggedInMember was not attending.

When I changed my QUERY to this below, the Query worked (as expected):

FIND Event where EXISTS EventAttendees WHERE (EventAttendees.Event = Event AND LoggedInMember = EventAttendees.Member) ORDER BY Event.TimeScheduled

This seems to indicate that an AwareIM QUERY does not "inherit" READ PROTECT rules for the BO. If true, that's ok, because if it did, I believe performance would suffer in AWAREIm

I have not done profiler or stored procs yet, stay tuned 🙂

Dave