Feature Request Time!

[rubben1985]

On 4/11/2021 at 1:10 AM, Raymond said:

Hello

The problem of too many combinations coming out from automatic generation can be solved with modules done for this purpose, but are costly and the one that tried is also not really a big solution according to my tastes, I decided to not use it any more, it costed me over 200$, do ravage in the core, is hard to style, lots of mangles and work to be done to have it working

I found out another module that for my case is even more useful, but does work on a different principle and do not do the same, just similar thus, do cost much less and do not require any core modd.

It is very useful to create "solutions", e.g., let's make the example of a customized PC.

I do create all the products that can be used with a barebone base PC, the module allow to associate all those products in the product page of the barebone PC, with possibility to add some rules, eg. required, optional, single item, more items and so on.

So the client open the page of the barebone PC, can also find some basic combinations done with the built in combination system (or as many as needed, that falls back to the combination system, is independent, eg. colour of the case, power supply, format etcetera...), then in the the lower part of the page find a section created by the module where there are menus to add items, eg. memory, hard disks, cables, cards, fans, whatever one want to propose to the client.

The client choose some combination, then choose the additional items and build up its own custom PC, the module create a list of the "solution" so created and calculates the price, then in the cart everything is added as usual.

Works pretty well, is not heavy, does not slow down the system.

What I really miss, and have seen no one module doing that in the many e-commerce platforms around, are the logic conditions, e.g:
 - if you do use component A then show components D, G, H

- if then component H is chosen do show components T, X, W and so on...

- if at a certain point the client do choose a Component Z prompt the client to add the component B as a useful option, or, if the client choose components Z AND component W, force the client to add the component J as mandatory, and so on...

It would be wonderful to see some kind of product builder using logic conditions into TB

In the past I tried to get more information in such systems and discovered that do exist what are called "rules engines" to be used in such systems....

https://martinfowler.com/bliki/RulesEngine.html

Thank you

Best regards

 

 

Can I know what module is this?

[musicmaster]

One other wish concerns the payment modules. I noticed that neither with Paypal not Stripe payments I there is any information on which order the payment was for.

[Sean Alcorn]

My fresh install had absolutely no method for a customer to register at the store. It took me about an hour to sort it out and in the end still do not know what actually resolved.

[veganline]

20 hours ago, Sean Alcorn said:

no method for a customer to register at the store. It took me about an hour to sort it out and in the end still do not know what actually resolved.

I'm not a Prestashop or Thirtybees coder - just another merchant - but my understanding is that customers are asked to register at checkout.
It's possible to take this option away, so that every customer is a guest customer, and I wrote a method in the tips and tricks section.

As with any such, it only suits some people at a certain time; it doesn't refer to the new checkout modules that have been written since, and it is for merchants who want their customers to avoid the hassle of registering; you might have some reason to want them to do it.
Hope this helps more than hinders
 

[wakabayashi]

It's long ago. I have been here. I have a lot of ToDos on my list. I have taken the most relevant out and post it here:

E-Mail:

• Core function with core template, that just allows to put in some array with content. That way you need just one html file. Each email looks the same and modules can easily add email functionality.

Images:

• Add a cover_2 image to getProducts function
• In general it sucks, the way one has to get Cover Image as a coder

Customers:

• A way to merge two customer accounts
• Login as customer (there are modules, but it would be a nice core feature) -> also if there would be an easy way to use it for devs. Imagine you can send email links with default login…

Addresses:

• Clear way to define required fields
• Sometimes a line more, would help a lot

Combinations

• Allow them for bundles and probably digital products
• Allow different descriptions for different combinations
• Allow different gtin for different combinations
• No forcement of using default combination

Products

• Add archive column -> merchants often don't want to delete product information, but they often have products, that they don't need for ever or at least a big time span. If you have multiple thousands products, it helps a lot for filtering. Same could be helpful for Suppliers.
• Remove Tags and only use Features
• Remove on_sale checkbox -> what is it good for? Automate this by checking special prices…
• Accesoirces groups -> Imagine you sell Digital Cameras. You might want to define USB Cables as accessoires. But I don't think you want to update every camera, always when you got a new USB Cable.
• Define a default text for available_now and available_later
• Allow extra fields

