Announcement

**wood** · 07-10-10, 08:13 PM

Re: Miva Merchant 5.5 Dream Features

I think I saw this, but I will 2nd the motion. On the products page allow use to set the checkboxes to the default view we want to see. For instance SKU, Name, Price, Weight and perhaps a custom field. Code is just not necessary for daily operations, it just takes up space for me.

**crozon** · 07-12-10, 08:30 AM

Re: Miva Merchant 5.5 Dream Features

The ability to set the Max allowed Characters and Max allowed Length for Text Fields and Text Area Attributes.

There is a thread started about this topic also.

**SunCam** · 07-12-10, 08:43 AM

Re: Miva Merchant 5.5 Dream Features

A "Comments and special instructions" field would save a lot of calls to our 800 number.

**kayakbabe** · 07-12-10, 08:54 AM

Re: Miva Merchant 5.5 Dream Features

addedendum to crozons wanting max characters and length of attribute fields..

I really want regexp control of custom product and category fields. having regexp for attribute fields especially text input and textarea input would be awesome. then we can control length and content easily.

I'm not sure what suncam is asking for... perhaps he needs an addendum module like the one from sebenza or emporium plus, so he can add some extra checkout fields for his customers.

**kayakbabe** · 07-12-10, 08:57 AM

Re: Miva Merchant 5.5 Dream Features

Originally posted by crozon View Post

In Wombat:

Either allow the customer to login in with order number and email address

The idea of this scares me. I wouldn't want this at all. It's too easy to violate privacy and security standards with this suggestion. all someone has to do it know someoneelses email address. and find a printout or an order number. that isn't very private info.

**kayakbabe** · 07-12-10, 09:10 AM

Re: Miva Merchant 5.5 Dream Features

just a little more about the regular expression idea... I really want it for the custom product and customer fields and extending it to any customer side text or textarea fields sounds like a good idea. But I suppose in the miva admin, it would take 2 more data entry fields, one for the regexp and one for the error message associated with it. That way if the regexp fails, we can display a message to our data entry person or to the customer about what they did wrong and how to use the field correctly so they can backup and do it right..

**wood** · 07-12-10, 08:51 PM

Re: Miva Merchant 5.5 Dream Features

In Rick's videos regarding inventory variants he mentions that currently price and inventory level are the only fields that dynamically update on the product page based on attribute selection. He also mentioned that images may be dynamic in the future. Select a red shirt, see a red shirt. Why stop there? Why not dynamically update other fields as well, even custom fields. While most data might be the same, there is the potential that some other data is different and relevant, like SKU. It should be simple enough to test to see if the field value was null, and if so leave the existing data alone. If not null dynamically display the new data on page also. This would make the inventory variant feature a very powerful tool.

**crozon** · 07-13-10, 07:50 AM

Re: Miva Merchant 5.5 Dream Features

The idea of this scares me. I wouldn't want this at all. It's too easy to violate privacy and security standards with this suggestion. all someone has to do it know someoneelses email address. and find a printout or an order number. that isn't very private info.

Wouldn't the print out have the postal code or zip code on it anyway?

It's much easier to know someone email and where they live then a specific order number they received.

**crozon** · 07-13-10, 07:54 AM

Re: Miva Merchant 5.5 Dream Features

It would be great if wombat could pull the volume price when the correct quantity is entered.

Also, we have misc fees like set-up charges and large item shipping charges associated with the product. I would love if wombat could insert this information also.

It's a pain if we are adding a phone order and forget to adjust the volume price and don't add a $35 set up charge to an order!

Both modules are from emporium plus.

**RayYates** · 07-16-10, 08:15 AM

Re: Miva Merchant 5.5 Dream Features

Todays wish...

Last Updated time stamps on category, product & customer records. I'm pretty sure that with MySQL this can be an automatic field, so Merchant had nothing to do except add the field when the table is created.

If not running MySQL just don't include the field.

**wcw** · 07-16-10, 08:26 AM

