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 <[EMAIL PROTECTED]> 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.
