Owner attribute?

[hpl123]

Hi all,
I am building a application with multiple users and every user have their own sets of BO´s that they work with. Standard AIM / out of the box, "shares" everything so if user 1 creates a BO Calendar entry, user 2 will see this entry as well.
What is the best approach to configure this so each user only sees their sets/data? Should i create a "owner" attribute on ALL BO´s and then use that attribute as a filter or what´s the best approach?
Thanks

[nlarson]

Does each user truly have their own BO's or just instances of data in a shared BO? How many users are we talking about? Would users ever need to be grouped together to share some data?

Based on your description it sounds like your talking about multi-tenant which can be done relatively easily, but is not an out of the box feature (HINT, HINT )

With a bit more info I am sure we can point you in the right direction.

[hpl123]

The application is kind of multitenancy. The application consists of several BO´s (3 examples: Calendar, Contacts, Notes). Each user of the application use/work with these same BO´s and create instances etc. but the instances should be kept separated from each other so each user only sees / works with their own instances. I have seen how this is done e.g. in the CRM sample application with attribute "Staff Responsible" that later acts as a filter. My question is if i should use this same approach on all BO´s throughout the application or are there other ways, better ways? + what should i think about when choosing this approach over another in terms of planning ahead (e.g. do i need to think about data protection through protection rules later on or is that handled automatically etc. with this approach)

Thanks

[hpl123]

What is the best practice when it comes to creating a application that divides data / instances in this way? I am currently working on this idea and trying to use a ID attribute in a user BO that acts as a owner of BO´s so when a user create a new instance of a BO (all BO´s except user BO´s) this ID attribute (i.e. user) gets assigned as the owner of that BO instance. Is this a good approach and something to think about? See also my other posts about trying to get this to work (having some issues)
Thanks

[pbrad]

Hi,
I'm not sure if I fully grasp what you mean but it sounds like you just need to create a one to many relationship between the user and the objects)multiple reference) such as appointment or Note. The when you show a query, report, reference list etc..., just filter the objects such as: Appointment IN LoggedInSystemUser.Appointments or Appointment.User=LoggedInSystemUser.

This is pretty simple and is `out of the box` so perhaps I am misunderstanding what you are trying to achieve? If so, please elaborate and I will point you in the right direction.

Cheers,
Pete

[nlarson]

Similar to what Brad recommends, I add a TenantID field all my BO's which populates from the RegularUser.TenantID field based on the instance owner. In my case I also have a Tenant.BO which groups multiple user by company(tenant).

I Then and set a rule in all my BO's

If
BO.TenantID<>LoggedInRegularUser.TenantID AND BO.TenantID>1

Then
READ PROTECT Objectives FROM ALL EXCEPT SYSTEM AND Administrator

This hides all the other tenants data from the logged in user.

Note: you may need to add a similar rule to some queries since Documents do not respect read protect (at least last time I checked)

[hpl123]

Note: This is a comment to this post and also: http://www.awareim.com/forum/viewtopic.php?t=6124

Thanks for the useful comments.

I solved this in the following way:
First of all, i added a attribute called "Owner" in all BO´s. I also added this rule to the BO´s (Note BO example):
"If Note IS NEW Then Note.Owner=LoggedInSystemUser.LoginName"

This makes sure all BO instances that a user creates gets marked so that, that specific user is the BO instance creator/owner.

Secondly i use the following rule in queries:
"FIND Note WHERE Note.Owner=LoggedInSystemUser.LoginName"

This works and solves what i asked about namely how to differentiate BO instances so each user works with their own BO instances only. I have so far not thought about / found any reasons why this would not work but that remains to be seen.

[tford]

Secondly i use the following rule in queries:
"FIND Note WHERE Note.Owner=LoggedInSystemUser.LoginName"

This should be fine, but I see the READ PROTECT that Nlarson mentioned as a safety blanket. It will ENSURE that records are not seen by the wrong users and not rely on making sure you have WHERE Note.Owner=LoggedInSystemUser.LoginName in each and every query, process, etc.

[hpl123]

Thanks Tom. Yes this was a concern i had and i can see yours and Nlarson´s point. I will try to incorporate the read protect rule.

[hpl123]

I tried incorporating the READ PROTECT rule but couldn´t get it to work.
I added this rule to the Note BO.
"If Note.Owner<>LoggedInSystemUser.LoginName READ PROTECT Note FROM ALL EXCEPT SYSTEM AND Administrator"

Now i can´t save a new Note instance. When I try to save it i get a unauthorized user error. I figure this has something to do with my first rule (or?). Nlarson, how does your ID attribute field get populated? and how do your users create a new BO instance when you´re using the READ PROTECT rule?

[nlarson]

Secondly i use the following rule in queries:
"FIND Note WHERE Note.Owner=LoggedInSystemUser.LoginName"

READ PROTECT is a only a partial safety blanket, since it only works with certain features. When it comes to security & data privacy only working part of the time is generally less desirable than not at all. If I was starting from scratch I would do the same as hpl to enforce uniformity and skip read protect.

[hpl123]

OK, I will think this through again i think.