Page 1 of 1

different behaviour in extended domain objects

Posted: Sun Aug 03, 2014 1:53 pm
by prabhat.kataria
I have extended ProductImpl and AdminUserImpl and added following code to both of them:

Code: Select all

@ManyToOne(targetEntity = StoreImpl.class)
protected Store store;

Now when I add new custom product from admin panel I automatically get form fields under heading location to fill in the address of store but same does not happen when i add new custom admin. I have not used @AdminPresentation annotation in both the case.

Also is there any inbuilt way through which I can use the stored store location information on new products that i create or I will have to come up with my own logic for it?

Re: different behaviour in extended domain objects

Posted: Wed Aug 06, 2014 10:39 am
by phillipuniverse
This is because ProductImpl is annotated with @AdminPresentationClass(populateToOneFields = PopulateToOneFieldsEnum.TRUE). This will take all of the @ToOne (like your @ManyToOne) annotated relationships and go and bring back all of those fields to display on the form.

If you want to do the same thing on the admin user, then you will need to annotate your extended AdminUserImpl with @AdminPresentationClass(populateToOneFields = PopulateToOneFieldsEnum.TRUE).

By the way, filling out those fields will add a new store entity every time. So if you fill out the store fields that you see on the Product form then that will be an entry into the Store table, and if you fill out the store fields on the admin user that will be another entry into the Store table. You might want to annotate one of those with @AdminPresentationToOneLookup() so that you actually look up a previously-created Store and don't create a new one every time.

Re: different behaviour in extended domain objects

Posted: Sat Aug 09, 2014 12:04 pm
by prabhat.kataria
Philip, as per your suggestion I have change my code to below which works perfect to show the mapped store of the user.

Code: Select all

@ManyToOne(targetEntity = StoreImpl.class)
@AdminPresentation(friendlyName = "Store")
@AdminPresentationToOneLookup()
protected Store store;


But when I click the lookup buttom I get following exception:

Code: Select all

[ERROR] 22:29:23 DynamicEntityRemoteService - Problem fetching results for org.broadleafcommerce.core.store.domain.StoreImpl
org.broadleafcommerce.common.exception.SecurityServiceException: Security Check Failed for entity operation: FETCH (org.broadleafcommerce.core.store.domain.StoreImpl)

Re: different behaviour in extended domain objects

Posted: Thu Aug 14, 2014 10:13 pm
by phillipuniverse
I believe this is because of the security that you have to set up to manage the Store. You can enable this with the following SQL import:

Code: Select all

INSERT INTO BLC_ADMIN_PERMISSION_ENTITY (ADMIN_PERMISSION_ENTITY_ID, CEILING_ENTITY, ADMIN_PERMISSION_ID) VALUES (1, 'org.broadleafcommerce.core.store.domain.StoreImpl', -27);
INSERT INTO BLC_ADMIN_PERMISSION_ENTITY (ADMIN_PERMISSION_ENTITY_ID, CEILING_ENTITY, ADMIN_PERMISSION_ID) VALUES (2, 'org.broadleafcommerce.core.store.domain.StoreImpl', -27);


That -5 link there to ADMIN_PERMISSION_ID is from the OOB import for the primary key of the permission to manage admin users. If that's wrong, you can just use this to find out what that is:

Code: Select all

SELECT * FROM BLC_ADMIN_PERMISSION WHERE NAME = 'PERMISSION_ALL_ADMIN_USER';

Re: different behaviour in extended domain objects

Posted: Sat Aug 23, 2014 4:05 pm
by prabhat.kataria
Thanks a lot Phillip, your suggestion works like a charm and yes for ADMIN_PERMISSION_ID its -27. But as usual I have a few more question on this:
1. What is OOB?
2. Is it necessary to write same insert statement twice or it was some typo?
3. As I have my custom product with store field marked with ManyToOne annotation, since by default this field will be visible on front end I do not want to show this field to some admin users, say shopkeeper, while I want to show the same field to other users, say site admin. I saw there is a visibility attribute n AdminPresentation whose value can be any enum of VisibilityEnum class but I am not sure how to set this enum conditionally.

Re: different behaviour in extended domain objects

Posted: Fri Aug 29, 2014 2:04 am
by prabhat.kataria
does OOB mean Open Of Broadleaf? Still wondering about point 3.

Re: different behaviour in extended domain objects

Posted: Fri Aug 29, 2014 10:32 am
by phillipuniverse
1. OOB == Out Of Box
2. That was a typo, sorry
3. We have not implemented field-level security in Broadleaf like we have with row level security. You will probably want to write an implementation of the FormBuilderExtensionHandler to hide this field from the user display depending on which user it is

Re: different behaviour in extended domain objects

Posted: Sun Sep 14, 2014 6:03 am
by prabhat.kataria
I am trying to create an implementation of FormBuilderExtensionHandler but have 2 queries:
1. how do I hook my custom FormBuilderExtensionHandler into broadleaf flow?
2. since I will be modifying form based on admin user, how can I get admin user object into my custom FormBuilderExtensionHandler?

Re: different behaviour in extended domain objects

Posted: Thu Nov 06, 2014 11:05 am
by prabhat.kataria
@Phillip can you please guide me on the queries I raised in previous post?