Hi -first post so go easy on me. I am trying to set up the read protect on my sample application. I have a list of customers. Each customer has a list of monitoring operations. so I have a customer BO, and a MonitorOperation BO where Customer owns multiple Monitor Operations I want the users to be able to login and see the customers and monitoring operations that belong to them I then made a customer attribute (called AllowedCustomers) on the regular user which is a peer relationship. So one regular user can be linked to multiple customers. The customer has a matching attribute called AllowedUsers Now my approach was: 1. when a customer is created, he/she is added by a rule into the user customer list 2. This should cause the customer modified event to fire 3. I have a another rule that checks when the customer.allowedusers has changed, when it is changed, I wanted to read protect all users not in the allowedusers list. I was going to do this by doing a find users where user not in the allowed users list. This (according to the doco) loads all of the users into the context, then in the next action, read protect users. (btw I mean the RegularUsers BO) This doesn't seem to be supported :( I only seem to be able to protect based on access levels, not individual users. I don't want customers to show up in any searches for users that don't have the access to those customers. I also don't want customer's MonitorOperations to show up in any searches where the owning customer is not in the user's list of allowed customers. Is there a way to do what I want? Thanks Peter

Read protect question

peterw2000

Hi -first post so go easy on me.

I am trying to set up the read protect on my sample application.

I have a list of customers. Each customer has a list of monitoring operations.

so I have a customer BO, and a MonitorOperation BO where Customer owns multiple Monitor Operations

I want the users to be able to login and see the customers and monitoring operations that belong to them

I then made a customer attribute (called AllowedCustomers) on the regular user which is a peer relationship. So one regular user can be linked to multiple customers. The customer has a matching attribute called AllowedUsers

Now my approach was:

when a customer is created, he/she is added by a rule into the user customer list
This should cause the customer modified event to fire
I have a another rule that checks when the customer.allowedusers has changed, when it is changed, I wanted to read protect all users not in the allowedusers list. I was going to do this by doing a find users where user not in the allowed users list. This (according to the doco) loads all of the users into the context, then in the next action, read protect users. (btw I mean the RegularUsers BO)

This doesn't seem to be supported 🙁

I only seem to be able to protect based on access levels, not individual users.

I don't want customers to show up in any searches for users that don't have the access to those customers.

I also don't want customer's MonitorOperations to show up in any searches where the owning customer is not in the user's list of allowed customers.

Is there a way to do what I want?

Thanks

Peter

aware_support

All you need to do is add this rule to the Customer object:

If NOT (Customer IN LoggedInRegularUser.AllowedCustomers) Then
READ PROTECT Customer FROM ...

So if a customer object is not in the list of allowed customers for the currently logged in user, it shouldn't be visible. Similar approach can be used with other objects.

aware_support

Forgot to say: once you add the protection rule Aware IM will automatically remove "invisible" instances from all searches

peterw2000

Thanks. That's a very fast response.

Can you tell me what comes after the "from"?

If I put say CustomerAccess (a new access level that all customer users have), won't that remove access to ALL customer users?

So if I have Fred and Joe, both of them work for different companies and they have logins on my system with access level "CustomerAccess"

Joe creates a new customer, the insert rule fires adding the customer he created to his "AllowedCustomers" list. Ok so far so good.

Now for the read protect, The condition is evaluated for Joe and it doesn't fire because Joe is in the list, so no read protect is applied. This part is OK as well.

At the same time we have Fred doing a search on all Customers. No read protect has been applied, so Fred sees all of the customers... right? This is not what I want.

What am I missing?

Thanks

Peter

aware_support

The part after FROM can be ALL or ALL EXCEPT Administrator.

You don't need to invent a new access level here. It doesn't matter what access level a current user has (as long as it's not the access level that is mentioned after FROM). So let's say you have two access levels - Administrator and User. The Admin. access level is allowed to see anything. The User access level obeys the access restrictions of the PROTECT rules. Your rule has to be:

If NOT (Customer IN LoggedInRegularUser.AllowedCustomers) Then
READ PROTECT Customer FROM ALL EXCEPT Administrator

So in your Fred and Joe examples Joe creates a customer and he is added to his list of allowed customers.

When READ PROTECT is evaluated it is evaluated for CUSTOMERS returned by the search, not for Joe or Fred who are users. So when the search is run initially it will return ALL customers for both Joe and Fred. However, later on some customers will be filtered out, depending who the current user is. So if only one customer was created, Joe will see it and Fred will not (because it will be filtered out for Fred - see the rule).

peterw2000

Once again , thanks for your quick reply.

I will try this.

But in the meantime, can you fill me in on the understanding side, or point me at more detailed documentation?

The rule is placed in an "when object is created or modified" section in the configuration tree, so I was assuming the rule only fired when I created or modified the user, and thereby set the protection once only until the customer was next updated.

If I'm understanding you correctly, you are saying the protect rule gets applied when the Customer is loaded by a search. Is that right?

If that is the case, then I am totally confused as to when a rule gets evaluated.

Thanks again

aware_support

Your confusion is understandable. The point is that PROTECT rules are special. All other rules are evaluated when the record is created and/or modified. PROTECT rule is also evaluated when a record is READ (as well as updated or created). Hope this clears up the confusion. This is why a simple read protection rule as described in this thread will do everything you need.

All the documentation for PROTECT rules is available in the User Guide, How To and the Rule Language Reference documents

peterw2000

OK. Thanks. That makes sense and it works exactly as you stated.

Very nice.

Is there a way to auto protect owned objects or do I need to repeat the rule for each child object?

Are there any other "special" rules that are evaluated outside of create/modify/delete?

BTW, I looked in the help and couldn't see where it says read protect is evaluated at read time, but could well have missed it.

Thanks again

tford

Is there a way to auto protect owned objects or do I need to repeat the rule for each child object?

It depends on how you intend to dispay the owned objects.

If you display them as a reference list in owner, then no special rules will be needed. In this case, if the owner is not displayed then the owned objects will certainly not be displayed.

If you display the owned objects in a query, then the owned object will need it's own READ PROTECT rule.

peterw2000

Thanks Tom. Makes sense.

I am allowing searches on the lower order object so I put a rule in and it works fine.

Do reports apply the read protect rules as well?

aware_support

At the moment protection rules are not supported in reports

peterw2000

What about queries?

aware_support

Queries are fully supported

peterw2000

OK.

So a report based on a query should be fine?

Thanks for all of your time

tford

I did some testing & it appears that reports do not respect READ PROTECT in any way. Using the "Run Query" or "Determined at run time" do not work.

The only alternative is to construct your report's query based on the same IF criteria that the READ PROTECT rule is based on.

I've send an email to support & they confirmed it's now on their To Do list.