If you have questions or if you want to share your opinion about Aware IM post your message on this forum
#52733 by ddumas
Tue Jan 14, 2020 11:00 pm
I have this rule in the Member BO. I expected this to prevent the LoggedInMember from deleting another Member.
IF Member <> LoggedInMember THEN
PROTECT Member from Member

In a process I had a rule coded as DELETE OnlineMeetingttendees.Attendee. OnlineMeetingAttendees.Attendee is data type Member. This was done by accident, and should have been coded as DELETE OnlineMeetingAttendees.
The Member got deleted when the LoggedInMember was not the Member that got deleted. The above Member based business rule at the top should have prevented AwareIm from deleting the Member.


Dave
#52735 by ddumas
Wed Jan 15, 2020 12:31 am
BO Member is in the SystemUser Business Object Group, along with RegularUser. In my application, Member is at the top of the food chain - the big Kahuna BO. That Business Rule must be bulletproof, and from what I see it is not. If one Member can delete another, then big problem.
Dave
#52737 by ddumas
Wed Jan 15, 2020 1:01 am
I did change to use the .ID's for the PROTECT, but that did not work. I am thinking Report Error is not normally something you would put in a Business Rule of a BO, since its part BO Rule processing, since it is console related and waits for user input, correct?

I am happy to try as a test though...

Dave
#52738 by ddumas
Wed Jan 15, 2020 1:44 am
So, your suggestion of:
IF Member.ID <> LoggedInRegular.user.ID THEN
REPORT Error 'Testing Rule'

worked. the Member was not deleted (good). However...
I got no message, and I think this was just intended to see if the rule was run in the Member BO. Looks like it was. However, my original PROTECT code was intended to do just that. This seems to suggest that the PROTECT code is ignored, correct?.

Dave
#52739 by intra
Wed Jan 15, 2020 2:03 am
It was just a test rule, i normally use that rule in a process to test out certain things.

I normally try and keep logic rules defined as much as possible (down to the attribute)

EG
IF 'BO <> BO1 THEN' to 'IF BO.Attribute <> BO1.Attribute THEN'

as it makes more sense (to me) that you're testing a value against another value.
#52740 by ddumas
Wed Jan 15, 2020 2:13 am
Correct, a rule like that s/b only used in a process, and as you suggested, I used that as test. That test proved that the If statement was triggered in the BO, blocking the delete via report error, BUT the PROTECT statement used inside the same IF logic was ignored.

In Summary both of these below do not work: They should. I.E. We should be able to trust that used inside a BO, PROTECT should work without fail. The Member should not have been deleted. I am going to log this as a bug.

IF Member <> LoggedInMember THEN
PROTECT Member from Member

IF Member.ID <> LoggedInMember.ID THEN
PROTECT Member from Member

Dave
#52741 by PointsWell
Wed Jan 15, 2020 3:02 am
ddumas wrote: In a process I had a rule coded as DELETE OnlineMeetingttendees.Attendee. OnlineMeetingAttendees.Attendee is data type Member.

Can I just check something. If you write DELETE OnlineMeetingAttendees.Attendee what you are actually doing is DELETE Member (ie the instance of Member) as OnlineMeetingAttendees.Attendee is in effect a synonym for Member.

Looking at the way it is coded I wonder if you are in fact wanting to remove that Member from the peer multiple attribute of OnlineMeetingAttendees, in which case you want REMOVE.

Also consider using the Delete Rules to control the deletion. If you place the rule
Code: Select allIF OnlineMeetingAttendee.Attendee=LoggedInMember THEN REPORT ERROR '[your delete error message]'

into the Delete Rules you have definitive control and you don't risk the rule becoming lost in other update rules.

This is not to say that there is not a problem with PROTECT not working - it maybe that there is an issue due to you deleting via a reference as opposed to deleting the BO directly

From the manual wrote: Protecting attributes of referred objects is not allowed, for example the action PROTECT Transaction.Account.State FROM ALL is invalid.

On a purely personal style point, I always avoid m:n relationships within Aware as these have to be resolved to two 1:m and Aware will do that in the background with a BO_REF table which it uses to store all the m:n relationships.

Also if you use peer multiple relationships to other entities as attributes on a BO then an item is either in the list or not in the list. Which is fine until you want to know things like:
  • When a member signed up to meeting
  • When a member cancelled
  • How many members cancelled this meeting/all meetings
  • How many times a member cancels
  • And on and on

If you create a separate BO to handle the Attendees (instead of an attribute on the Meeting BO) you can have a whole range of extra data that you will get asked for some day in the future when someone realises that people keep cancelling or not attending or some other measurable issue.
#52743 by ddumas
Wed Jan 15, 2020 3:49 am
Regarding:

If you write DELETE OnlineMeetingAttendees.Attendee what you are actually doing is DELETE Member (ie the instance of Member) as OnlineMeetingAttendees.Attendee is in effect a synonym for Member.

Correct, I accidentally coded DELETE OnlineMeetingAttendees.Attendee. To my subsequent horror, The PROTECT Member BO rule which should have blocked the Member from getting deleted, did not, and the Member got deleted. Since Member is at the top of the food chain for a whole bunch of child BOs, all those got deleted also. IF this is indeed a bug where we cannot trust PROTECT, it's quite a dangerous one.

Does that make sense?

Dave
#53035 by bssxfire8
Mon Feb 03, 2020 8:05 pm
Can you test this Rule in your scenario to see if it fixes your issue?

IF Member <> LoggedInMember THEN
PROTECT Member from Member AND System

I am wondering if maybe the issue is that your delete process is not running as the Member but at a System level instead.
#53037 by bssxfire8
Mon Feb 03, 2020 9:04 pm
Ok I've done some testing on this, and my earlier suggestion was correct that you must include System in the PROTECT rule, but you have to make sure you put the PROTECT rule in the Deletion Rules as well if you don't have it there already.

Who is online

Users browsing this forum: Google [Bot], MSN [Bot], PointsWell and 13 guests