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
IF 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.