Product Features:

• Multiple Features (done)
• Add Feature types with units or allow at least suffix and prefix value. That way filter modules can work without any issues. A filter module could than easily group values or work with ranges…
• Create Product Listing Pages from feature values. Imagine you sell books. It would be cool to have a product listing page for "Stephen King" with one click.

Categories

• Allow extra fields or add at least a second description

Voucher

• Allow to use it on product and shipping value. We sell vouchers and customer still need to pay for shipping even if his voucher value is bigger than product+shipping. That's not acceptable.

Checkout:

• A clean checkout with ajax Adress saving
• Drop the two different checkout system. It's just a mess.

Customer Service:

• Clean forms and handling in the BO. Nowdays you don't even know from where a message comes. Sometimes you get an email sometimes not. Have a good sync with email folder. My wish would be, that I can 100% handle customer cases in BO.
• Allow shortcodes on predefined messages and include attachments
• Handling returns

Order Status:

• Remove some functionality and implement clean processes. Imagine you have a Status: "Service in progress". How could you say if the order ist paid or not? This should all be handled by order payments
• What is logable status good for? In my opinion an order should have two bools: paid and shipped. This should be handled auto by modules. Then you have a status canceled. The rest of status should just be for displaying infos to merchant/customer, no funcionality should be involved imo.

Order Edit:

• Give more flexibility on invoice and delivery_slip generation. Why can't I edit an order after I genereated an order_slip. That makes no sense to me. A merchants knows best, when he needs to change/generate something. In my opion merchants should be able to generate as much invoices as they want per order. I don't see any need for invoice tables at all. I would just save a pdf. Maybe it's naive, please tell me. But I believe for us it would work perfectly.
• Allow to delete an order state. Sometimes you set it by mistake.
• Remove "tracking status" What is it good for?
• Remove "customer more" button. You can just click on the name… We have already too many buttons.
• Having to buttons to save address "Save as new Address" and "Override". Right now it's always saved as a new adress. In our case we want 90% of the times the "override".
• Either integrate a usable "return system" or remove it
• Allow to edit shipping costs (I have actually almost done it)
• Allow to edit payment method, allow to edit/delete payment lines (right now, you can only remove). On the otherhand the "details" can probably removed. Anybody really wanna save credit cart data on his server?
• Allow to add a cart rule by code.

Order Add:

• Allow to select the real payment method. In fact you can just select the payment module…
• Use a real shipping free stuff. In fact it just adds an ugly voucher.

Stock:

• Oh I better don't begin. It doesn't make sense as long as combinations and bundles aren't handled cleanly.

Captcha:

• Simple Usage of Captcha for devs. So that not multiple captcha version are used.

Backoffice List

• Allow better filtering (>=2)
• Allow better sorting (two columns)
• Allow custom display of columns -> every merchants wants a bit different columns.

Modules:

• Right now you have to set controllers, where you don't wanna show a module output. In my opinion it would be better if you would set where to show.
• Why is Payments under modules but Carrier has it own menu in BO?

What we don't need:

• Full Cache Page System -> TB is fast, if you aren't greedy on saving money for a good webspace.

[Quant]

20 hours ago, wakabayashi said:

It's long ago. I have been here. I have a lot of ToDos on my list. I have taken the most relevant out and post it here:

Sorry for GoogleTranslate.

-
Now, there is no need to complicate the functionality of the core and base theme, which is backward compatible with Prestashop 1.6.
I understand that the point of backward incompatibility is implemented in version 1.3 and above. I could be wrong.
Watching github and "Datackick" posts all your wishes will be implemented in version 31.0.0 :).

---
The "Mail" class is the best way to do it. Put everything in one method.

The path of the classes themselves define the functionality - Order :: sendMail, OrderState :: sendMail.
And sending letters only in the background (queue) - devSprint03!
Using a webtrigger is crazy, needs some work!
You can add the "Notificaton" class.
---

All that concerns redefining the output of products in FrontOffice should be done by modules.
But - we need one more class for displaying products in FO, which modules should also use - maybe "ProductIterator" or "CatalogProduct".
---