Re: Miva Merchant 5.5 Dream Features

You can use custom fields to do that now along with the tool kit to update it. Works for both mivasql and mysql.

**RayYates** · 07-16-10, 08:39 AM

Re: Miva Merchant 5.5 Dream Features

Originally posted by wcw View Post

You can use custom fields to do that now along with the tool kit to update it. Works for both mivasql and mysql.

I know, but this IS the dream features list. Adding it to an long running site does not solve the problem if the data was not stored to begin with.

**Brandon MUS** · 07-16-10, 01:45 PM

Re: Miva Merchant 5.5 Dream Features

I would be more in favor of a date_created opposed to a date_updated field. With MySQL you can only have 1 autodate field (for whatever reason), so if we were to vote for one, I'd go with creation (I don't see the use of knowing when a product was last updated).

Also, last_updated on categories would not be changed if new products were added/removed from a category -- only if the name changed. Likewise, products would not be considered "updated" if new attributes were added/removed, only things like price changes and name changes would update that field (if we went the auto-mysql route)

**RayYates** · 07-16-10, 05:42 PM

Re: Miva Merchant 5.5 Dream Features

Originally posted by Brandon MUS View Post

I would be more in favor of a date_created opposed to a date_updated field. With MySQL you can only have 1 autodate field (for whatever reason), so if we were to vote for one, I'd go with creation (I don't see the use of knowing when a product was last updated).

Search engine and product data feeds often contain the date of the last update. Currenty most users resort to using the current date. Also if a site has a product that is content and sells access to the content trhough availability groups, A last update field become very important. I have a client that altered the product database as described, herself will no ill effects.

As for the first point, I'd actually like ALL database records to have a creation date timestamp. but that might be a lot to ask.

Originally posted by Brandon MUS View Post

Also, last_updated on categories would not be changed if new products were added/removed from a category -- only if the name changed. Likewise, products would not be considered "updated" if new attributes were added/removed, only things like price changes and name changes would update that field (if we went the auto-mysql route)

Point taken. If a product were added to a category then the categoryXproduct and the attribute tables could have a last update field. Changing an attribute would not and should not change the product timestamp. All timestamp should be at the table / record level.

I realize MivaMerchant is always reluctant to change database structures, this is why I limited my request to category and product records that change frequently.

**kayakbabe** · 07-19-10, 10:39 AM

Re: Miva Merchant 5.5 Dream Features

I personally, if I can only have 1 time field, would prefer the last updated. I could use that info to figure out who of my employees screwed something up if I had to (not to punish, but to figure out if our procedures are wrong of if the employee needs to be in a different role, or needs more education); Even more though... I would use a date modified to have a product listing that showed recently updated products, to notify customers that some product has changed, to well... I could use it so many more ways than just a date created field.

However in mysql it is not true that you can have only 1 timedate stamp field in a record. You just can't have 2 fields that auto update to the current time upon update. So you can have your date created field and you can also have your last modified time field. You CAN have both. The date created needs to be created with the data of the record as is it first inserted. But the modified_date can be an auto updated by sql. On creation those timestamps will probably match, (but might not if your db server is not on the same box as your website).

By the way, I have modified my tables to have modified time stamps. I give xml feeds to some of my customers so they can resell our products and not have to stock them. It's important that they know when some product is updated and when it's been updated. I give them short feeds of only updated products (importing the whole mass of products is a lot, so they get short feeds everyday of just the changed products).

I believe the key is to use a field name which miva wouldn't likely use. Therefore I use a prefix to my extra field names. I wouldn't name this modified_date because that's a generic enough term that miva would likely use. I use something like kayak_modified_date. I'm pretty sure miva wouldn't use that. Yes, I might have a conflict if miva ever decided to add an automated time date stamp field. But if they do, it's a pretty obvoius and easy thing to fix. I've been doing this in every version of miva even before the compiled days.

I would really like this to be built in, and not have to mess with adding fields to the database structure. modified date is pretty standard in a lot of carts. We should have it in ours.