You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Bilgin Ibryam <bi...@iguanait.com> on 2008/01/16 01:31:48 UTC
New field for WebSite entity?
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.
Re: New field for WebSite entity?
Posted by BJ Freeman <bj...@free-man.net>.
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
Re: New field for WebSite entity?
Posted by Bilgin Ibryam <bi...@iguanait.com>.
Yeah, new field is not required.
Thanks all, for the suggestions. I will keep to them.
Bilgin
--
View this message in context: http://www.nabble.com/New-field-for-WebSite-entity--tp14854979p14879795.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: New field for WebSite entity?
Posted by David E Jones <jo...@hotwaxmedia.com>.
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 <bi...@iguanait.com> 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.
>>
>>
Re: New field for WebSite entity?
Posted by Scott Gray <le...@gmail.com>.
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 <bi...@iguanait.com> 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.
>
>