The checkout process should be spared from the buyer's registration choice.
The main thing for the seller is to receive the order and data for communication with the buyer!
You can extend the "Customer" class, add a phone. Use the "Address" class as a proxy.
Depending on the type of delivery or secondary to the country, use the mandatory fields of the "Address" model.

    pickup => Address - false
        invoice_address AS shop address from Config
    mycountrylocaldelivery => Address - true
        invoice_address AS moduleCarrier - Carrier api
     etc. :)
---

If you can do a Fast (basic or not) method "Product :: getProducts (array $ withFeature = [])" - that's cool!
---

Better to keep the core functionality of the store simple and straightforward.
Expand with modules.

And it's time to think about "CSS" and "JAVASCRIPT" for the base theme to function!
 

[wakabayashi]

@Quant I am sorry, but I don't understand some things, you said. And with many others I disagree.

I would agree, that modules are a great way to expand shop functionality. But I hate the mantra:

1 hour ago, Quant said:

Better to keep the core functionality of the store simple and straightforward.
Expand with modules.

IMO this exactly the reason, why we cant sort product lists for average review rating or why we cant have a clean filter on product lists. It's also the reason why you dont have a clean sitemap for google. Of course often you also could build a clever module that is extendable. This would be true for a sitemap module for example. But how many extendable modules with hooks do you know? And how many of this hooks are used by other modules?

1 hour ago, Quant said:

All that concerns redefining the output of products in FrontOffice should be done by modules.

Again you do it. Then you also agree, to add no image link at all to the $products array? IMO in a clean world, the theme would state, if it has a hover functionality. If yes, a function like Product::getProductProperties would add e second image link. It would simplify things so much for every theme desinger.

 

In general I have the feeling that a lot of Devs and some merchants only see the advantages of modules and not the drawbacks. Right now every module with mail functionality sends different template to customers. What does a customer care, if it's a core email or a from a module? He doesn't, he is just confused why he gets different looking emails from the same store. So thats why, I proposed the new Email Hook functionaility. It's not logical to me, that you don't even want that @Quant. Cause it would help the module approach a lot. 

 

The checkout is probably not the best cornerpart to start with. It's actually very important, but it's so complex and needs/wishes are so different. Some merchants don't want customer accounts at all. I do even force all my customer to register. And probably most are somewhere in between and offer both options.

Edited May 2, 2021 by wakabayashi

[Quant]

1 hour ago, wakabayashi said:

@Quant I am sorry, but I don't understand some things, you said. And with many others I disagree.

I wanted to say that there is no need to make another version of TB (I am a seller (and understand a little in development)).
Sellers need functionality stability,
developers also don't need to make frequent updates.
---
Sorting
It is necessary to add the display of goods to the basic functionality - in stock or not.
Where? There are a lot of solutions. If the "respected" decides to do it himself, you must remember to look, there are a lot of nuances.
This is one of the most requested features!
---
You want to display multiple images in FO.
The "getProductProperties" method generally needs to be divided into separate parts for getting the character, images, formatting, etc.
It will be more convenient to override.
In general, such functionality needs to be obtained through "ProductPresenter ()" (it needs to be done for TB as well), well, everyone needs to think about what he should decide.
It is necessary to display its variants in the listing in the product card - Color: Black: Green: Red, etc.
---
I am against any functionality of getting Goods in FO, which is not included in the core.
Maybe you need to create Product :: getNewProductList (etc.): ProductIterator
Do you want to do optimization? At the iteration stage?
---
Mail -> for new versions OrderState :: mail or a stub for those you don't understand. But it's better to make a Notification class.
Mail -> queue.
---
All salespeople have different needs. I want the engine to be fast!

[Traumflug]

On 5/1/2021 at 4:17 PM, wakabayashi said:

Remove on_sale checkbox -> what is it good for?

This one is simple: it shows an 'on sale' label in product lists. If your theme doesn't feature this label, it does nothing.

 

[wakabayashi]

9 minutes ago, Traumflug said:

This one is simple: it shows an 'on sale' label in product lists. If your theme doesn't feature this label, it does nothing.

I know that 😊 I more meant: why do I have to set it as a merchant? If I set a special price, do I ever want, to not display this label? :S

[Traumflug]

Apparently somebody was too lazy to implement automatic labels. Or considered it a good idea to put products on sale without changing the price.

