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
NOT GOOD - AwareIM let one member delete another
Re: NOT GOOD - AwareIM let one member delete another
You need to look at using 'groups'.
Use a similar rule where regularuser weeds out duplicate login names.
Use a similar rule where regularuser weeds out duplicate login names.
Avid Linux user....
Re: NOT GOOD - AwareIM let one member delete another
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
Dave
Re: NOT GOOD - AwareIM let one member delete another
So what happens when you do this?
IF Member.ID <> LoggedInRegular.user.ID THEN
REPORT Error 'Testing Rule'
?
IF Member.ID <> LoggedInRegular.user.ID THEN
REPORT Error 'Testing Rule'
?
Avid Linux user....
Re: NOT GOOD - AwareIM let one member delete another
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
I am happy to try as a test though...
Dave
Re: NOT GOOD - AwareIM let one member delete another
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
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
Re: NOT GOOD - AwareIM let one member delete another
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.
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.
Avid Linux user....
Re: NOT GOOD - AwareIM let one member delete another
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
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
-
- Posts: 1460
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: NOT GOOD - AwareIM let one member delete another
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.ddumas wrote: In a process I had a rule coded as DELETE OnlineMeetingttendees.Attendee. OnlineMeetingAttendees.Attendee is data type 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 all
IF OnlineMeetingAttendee.Attendee=LoggedInMember THEN REPORT ERROR '[your delete error message]'
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
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.From the manual wrote: Protecting attributes of referred objects is not allowed, for example the action PROTECT Transaction.Account.State FROM ALL is invalid.
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
Re: NOT GOOD - AwareIM let one member delete another
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
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
-
- Posts: 1460
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: NOT GOOD - AwareIM let one member delete another
Delete Rules are your friend in that case (which unfortunately doesn't help you at the moment).
Re: NOT GOOD - AwareIM let one member delete another
??? I am not following you on that. I am definitely going to log this as a bug. Essentially the bug is: DELETE action ignores PROTECT Business Rules of the BO in the Delete.
Dave
Dave
Re: NOT GOOD - AwareIM let one member delete another
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.
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.
Re: NOT GOOD - AwareIM let one member delete another
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.
Re: NOT GOOD - AwareIM let one member delete another
Thanks - I will try that and get back.
Dave
Dave