[In-Commerce] Store Contact Info Page

[Alexander Obuhovich]

On "Store Contact Info Page" we have several problems:

• country ISO code is displayed instead of it's name
• same information on every language
• really small box for entering store additional information in administrative console.

Optimal way is to fix that this way:

• add "formatted" parameter to m_GetConfig tag
• make possible to enter configuration variable value on multiple languages

2nd part could be challenging to implement.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

Alex,

does the info entered in Store info page are used somewhere else? Most of the time I use a content page to do the job, but may I miss some interesting functionnalities?

p.

2010/4/12 Alexander Obuhovich <aik....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.
To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

[Alexander Obuhovich]

Address is actually used to estimate shipping costs for Intershipper. I'm only talking about making non-address field translatable.

[Dmitry Andrejev]

Yes, I think it would be cool to have but not very simple - need to think this one through.

Currently we can store Configuration Options for a field as Language Phrase with actual value as an ID.

What if we just store Language label (which is translated later by system) and mark that Configuration field as it uses translation or something?

Ultimately we should think how all this can be tighten up to SiteDomain, but I don't see a clear picture how yet, do you?

Please share your thoughts.

DA.

[Alexander Obuhovich]

Label stored in configuration is not very obvious solution. I have no idea about that for now.

[Dmitry Andrejev]

Yes, this is true about label.

Let's BRAINSTORM on this for a couple days and post here again!!!

DA.

[Alexander Obuhovich]

Quite long brainstorming for about 1.5 month.

[Phil -- wbtc.fr --]

I'd like to go back to the root of this field: where does these infos are used?

As far as I know, it's :
- to display store info on front (I never had a customer using this)
- for intershipper as departure address
- to display on invoices generated by system

Do I miss something?

2010/5/23 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry Andrejev]

Hi guys,

Phil, yes, you have listed most of them. As to the showing address on the Front - just output the configuration variable using <inp2:m_GetConfig name=""'/> tag (any config) in any template.

Alex, I'll list your options and my option:

1. ISO issue - yes, I agree we can add "formatted" parameter to Config and process it as needed. I suppose we do define formatter (options or SQL) elsewhere in Config table.

2. Multi-lingual support for Configuration fields.

How often you need to have data changed in Configuration - not too often, now imagine it's multi-lingual - probably even less.

What if we add the ability to specific if Configuration field contains a Language label? When needed user can check ANY text area field (check-box next to the field) and it will treat text as a Language label trying to translate it.

Please post your thoughts.

DA.

[Alexander Obuhovich]

2. then we can simply add "as_label" parameter to "m_GetConfig" tag. This way it will translate configuration variable value in all cases.

[Phil -- wbtc.fr --]

Hi,

I was asking th use of these fields, and as the inportal label is
named, these are config values.
In other words, I propose to focus the remake of these fields
according to their usage: billing and shipping.

Displaying contact info on front using this is not the main feature,
everybody need to add more info than just address and phone, then it'd
just save few characters. According to this, I propose not to use
translation table, as it's a non sense: an address don't have a
translation, neither the name of a company. On opposite, these fields
could change when using multisite feature, in order to generate
relevant invoices, and avoid confusing customer with different names
on bills or on "terms" page.

What your though on this?

Phil.

2010/5/24 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry Andrejev]

Hi guys,

Yes, I agree with Phil at some degree:

1. Any of these fields can be different when used with Site Domain as Shipping From info.

2. At the same time we can't simply make ALL Configuration variables Domain specific - doesn't make sense.

I believe we should go this way:

1. Have option "as_label" for ANY config variable (text fields I guess)

2. Work out list of Variables that will be used with Site domains and store it there (not sure about best storing option). The goal is to use these Domain specific variables instead of main default ones we have now (when they filled in) in places such as:

- Invoice Generation / Printing

- Shipping Calculations as From info

- We'll have to mark Site Domain (name or ID) for Orders in order to properly identify which Site domain and corresponding info to load.

Back to you guys.

DA.

[Phil -- wbtc.fr --]

Hi Dmitry,

I forgot that if we use sitedomain, we'll have specific lang pack
along with the domain, then may using these fields as labels, it's
automatically follow the lang pack, right?
There's still the printing/shipping part to address.

p.

2010/5/24 Dmitry Andrejev <dand...@gmail.com>:

[Dmitry Andrejev]

Alex or anyone any additional feedback here?

Cheers.

DA.

[Alexander Obuhovich]

So we end up with "as_label" parameter for "m_GetConfig" tag.

[Phil -- wbtc.fr --]

it'll fit all our needs.

2010/5/31 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

I support "as_label" parameter to "m_GetConfig" tag, but it would be great to have "formatted" parameter as well. It will use data from ValueList field of that configuration variable to transform it's value.

For example variable "CookieSessions" has 3 values:

• 0 for "Query String (SID)";
• 1 for "Cookies";
• 2 for "Auto-Detect".

Tag <inp2:m_GetConfig name="CookieSessions"/> will return 0 or 1 or 2. But tags <inp2:m_GetConfig name="CookieSessions" formatted="1"/> should return "Query String (SID)" or "Cookies" or "Auto-Detect".

Task: http://tracker.in-portal.org/view.php?id=852