[movieseals]

12 minutes ago, Traumflug said:

Apparently somebody was too lazy to implement automatic labels. Or considered it a good idea to put products on sale without changing the price.

I have to admit that this one has been bugging me for a bit.  I now run an event directly in mysql to flush these or add them according to specific price - but it should be automated, makes no sense whatsoever in its current incarnation.

[datakick]

On 5/2/2021 at 10:27 PM, wakabayashi said:

If I set a special price, do I ever want, to not display this label? :S

The problem is that specific prices are not used only for price reductions. A lot of merchants are using them to have different prices for different group of customers (per customer group/countries/languages/currencies), but that does not mean that the product is considered 'on sale'.

Example: my product cost 40 EUR, which equals to 1032 CZK. But I can use specific price and sell it for 1000 CZK in order to have a pretty rounded price. But I don't want thirty bees to automatically show 'on sale' label.

[wakabayashi]

1 hour ago, datakick said:

The problem is that specific prices are not used only for price reductions. A lot of merchants are using them to have different prices for different group of customers (per customer group/countries/languages/currencies), but that does not mean that the product is considered 'on sale'.

Example: my product cost 40 EUR, which equals to 1032 CZK. But I can use specific price and sell it for 1000 CZK in order to have a pretty rounded price. But I don't want thirty bees to automatically show 'on sale' label.

Thanks for the explanation. I didn't consider that. This makes some sense. But still not completly IMO. Wouldn't it be then logical if this field is set, when you add a special price? Cause your argument is probably also valid, if you wan't to only make a sale for a certain customer group.

But I am sure, we both agree, that this point is by far not the most important/intersting on my list ☺️ I understand, if my list is a bit overhelming, but maybe somebody has some concrete stuff to criticize or to vote up some points.

[30knees]

I'll take you up on the idea to vote for features, @wakabayashi! 🙂 Nice to see you.

YES! is a strong vote and OK! is a normal vote. 😄

 

On 5/1/2021 at 10:17 AM, wakabayashi said:

It's long ago. I have been here. I have a lot of ToDos on my list. I have taken the most relevant out and post it here:

E-Mail:

• Core function with core template, that just allows to put in some array with content. That way you need just one html file. Each email looks the same and modules can easily add email functionality.

YES!

Customers:

• A way to merge two customer accounts

YES!

• Login as customer (there are modules, but it would be a nice core feature) -> also if there would be an easy way to use it for devs. Imagine you can send email links with default login…

OK!

Combinations

• Allow them for bundles and probably digital products

YES!

• Allow different descriptions for different combinations

OK!

• Allow different gtin for different combinations

Doesn't this exist already?

• No forcement of using default combination

OK!

Products

• Add archive column -> merchants often don't want to delete product information, but they often have products, that they don't need for ever or at least a big time span. If you have multiple thousands products, it helps a lot for filtering. Same could be helpful for Suppliers.

YES!

• Remove on_sale checkbox -> what is it good for? Automate this by checking special prices…

YES!

Product Features:

• Create Product Listing Pages from feature values. Imagine you sell books. It would be cool to have a product listing page for "Stephen King" with one click.

YES!

Customer Service:

• Clean forms and handling in the BO. Nowdays you don't even know from where a message comes. Sometimes you get an email sometimes not. Have a good sync with email folder. My wish would be, that I can 100% handle customer cases in BO.

OK!

• Allow shortcodes on predefined messages and include attachments

OK!

• Handling returns

YES!

Order Status:

• Remove some functionality and implement clean processes. Imagine you have a Status: "Service in progress". How could you say if the order ist paid or not? This should all be handled by order payments

YES!

• What is logable status good for? In my opinion an order should have two bools: paid and shipped. This should be handled auto by modules. Then you have a status canceled. The rest of status should just be for displaying infos to merchant/customer, no funcionality should be involved imo.

OK!

Order Edit:

• Give more flexibility on invoice and delivery_slip generation. Why can't I edit an order after I genereated an order_slip. That makes no sense to me. A merchants knows best, when he needs to change/generate something. In my opion merchants should be able to generate as much invoices as they want per order. I don't see any need for invoice tables at all. I would just save a pdf. Maybe it's naive, please tell me. But I believe for us it would work perfectly.

