Re: Users Groups (and grouping)
Re: Users Groups (and grouping)
- Subject: Re: Users Groups (and grouping)
- From: Timothy Worman <email@hidden>
- Date: Tue, 13 Aug 2013 13:35:49 -0700
What about ERTag? A user could be tagged as both ‘vendor’ and ‘employee.'
T
On Aug 13, 2013, at 1:31 PM, Theodore Petrosky <email@hidden> wrote:
> I like this method of inheritance however, why did you choose vertical inheritance? I did one vertical and one single table. I put a qualifier userType='Vendor' on the table.
>
> I think the only thing 'wrong' with inheritance is that I can not create a User that is both a employee and a vendor. There are cases where we have clients that are also vendors.
>
> I was looking at the migration that I am creating and now I see.
>
> with vertical inheritance, it is actually creating a table in the database with a foreign key. this would allow me to add specific meta data to my inherited entity, whereas the single table does not create this table therefore I can segregate the different 'roles' but can not add a specific piece of meta data. Such as a person has a SSN but a business has an EIN (in the US).
>
> but that still leaves me with the problem of modeling a Vendor that is a Person not a business. Couldn't we find an easier way to model this stuff.
>
> Ted
>
>
>
>
> On Aug 13, 2013, at 2:59 PM, Johnny Miller <email@hidden> wrote:
>
>> Use vertical inheritance and then use entity.name='Vendor'?
>>
>> Sent from my iPad
>>
>> On Aug 13, 2013, at 8:19 AM, Theodore Petrosky <email@hidden> wrote:
>>
>>> I have been playing with D2W and I may have boxed myself into a corner.
>>>
>>> A User is of a type. a User can be a Vendor or a Client or a Worker. So I thought that I would create an attribute 'userType' in User. I wanted to have a Vendor tab and a Client tab and I have it mostly working.
>>>
>>> when I create a ListVendorPage:
>>>
>>> public WOComponent listVendorAction() {
>>>
>>> EOEditingContext ec = ERXEC.newEditingContext();
>>> ListPageInterface lpi = (ListPageInterface) D2W.factory().listPageForEntityNamed("AppUser", session());
>>>
>>> EODatabaseDataSource ds = new EODatabaseDataSource(ec, "AppUser");
>>>
>>> ERXFetchSpecification<AppUser> fs =
>>> new ERXFetchSpecification<AppUser>(AppUser.ENTITY_NAME, AppUser.IS_ACTIVE.eq(true).and(AppUser.USER_TYPE.eq("Vendor")), null);
>>>
>>> ds.setFetchSpecification(fs);
>>>
>>> lpi.setDataSource(ds);
>>>
>>> ((D2WComponent) lpi).d2wContext().takeValueForKey("ListVendor", "navigationState");
>>> ((D2WComponent) lpi).d2wContext().takeValueForKey("Vendor", "userTypeKey");
>>>
>>> return (D2WPage) lpi;
>>> }
>>>
>>> I am also adding that userTypeKey so I can target rules like this:
>>>
>>> 100 : (pageConfiguration = 'ListAppUser' and userTypeKey = 'Vendor') => displayNameForPageConfiguration = "Vendor List" [com.webobjects.directtoweb.Assignment]
>>>
>>> Maybe there is a better way? If I select to edit a Vendor, I wanted rules:
>>>
>>> 100 : (pageConfiguration = 'EditAppUser' and userTypeKey = 'Vendor') => navigationState = "ListVendor" [com.webobjects.directtoweb.Assignment]
>>> 100 : (pageConfiguration = 'EditAppUser' and userTypeKey = 'admins') => navigationState = "ListAdmins" [com.webobjects.directtoweb.Assignment]
>>>
>>> then I thought that what I should be using is inheritance. Vendor inherits from User, Administrators inherit from User. In the past, I would have created a User with boolean attributes for Vendor, Client, Employee, Admin. After all a user can be both an employee and a vendor.
>>>
>>> How are youse guys doing this?
>>>
>>> Ted
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden