New field for WebSite entity?

[Bilgin Ibryam]

What do you think about adding a new indicator field to WebSite entity, to show is it a public facing website (frontend) like WebStore or not (like OrderEntry).

I want to use this indicator in the following 2 situations:
1. Depending on that field, we can disabling "Tell-A-Friend" and "Customer Reviews" links from product views screens in non frontend pages.
2. In ecommerce application if the user is blacklisted CheckOutEvents.failedBlacklistCheck events rejects the order and disable the userLogin. The same event can be used in order manager application, and if it is not a frontend website, the event can reject the order but do NOT disable the logged in user.

Possibly there are also other situations where this field can be used. Or may be someone can offer me a better way to handle these situations.

Any opinions?

Regards,
Bilgin

[BJ Freeman]

you can look for Https in the Url and if there is a login, also.
you can also look at the component to see which one is being used.


Bilgin Ibryam sent the following on 1/15/2008 4:31 PM:

> What do you think about adding a new indicator field to WebSite entity, to
> show is it a public facing website (frontend) like WebStore or not (like
> OrderEntry).
>
> I want to use this indicator in the following 2 situations:
> 1. Depending on that field, we can disabling "Tell-A-Friend" and "Customer
> Reviews" links from product views screens in non frontend pages.
> 2. In ecommerce application if the user is blacklisted
> CheckOutEvents.failedBlacklistCheck events rejects the order and disable the
> userLogin. The same event can be used in order manager application, and if
> it is not a frontend website, the event can reject the order but do NOT
> disable the logged in user.
>
> Possibly there are also other situations where this field can be used. Or
> may be someone can offer me a better way to handle these situations.
>
> Any opinions?
>
> Regards,
> Bilgin

[Scott Gray]

Hi Bilgin

For (1) I think it would be better if we created a new version of the screen
for the ordermgr app that displays information more relevant to an order
clerk, something like detailed product availability (ATP, incoming
shipments, etc) and pricing (minimum prices, any applicable price
rules/promotions etc).  We could then override that screen in ecommerce with
the current screen.  Obviously this is more work but for now we could create
a copy of the current screen, put it in ecommerce and add a todo note to the
ordermgr version about customizing it for the backend.

For (2) perhaps we should be checking if the userLogin is related to the
party placing the order and only disabling if that is the case.
Alternatively you could check if the userLogin has any ORDERMGR permissions
and not disable in that case.

Regards
Scott

On 16/01/2008, Bilgin Ibryam <[hidden email]> wrote:

>
>
> What do you think about adding a new indicator field to WebSite entity, to
> show is it a public facing website (frontend) like WebStore or not (like
> OrderEntry).
>
> I want to use this indicator in the following 2 situations:
> 1. Depending on that field, we can disabling "Tell-A-Friend" and "Customer
> Reviews" links from product views screens in non frontend pages.
> 2. In ecommerce application if the user is blacklisted
> CheckOutEvents.failedBlacklistCheck events rejects the order and disable
> the
> userLogin. The same event can be used in order manager application, and if
> it is not a frontend website, the event can reject the order but do NOT
> disable the logged in user.
>
> Possibly there are also other situations where this field can be used. Or
> may be someone can offer me a better way to handle these situations.
>
> Any opinions?
>
> Regards,
> Bilgin
> --
> View this message in context:
> http://www.nabble.com/New-field-for-WebSite-entity--tp14854979p14854979.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>

[David E Jones]

On Jan 15, 2008, at 10:35 PM, Scott Gray wrote:

> Hi Bilgin
>
> For (1) I think it would be better if we created a new version of  
> the screen
> for the ordermgr app that displays information more relevant to an  
> order
> clerk, something like detailed product availability (ATP, incoming
> shipments, etc) and pricing (minimum prices, any applicable price
> rules/promotions etc).  We could then override that screen in  
> ecommerce with
> the current screen.  Obviously this is more work but for now we  
> could create
> a copy of the current screen, put it in ecommerce and add a todo  
> note to the
> ordermgr version about customizing it for the backend.

Yes, this is the generally accepted pattern. The screens are different  
in the order manager and ecommerce and so the implementations of the  
screens should be different.

I guess this may be a little more work, but not much. The benefit  
overall is that the two applications remain significantly more simple  
and straightforward and in ongoing maintenance and customization the  
code will be more flexible and less error prone to change.

> For (2) perhaps we should be checking if the userLogin is related to  
> the
> party placing the order and only disabling if that is the case.
> Alternatively you could check if the userLogin has any ORDERMGR  
> permissions
> and not disable in that case.

Yes, it sounds like it is written in an unfortunate way. Maybe we  
should just change it to get the customer partyId out of the cart in  
the session attribute and not worry about the userLogin at all.

-David

> On 16/01/2008, Bilgin Ibryam <[hidden email]> wrote:
>>
>>
>> What do you think about adding a new indicator field to WebSite  
>> entity, to
>> show is it a public facing website (frontend) like WebStore or not  
>> (like
>> OrderEntry).
>>
>> I want to use this indicator in the following 2 situations:
>> 1. Depending on that field, we can disabling "Tell-A-Friend" and  
>> "Customer
>> Reviews" links from product views screens in non frontend pages.
>> 2. In ecommerce application if the user is blacklisted
>> CheckOutEvents.failedBlacklistCheck events rejects the order and  
>> disable
>> the
>> userLogin. The same event can be used in order manager application,  
>> and if
>> it is not a frontend website, the event can reject the order but do  
>> NOT
>> disable the logged in user.
>>
>> Possibly there are also other situations where this field can be  
>> used. Or
>> may be someone can offer me a better way to handle these situations.
>>
>> Any opinions?
>>
>> Regards,
>> Bilgin
>> --
>> View this message in context:
>> http://www.nabble.com/New-field-for-WebSite-entity--tp14854979p14854979.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>>

[Bilgin Ibryam]

Yeah, new field is not required.
Thanks all, for the suggestions. I will keep to them.

Bilgin