YES!

• Allow to delete an order state. Sometimes you set it by mistake.

YES!

• Remove "customer more" button. You can just click on the name… We have already too many buttons.
• Having to buttons to save address "Save as new Address" and "Override". Right now it's always saved as a new adress. In our case we want 90% of the times the "override".

YES!

• Either integrate a usable "return system" or remove it

YES!

• Allow to edit shipping costs (I have actually almost done it)

YES!

• Allow to edit payment method, allow to edit/delete payment lines (right now, you can only remove). On the otherhand the "details" can probably removed. 

YES!

Order Add:

• Allow to select the real payment method. In fact you can just select the payment module…

YES!

• Use a real shipping free stuff. In fact it just adds an ugly voucher.

YES!

Modules:

• Why is Payments under modules but Carrier has it own menu in BO?

OK!

 

 

[Briljander]

On 5/4/2021 at 8:18 AM, datakick said:

The problem is that specific prices are not used only for price reductions. A lot of merchants are using them to have different prices for different group of customers (per customer group/countries/languages/currencies), but that does not mean that the product is considered 'on sale'.

Example: my product cost 40 EUR, which equals to 1032 CZK. But I can use specific price and sell it for 1000 CZK in order to have a pretty rounded price. But I don't want thirty bees to automatically show 'on sale' label.

Is this the only way to create customer specific price list or price lists for different countries with customerfriendly prices in Prestashop?

[musicmaster]

Is this discussion also relevant for Thirty Bees?

https://www.prestashop.com/forums/topic/1045112-is-prestashop-able-to-cope-with-new-european-tax-laws/

Implementation would mean that you can set the price incl VAT while the price for each EU would be different depending on its VAT rate.

[Traumflug]

It's obviously relevant for any shop software. I think it can be solved with catalog price rules, one for each distinct VAT percentage.

Edited May 11, 2021 by Traumflug

[toplakd]

Regarding the 1. July and OSS (One-Stop Shop) I suggest reading the information on following links:

https://ec.europa.eu/taxation_customs/business/vat/oss_en

https://op.europa.eu/en/publication-detail/-/publication/a8580815-6507-11eb-aeb5-01aa75ed71a1/

https://ec.europa.eu/taxation_customs/business/vat/vat-e-commerce_en

On second link you can download .pdf publication in all EU languages + some additional languages.

Edited May 12, 2021 by toplakd

[toplakd]

The only thing that makes me wonder, is the Tax in the Carrier section.

As currently one can only set no tax or one tax to apply, so most likely for each country different carrier will be needed so the added tax for shipping will be same as the tax for products.

Maybe 3rd option should be added: tax from country ?

 

p.s.

Forgot how the taxes are calculated on shipping, so after testing it, it works as it should.

Tax from country is also applied to shipping costs

Edited May 12, 2021 by toplakd

[Wartin]

Hello!
This is about combinations. Imagine you have a product with different colors. Then you have selected one as a default. But that color reach quantity 0. Then, in product's page, the 'add to cart' button is not shown anymore, but you do have more colors of the same product to sell.

It would be nice that TB selected another combination (in this case color) as default, in order to not show a product without a 'add to cart' button.

[The Pellet Guy]

2 hours ago, Wartin said:

Hello!
This is about combinations. Imagine you have a product with different colors. Then you have selected one as a default. But that color reach quantity 0. Then, in product's page, the 'add to cart' button is not shown anymore, but you do have more colors of the same product to sell.

It would be nice that TB selected another combination (in this case color) as default, in order to not show a product without a 'add to cart' button.

This is an annoyance for me too  I fixed this on my Presta site with a module but couldnt get it to work on Bees it sets the default to the product with thehighest stock level when the product sells out,  it was a mammoth task every monday changing the defaults as products sold out over the weekend.

 

I have two other annoyances that I would love to see a solution for

Merge two customers:  would be a huge benefit  the amount of customers that sign up with 2nd and 3rd accounts drives me mad its time consuming

Specific prices edit function: I have quite a few groups, resellers, teams, general public, etc and all have different rates, if it was possible to be able to edit the specific prices rather than delete and redo it would save huge amounts of time for larger collections of products it can be literally done on the fly, sure we can use a catagory discount per group but thats far too general especially when the title is specific and the discount structure is not always a fixed percentage across a catagory

 

