setting access to business objects

ddumas

I have a Note object in which I want to allow users with access level Customer to be able to see the instances, but only the creator should be able to modify, or delete an instance.

Unless I set the access level of Note to Full Access, no none except Adminstrators can even see the Notes. Not even the creator can see the Notes created by that user. With Full access anyone can modify / delete.

Very frustrating.

Rennur

You can set this up in 'Access Levels'

tford

Some folks may use Access Level to accomplish this type of thing, but I prefer to use PROTECT rules so I have complete visibility right in the BO rules of all aspects of controlling BO / attribute access.

I have an attribute that tracks who created the instance of the BO.

ddumas

Rennur wrote
You can set this up in 'Access Levels'

I tried that. The delete icon still appears at the row level for users that did NOT create the instance. So that only blocks an edit - does not block the delete.

ddumas

tford wrote
Some folks may use Access Level to accomplish this type of thing, but I prefer to use PROTECT rules so I have complete visibility right in the BO rules of all aspects of controlling BO / attribute access.

I have an attribute that tracks who created the instance of the BO.

I tried that also:

I added this as a business rule to the ProjectApprovalStatusNote object.

if ProjectApprovalStatusNote.AddedBy<>LoggedInEmployee then PROTECT ProjectApprovalStatusNote FROM ALL EXCEPT Administrator

I then logged in as an Employee (Systemuser) different than ProjectApprovalStatusNote.AddedBy

I was able to delete a note created by another user, so the business rule DID NOT work, as coded.

Rennur

I personally prefer & use PROTECT as Tom suggested.

In Access Levels you would need to restrict access to this object for all, except the Customer then you can use PROTECT rule like

If Note.CreatedBy.ID<>LoggedInEmployee.ID Then PROTECT Note FROM ALL

Rennur

Make sure the other login does not have Administrator rights

ddumas

Rennur wrote
Make sure the other login does not have Administrator rights

I did that - they both have Customer access. The only difference in the code I used (my response to Tom) and yours is that you used .ID in your comparison code and I just compared the objects without .ID

I will try with .ID and see if that works.

Rennur

LoggedInEmployee can be a 'Calculated' attribute.

Object RULE for the ProjectApprovalStatusNote.AddedBy when creating a new object:

Example,

If ProjectApprovalStatusNote IS NEW AND
ProjectApprovalStatusNote.AddedBy IS UNDEFINED
Then
ProjectApprovalStatusNote.AddedBy=LoggedInEmployee

This will ensure the AddedBy is DEFINED when you create the object, then the PROTECT rule should work

Rennur

LoggedInEmployee can be a 'Calculated' attribute.

CORRECTION:
ProjectApprovalStatusNote.AddedBy can be a 'Calculated' attribute.

ddumas

Rennur wrote
LoggedInEmployee can be a 'Calculated' attribute.

Object RULE for the ProjectApprovalStatusNote.AddedBy when creating a new object:

Example,
If ProjectApprovalStatusNote IS NEW AND
ProjectApprovalStatusNote.AddedBy IS UNDEFINED
Then
ProjectApprovalStatusNote.AddedBy=LoggedInEmployee
This will ensure the AddedBy is DEFINED when you create the object, then the PROTECT rule should work

I do that when I create the Note. I am going to revise my PROTECT code to use .ID as you did, and let you know if that makes it work.

ddumas

Rennur wrote
LoggedInEmployee can be a 'Calculated' attribute.

CORRECTION:
ProjectApprovalStatusNote.AddedBy can be a 'Calculated' attribute.

So, I revised with .ID, below, and still lets anyone delete:

IF ProjectApprovalStatusNote.AddedBy.ID<>LoggedInEmployee.ID then PROTECT ProjectApprovalStatusNote FROM ALL EXCEPT Administrator

I even have a Process that displays these IDs, and they are indeed different. Both users are access level Customer (not Administrator), so this IF statement should work, but does not.

Rennur

Check VP settings:

ddumas

Rennur wrote
Check VP settings:

Yes, just did that, so this is definitely making a difference.

Just go this error when a user at access level Customer tried to create a new ProjectApprovalStatusNote record (create ProjectApprovalStatusNote...)

Customer access is set to full access on ProjectApprovalStatusNote, so not sure why the error.

???

Rennur

Add the System to your rule
if ProjectApprovalStatusNote.AddedBy<>LoggedInEmployee then PROTECT ProjectApprovalStatusNote FROM ALL EXCEPT Administrator AND System

Rennur

If NOT(ProjectApprovalStatusNote IS NEW) AND
ProjectApprovalStatusNote.AddedBy<>LoggedInEmployee
Then
PROTECT ProjectApprovalStatusNote FROM ALL EXCEPT Administrator

ddumas

Rennur wrote
Add the System to your rule
if ProjectApprovalStatusNote.AddedBy<>LoggedInEmployee then PROTECT ProjectApprovalStatusNote FROM ALL EXCEPT Administrator AND System

Yep - that got rid of the error. It still does not enforce against another Customer access level user from deleting, for some reason 🙁

Rennur

My guess is the standard AIM delete button ignores the PROTECT rule.

Create a 'process' called 'DeleteObject' and have it check if the AddedBy = LoggedInEmployee and if so DELETE ProjectApprovalStatusNote

In the form operations, add a button (icon only & next to the item) to start process & delete the object instead of usind the AIM 'Delete Object' function.

ddumas

Rennur wrote
My guess is the standard AIM delete button ignores the PROTECT rule.

Create a 'process' called 'DeleteObject' and have it check if the AddedBy = LoggedInEmployee and if so DELETE ProjectApprovalStatusNote

In the form operations, add a button (icon only & next to the item) to start process & delete the object instead of usind the AIM 'Delete Object' function.

Agreed. I was saving that for a last resort. Was hoping to get this working so that the design could be used consistently. I am going to speak with AWARE IM support, and I will let you know what I find out. Thanks for all your help on this.

I need to buy you a beer!

ddumas

Rennur wrote
My guess is the standard AIM delete button ignores the PROTECT rule.

Create a 'process' called 'DeleteObject' and have it check if the AddedBy = LoggedInEmployee and if so DELETE ProjectApprovalStatusNote

In the form operations, add a button (icon only & next to the item) to start process & delete the object instead of usind the AIM 'Delete Object' function.

So, turns out that AWARE IM support thinks you may be right on thr PROTECT not covering a Delete. I got this to work by using a regular Delete operation, but then specifying the following in the Accessibility definition the Delete operation:

ProjectApprovalNote.AddedByLoginName=LoggedInEmployee

AddedByLoginName is a shortcut, as Accessibility definition does not allow references.

Works now - Delete only shows up for the user that created the note.

Yea!