Chandra

I can confirm prices are not zeroed in tb_order_details This leads me back to the 'total_paid_real' field in tb_orders that is not getting updated in custom payments. I shall research a little more.

@Traumflug Hi, I am guessing the rounding issue is not at play here since the order gets calculated correctly. I think it is a bug in Custom Payments module. I looked up the values in the tb_orders table for the custom payment method (where the issue shows up) compared to a payment method that works correctly. The deduction from my analysis is that custom payment method does not update the field 'total_paid_real' in tb_orders table, while other payment methods do. It appears this field value is used in listing/displaying order values. I am not sure why the order amount is duplicated in this field and where it is used. Is there an easy way to have this module update the field in question?

Noticed this in two tb installations. Order total always shows zero on dashboards, customer page etc. for orders using custom payment methods. Notice the cart total shows correctly on the screen but all order totals are zero.

Absolutely no related entries in the thirtybees log accessed from backoffice. Were you thinking another log?

When some products are added to the cart and then the '-' button is clicked to reduce quantity of a product, a technical error pops up sporadically. Technical Error: unable to save update quantity Details: Error thrown: [object Object] Text status: error It appears this happens when there is more than one product in the cart. Please see screenshot. I think this is an important bug since it affects the customer experience and the merchant loses money also. We have had some issues with customers ordering below the minimum order quantity for free shipping and claiming the bug affected their order.

Why can't you only put in available stock after deducting reservations? And then enable preorders?

Customer profile image in backoffice Online visitors screen refers to /modules/statslive/logo.gif This module folder does not exist.

Oh oh, feature request submissions are closed! 😞

Thanks @datakick Mautic and Phplist have a queuing mechanism that I thought should work well for the tb scenario. I see mautic creates emails and dumps them in a folder within the mautic installation. A cron runs periodically to pick and send out a configurable number of those emails through any standard mail server. We have cron functionality in tb for a variety of tasks anyway. Thinking about it, even Amazon does not send order emails immediately these days.

Why not separate out email sending process to some kind of queue mechanism so it is not on the critical path for order confirmation? Having this feature allows using SMTP authenticated email that is delivered more reliably, and does not delay order confirmation by many seconds either.

Good one! You could also add a single line to preferences - custom code - extra metas section as: <meta name="theme-color" content="blue" />

I have opened a bug. https://github.com/thirtybees/thirtybees/issues/824

My view is that the community theme is decent, at least for folks like me who are happy with a neat design, a slider or two etc. If the theme configurator itself could be enhanced for a few more options for fine grained control on colors and fonts, to me that would cater to most merchants' needs.

Just created a feature request that i think would be very useful. Please upvote if you agree. Thanks. https://thirtybees.com/suggestions/attribute-price-impact-as-of-base-product-price/

@lesley said in Change the hook for faceted search module: I haven't tried this, but you might add this to the module php file and then hook it to the displayTopColumn public function hookTopColumn($params) { return $this->hookLeftColumn($params); } By module php file I mean blocklayered.php Just to confirm, should hookLeftColumn in the code be hookTopColumn?

@datakick Works perfectly, thanks much. A related question - do you know if attributewise price is stored in any table (I can't find it) or is calculated on the fly each time based on the impact values?

@Domas Thanks. The row with attribute 0 is the total row for the product. The pseudocode would be like: For each product, update quantity where product-attribute=0 as sum of quantity of each product-attribute <> 0 I tried this but this isn't right enough: UPDATE tb_stock_available s1 JOIN tb_stock_available s2 ON s1.id_product = s2.id_product SET s1.quantity = (select sum(quantity) from tb_stock_available s2 where s2.id_product = s1.id_product and s2.id_product_attribute <>0) WHERE s1.id_product_attribute = 0

Requesting help from any sql guru: I am updating the table tbstockavailable from the backend with stocks of various product attributes. I would like to update the total stock row (attribute=0) of each product with the sum of the attribute stocks. Is there a single sql query that I can run at the end of attribute updates to update the totals? Thanks.

@dosbiner Thanks. I have added the below comment to the github issue. ``` Without understanding the code, I have a feeling the stock check happens at the point the Checkout button is clicked (and not at the point of clicking the payment Confirm button). Would it make sense to repeat the stock check at the payment confirmation, since stock position would have changed between clicking check out and clicking confirm? ```

I have been testing out orders vis-a-vis stocks and believe stock check against products in the cart of an order happens at shipping selection step and not at payment confirmation step. Consequently, if the stock in cart has been ordered by another customer, the order of the first customer still goes through, leading to negative stock and hence delivery issues. Should there not be an additional stock check at the point of payment confirmation?

Thanks @Tomik @datakick Thank you for your pointers. This can't get more interesting - the email authentication fails in firefox alone and not from other browsers or mobile. Apparently a password is somehow being saved in the browser and is being overwritten in the email password field. Typing in the right password afresh does not use it even. I have noticed the password in the DB gets overwritten with a different password from firefox as well. I can confirm this is not a TB problem. Thanks for all your help.

But something has changed; every other system sends email fine. Can you help me with which file to look for email changes since 1.0.7

It appears that 1.0.8 broke SMTP email. It worked correctly before the update. Email sent from thunderbird with same user id and password on port 587, STARTTLS, Normal authentication works fine. PHPMail works fine. Looks like a bug? Error on TB BO: Error: Please check your configuration Failed to authenticate on SMTP server with username "xxx" using 2 possible authenticators I checked mail logs on the postfix mail server and find authentication errors with LOGIN and PLAIN methods. Dec 29 12:34:44 mail postfix/smtpd[4368]: warning: xxx.com[ip-xxx]: SASL LOGIN authentication failed: authentication failure Dec 29 12:34:46 mail postfix/smtpd[4368]: warning: SASL authentication failure: Password verification failed Dec 29 12:34:46 mail postfix/smtpd[4368]: warning: xxx.com[ip-xxx]: SASL PLAIN authentication failed: authentication failure

@datakick You amaze as always! Should I raise a bug on github?

Thoughts anyone?