[Wartin]

On 5/21/2021 at 6:05 PM, The Pellet Guy said:

This is an annoyance for me too  I fixed this on my Presta site with a module but couldnt get it to work on Bees it sets the default to the product with thehighest stock level when the product sells out,  it was a mammoth task every monday changing the defaults as products sold out over the weekend.

Helo!

After reading your comment I searched for a module. There is a free module and found a paid one too.

Is this the same you used in Prestashop?

https://www.prestashop.com/forums/topic/1011838-free-module-out-of-stock-combination-change-ps-16-ps-17/

edit: I tried that free module and it works OK in TB. Just commented some lines as a comment suggests, in order to prevent an error.
Anyway, it would be a great out of the box feature.

Edited May 23, 2021 by Wartin

[The Pellet Guy]

10 hours ago, Wartin said:

Helo!

After reading your comment I searched for a module. There is a free module and found a paid one too.

Is this the same you used in Prestashop?

https://www.prestashop.com/forums/topic/1011838-free-module-out-of-stock-combination-change-ps-16-ps-17/

 

the module I use is  Change the default combination when it goes to zero v1.0.3 - by SFWEB      

 

there is a short you tube videoon how it works  its flawless on 1.6.1.24  I think it needs some tweaking for Bees

[veganline]

Features:  meta data space for Schema.org and Google Product Categories.
Foolproof. Shown by default to search engines. In a bit more detail...

Non-theme.

• Features
  The software has Feature fields called "Title" and "URL", which accept data in a fresh install but not for me in practice; I read that they're sensitive to over-rides.
  (added: I think they're for a new page that lists all products with that feature, but have not got the hang)
  
  I'd like to use them for Schema.org and Google Merchant Center meta data.
  
  There's a Wakabayashi post on May 1st which has more ideas for features.
   
• Product Fields
  Most could be default features. So if you use UPC barcodes but not EAN barcodes, you  don't have unused code on product.tpl for the EAN field; it's just a default feature that you delete. If you use ISBN for books, just name a feature and add the metadata. (You'd have to think how to show that feature near the top of a product page without overloading a cheap shared server; maybe a template file that shows the first three default features without any {for each} loops if they're slower to render on a cheap server)
  
  As it is, my Niara theme shows some product fields by default with Schema.org tags, which is great if they happen to be the ones that are important to my human customers and the robot spiders. I think the spiders' priorities change quicker and they are more brand-concious than humans.
   
• Shipping cost on the front page
  Some estimate available to theme writers, so they can put it on the product page, would be good. Weight Width Depth Height are available for a guest customers before ordering. If there was a variable for a table of all shipping prices, or some of them, that would be good.
  I don't know if it's a theme problem or a TB problem, but it has been an unanswered thread on Prestashop since 29th of May 2015 ; it's "solved" for PS1.5 but not for PS1.6 or PS1.7, six years ago as I write... 
  prestashop.com/forums/topic/424375-solved-shipping-price-on-product-page/

Theme.

• My Niara theme lists features near the bottom of the page, without meta data. Merchants.google.com's spider ignores them even if I type google merchant center tags as features. Some time I will work-out how to take a specific feature, show it nearer the top of the page, and type my own meta data into the template file, but it's a slow process to learn all this.
   
• Size. A way of putting meta-data like "schema.org/size" round a size attribute would be good. I might done it already on the product template. Maybe there are better ways already.
   
• shipping_weight width height and depth on the product page by default would be good. I've learned to do it, more or less well. Maybe a module could do it better and the free Advanced EU Compliance module does add weight to the front page. 
   
• shipping price on the product page by default

(Other ways-around: product feed modules
I've paid for a couple of modules to upload data straight to Google, Ebay, and Amazon, but haven't yet  learned to use them and not everyone buys the modules. As someone said further back in the thread "Online markets - there's a reason there are paid modules. Markets integration rules and methods change and improve constantly, and require support. Support = money."  So if there is a search spider that might find some of this information in between going to fashion shows and changing its search habits, all the better.)

Edited June 8, 2021 by veganline