I need to tag products that are downloadable in Infusionsoft. I will be uploading those products through API. Is there a way i can achieve this? I can tag contacts but not products? Also an alternative was to use custom fields but they are also only for Contact Service,Company and order.
You cannot create tags for anything other than contacts.
There are a few ways to hack it though:
Append a specific value to the SKU
Use the NeedsDigitalDelivery column
Set a specific value in the InventoryLimit column
These options may not be ideal, but they may provide a workaround to the limitations of the product table.
Related
I found this in an old post and i'm thinking of using it for a project, but i don't know if i should change it or leave it, here's what i want to change:
remove product options and add product id and option group id to options
remove order details and have it's info in orders
is what i'm doing bad? also if you could be kind to tell me some of the best practices for something like this i would greatly appreciate it.
thanks for your time.
Both tables are there for a good reason.
productoptions is a mapping table between options and products: this is a many-to-many relationship, where a given product may have multiple options, and an option may be used by multiple products. If you remove this table, you end up redondantly adding the optionName to each and every row in productoptions that relate to the same option, which is inefficient, and might break data integrity (how do you ensure that a given option always has the same name?).
As for order_details: this is a many to one relationship towards orders. An order may have mutliple details line, each referring to a different product. Removing this table means losing this possibility.
This matter is driving me crazy as after wasting days going through my DB I've still been unable to find out an answer to the following question:
Where is the flag "is_visible" stored on the mysql DB for the attributes of Woocommerce products?
I checked all the tables 1000 times but I can't understand where and how the flag option "attribute visible on the product page" is stored on the Wordpress DB.
Thanks!
Enrico
the data is sotered in the postmeta table. However it is not quite straight forward to handle it. If you pick a product and do a search for the product ID as post_id you will see a record with the meta_key _product_attributes. In the meta value you will find a serialised array of the attributes including is_visible.
Just be careful because if you simply edit it in phpmyadmin you can mess stuff up badly. If you don't know what a serialised array is google it.
In case someone is searching for this in the year 2022 or later: In the meantime woocommerce isn't storing this value in the post_meta table. Instead there is a taxonomy called "product_visibility" with different states (exclude-from-catalog, exclude-from-search). In the "term_relationships" table is stored which of these values is associated with a product.
I am working on a large web application project and the previous designer favored the use of ids as handles to form fields over name attributes.
I suppose one advantage of this is that the lookup of that field via Javascript is faster through ids.
A big problem I'm now running into, however, is that ids have global scope. I want to refactor a large set of database column names to a more standard naming scheme, which doesn't include any column name prefix to identify which table the column belongs to. This is going to cause problems in those forms that use ids, since the field ids correspond directly to the column names. Column names which were things like "zon_name" and "pro_name" are now going to both be just "name". This will cause non-unique ids in the html.
So, after that long preamble, here's my question...
Before I try to address this scoping issue by changing all the forms to use name attributes instead of ids, are there any other reasons I'm not considering that the original developer may have had for using ids besides the speediness of their lookup?
I know this is a long one so I appreciate anyone who is brave enough to read through and give a good answer. Thanks!
Name and id do different things and, while there is some overlap, they are not interchangeable for the most important things they do.
Use name
To determine what key will be given to the data when the form is submitted to the server
To create radio groups
From JS/CSS when you need to reference multiple form controls at once (and when adding a class or using the element type is not more appropriate)
Use id
In the for attribute of the control's <label>
From JS/CSS when you need to reference a specific input
I suppose one advantage of this is that the lookup of that field via Javascript is faster through ids.
Not significantly (especially when the name is a unique one).
It sounds like the original designer hasn't been following standard conventions and has come up with something highly JavaScript dependant.
If you're using forms, you should be using <label for="aFormElement"> along with your form elements.
The for attribute on label matches up with an id attribute, not a name attribute.
So, you really need both id (for the label, amongst other things) and name for server-side code.
For the speed to find your elements, you can set just id on the form.
Then for the fields use name to read them like:
var form = document.getElementById('theForm'),
productName = form.productName.value;
Say that I have vendors selling various products. So, at a basic level, I will have the following tables: vendor, product, vendor_product.
If vendor-1 adds Widget 1 to the product table, I want only vendor-1 to see that information (because that information is "owned" by vendor-1). Same goes for vendor-2. Say vendor-2 adds Widget 2, only vendor-2 should see that information.
If vendor-1 tries to add Widget 2, which was already entered by vendor-2, a duplicate entry for Widget 2 should not be made in the product table. This means that, somehow, I need to know that vendor-2 now also "owns" Widget 2.
A problem with having multiple "owners" of a piece of information is how to deal owners editing/deleting the data. Perhaps vendor-1 no longer wants Widget 2 to be available to him/her, but that doesn't necessarily apply for vendor-2.
Finally, I want the ability to flag(?) certain records as "yes, I have reviewed this data and it is correct" such that it then becomes available to all the vendors. Say I flag Widget 1 as good data, that product should now be seen by all vendors.
It seems that the solution is row level security. The problem is that I'm not too familiar with its concepts or how to implement it in MySQL. Any help is highly appreciated. Thanks.
NOTE: this problem is somewhat discussed here: Database Design: use composite key as FK, flag data for sharing?. When I asked the question, I wasn't sure how to phrase the question very well. Hopefully, I explained my problem better this time.
Mysql doesn't natively support row level security on tables. However, you can sort of implement it with views. So, just create a view on your table that exposes only the rows you want a given client to see. Then, only provide that client access to those views, and not the underlying tables.
See http://www.sqlmaestro.com/resources/all/row_level_security_mysql/
You already suggested a vendor, product and vendor_product mapping table. You want vendors to share the same product if they both want to use it, but you don't want duplicate products. Right?
If so, then define a unique index/constraint on the natural key that identifies a product (product name?).
If a vendor adds a product, and it doesn't exist, insert it into the product table, and map it to that vendor via the vendor_product table.
If the product already exists, but is mapped to another vendor, do not insert anything into the product table, and add another mapping row mapping the new vendor to the existing product (so that now the product is mapped to two vendors).
Finally, when a vendor removes a product, instead of actually removing it, just delete the vendor_product reference mapping the two. Finally, if no other vendors are still referencing a product, you can remove the product. Alternatively, you could run a script periodically that deletes all products that no longer have vendors referencing them.
Finally, have a flag on the product table that says that you've reviewed the product, and then use something like this to query for products viewable by a given vendor (we'll say vendor id 7):
select product.*
from product
left join vendor_map
on vendor_map.product_id = product.product_id
where vendor_map.vendor_id = 7
or product.reviewed = 1;
Finally, if a product is owned by multiple vendors, then you can either disallow edits or perhaps "split" the single product into a new unique product when one of the owning vendors tries to edit it, and allow them to edit their own copy of the product. They would likely need to modify the product name though, unless you come up with some other natural key to base your unique constraint on.
This sounds to me that you want to normalize your data. What you have is a 1 (product) to many (vendors) relationship. That the relationship is 1:1 for most cases and only 1:n for some doesn't really matter I would say - in general terms it's still 1:n and therefor you should design your database this way. The basic layout would probably be this:
Vendor Table
VendorId VendorName OtherVendorRelatedInformation
WidgetTable
WidgetId WidgetName WidgetFlag CreatorVendor OtherWidgetInformation
WidgetOwnerships
VendorId WidgetId OwnershipStatus OtherInformation
Update: The question of who is allowed to do what is a business problem so you need to have all the rules laid out. In the above structure you can flag which vendor created the widget. And in the ownership you can flag what the status of the ownership is, for example
CreatorFullOwnership
SharedOwnership
...
You would have to make up the flags based on your business rules and then design the business logic and data access part accordingly.
I am creating a database using MySQL 5 for an eCommerce web site. I want the database to be as flexible as possible so that the owners of the web site can add custom attributes for various types of products. For instance, they can have a product which has 4 shirt sizes and 3 colors for each size available, or a product that has 6 shirt sizes, 4 colors for each size and possibly a 3rd attribute.
The problem I am running into is that they should be able to control the quantity for a product based on its various attributes, not for the product itself. The company may have a product that has 25 in stock of one style and color but have 13 in stock of a different size and color combination.
Is there a good solution on how to structure this in a MySQL database? Currently I have a table that will store the product id, quantity and the attributes will be concatenated in 1 field using a "key:value" syntax that is comma-delimited.
This is my first time trying to create a system like this. Any information/help would be greatly appreciated. If you need more information, I can provide that as well.
I really appreciate the recommendation. But to do this "Derived Item" method, would I need to create a different database table for each type of product since the products could have variable attributes associated with them?
The simplest solution is obviously to make every shirt-color combo a totally separate item, and abandon the attribute concept. I believe this is how most real stores operate. It makes sense when you consider how often the "base" items change anyway.
If that isn't acceptable, you could have a DerivedItem table, where each row was a separate derived item, which had a reference to the base item in a BaseItem table. That would eliminate some redundancy at the cost of a more complex design.
I'd go with the products and derived products, or whatever you might want to call it.
You can still put attributes on these if you wish.
You can then put common attributes on the product table (description etc) and those that vary on the derived product (colour, size, price etc).
The attributes would be best implemented as a separate table, with a foreign key on the derived attribute for things like colour. That eliminates the chance of users entering things like "Dark Blue" and "Blue (Dark)" and expecting your system to magically know that they are the same colour ...!