Feature Request Time!

[Raymond]

I noticed that avatar picture for employees are to be set on gravatar.com, I do not really understand why this is not an option and the only way to set one...

I suggest to add the classic way to upload an image locally and, presuming that is needed by some or many, keep the gravatar.com thing as an option

In my opinion is not good to have the platform rely too much on third parties, especially if as only option, what if for any reason there is change on those third parties side? what when users do not like that third party? what about privacy?....

This is not a very important thing, one can just ignore it, or modify the core, but to me at least does not look good and also is not reassuring to have to rely too much on third party services and have no options by default to avoid those...

[Raymond]

Hello

A needed useful feature that I suggest is the possibility to define remote areas for the couriers' fees.

Some couriers in order to serve certain remote areas do apply a surcharge, there is no way in the actual system to show to the clients shipping options that take in account such surcharges to have the goods shipped in remote areas.

Some couriers to deliver in certain areas that are considered to be hard to reach will add a 5$ or more as a surcharge on top of the regular shipping fare, not all couriers would do that, furthermore some will apply a low surcharge, others would apply a quite hefty surcharge.

Both the client and the seller should be able to know that and the client should be able to decide which courier would deliver at which price in a specific area.

In other words the possibility to choose among several couriers should be more granular.

For the seller this is an important problem, especially for goods that have a low price loosing e.g. 5$ or the like on the the shipping might mean loosing all the revenue if not selling underprice.

This problem could be resolved using the zip codes, the zip code during checkout could be checked against a table containing the zip codes that the seller indicates as  remote areas and associated to a specific zone, if there is a match then in the cart the client will see the special fares applied by the various couriers that can be chosen for that zone.

In other words as a practical example my idea is this:

the seller do create new Zones, e.g. "UK remote areas", "Germany remote areas" and so on

in the couriers configuration do indicate the fares for those zones

in a new config panel do input the list of zip codes that are considered remote areas so that are stored in a table and respectively associate each list to the new remote areas zones, eg. as said above "UK remote areas" zone, "Germany remote areas" and so on

the system during checkout control if the zip code given by the client in the delivery address match against the remote areas zip codes table

if there is no match the regular fares for that zone do apply

if there is a match then an override is done and the special fares indicated for the "remote areas" correspondent zone will be applied.

I am not fond of coding, I do not know if this can be done at core level keeping the compatibility with modules and/or third party software to manage Tb or prestashop, personally I do use prestashop manager as an example and find it to be really useful, I would not like to not be able to continue to use it.

So I do not know if it is better to have this feature as a module or as a core thing, sure is that according to me should not cause compatibility troubles.

Finally, I am pretty sure that this feature would be very appreciated by many sellers and would make a very practical and noticeable difference in comparison to many other e-commerce platforms.

I hope that you will consider implementing it.

Thank you

Best regards

Edited March 21, 2021 by Raymond

[Raymond]

Hello

Another important feature that I do suggest is to add the possibility to assign specific payment methods to products just as already happens for shipping carriers.

It happens that some products cannot be paid with credit card, or cannot be be paid with bank wire, the reasons can be many.

Another particular case is when the seller want to simply have the client to send in a request or proposal to buy some goods but not to have the sale automatically approved and receive the payment nor send a request to pay until the deal is approved and confirmed but not allow this same procedure for other products.

So far with your good "customized payment module" it is possible to create different forms of payment, using the options in the payment configuration (menu modules>payments) it is possible to decide a lot of things, but there is no way yet to tell to the system to show up only certain payment methods for each specific product...

It would be really very useful the possibility to have all available payment methods assigned by default to every product or to be able to assign only one or more selected payment methods to specific products, just as it happens with the shipping carrier.

In this new scenario the system would allow all sorts of operations, so for the simplest setups nothing would change, the seller would just add a few payment methods and specify nothing, for more complex setup instead the seller can create a more granular set of rules depending on the nature of the products and problems to be solved in order to perfect a sale.

E.g. the seller on top of allowing only certain payment methods for some products can indicate that paying with a specific method the client can have a discount only with certain products and not with other.

Why that? e.g if I sell a low price product, let's say a set of wrenches, or a 100$ loudspeaker, I might want to invite the client to pay with bank wire and concede a discount, e.g. "pay with bank wire and get 3%", for other kind of products, e.g. a 4000$ computer for which for some reason the credit card payment would just not be allowed the discount conceded when paying by bank wire transfer would have no sense, in fact in that case the bank wire would not be an optional payment method but the only way to pay.

Thus a seller could create several kind of payments, e.g. pay cash with discount, pay cash (but no discount), pay cash COD (with a surcharge maybe on some product and not on others...), pay with bank wire, pay with bank wire with a discount, pay with whatever method the plain price or with a discount or with a surcharge depending on the case, or furthermore pay with credit card or other method defined with other third parties modules and for each product only selected payment methods will be available.

In this more complex scenario, if the seller do create more versions of the same payment method (e.g pay with bank wire without a discount and pay with bank wire with a discount) the only thing that must be taken care of is to always specify which payment methods are available for each product, which in my honest opinion is a good compromise in change of great flexibility and ability to arrange all sorts of sales for particular products.

Btw, this same last problem could be also alternatively solved with the optional possibility to assign payment methods to categories, so a seller could create special categories for the products that need to be paid with special methods... this would create another kind of incongruence, e.g. have products that belong to a category assigned to two different categories, however would still be another extra possibility to granularly arrange complex marketing scenarios... it will be up to the seller to find best ways for the catalogue that need to market, but at least will have a wider gamma of choices to do it.

Thank you

Best regards

Edited March 22, 2021 by Raymond

[lesley]

It already supports this in a way. Create another set of carriers that work with only one payment method. Like your computer example, create a carrier that only works with bank transfer, then select that as the only carrier that will deliver the computer. You have effectively forced the customer to use the bank transfer to buy that product. 

 

That way in my opinion will be the best. Because it does not add another area for an order to not be able to be completed. 

[veganline]

On 3/21/2021 at 6:52 AM, Raymond said:

A needed useful feature that I suggest is the possibility to define remote areas for the couriers' fees.

Somebody did some work, trying to link UK postcodes to courier zones a few years ago. It is above my head but might help someone
...prestashop.com/forums/topic/105334-extension-uk-postal-zones-pack/ 
(I'm just a merchant commenting so this is a bit off-topic)

[KolS]

Hello,

Can you add a feature or module that will show a up pop-up notification of the last order or a page with list of recent orders. I think that would be helpful to attract orders from new customers. Also, a feature that will allow us to upload product pictures by entering image url like on eBay - This will aid listers to upload products more faster. 

Please pardon my English.

Thanks a lot!

 

[haylau]

26 minutes ago, KolS said:

Hello,

Can you add a feature or module that will show a up pop-up notification of the last order or a page with list of recent orders. I think that would be helpful to attract orders from new customers

 

I think that part exists? But not very pretty

Front office Features

Product Tooltips v2.0.2 - by thirty bees

Shows information on a product page: how many people are viewing it, the last time it was sold and the last time it was added to a cart.

[Raymond]

Hi Lesley, thank you

 

Yes, it works, I settled the customized universal payment module a time ago and did not remember that allows to choose a carrier, went back into that panel, and yes, the method you suggest works, so that is covered.

What I could not do is to set a discount without a coupon that can be applied only to clients who chose to pay with bank wire.

When creating a rule for the cart if no coupon code is created the discount is applied to everyone, if a coupon is created the problem is only half solved because the client need to receive it before placing the order, furthermore if that code is shared also clients paying elseway might try to use that same coupon code.

So maybe could be good to add to the cart rules configuration panel the possibility to indicate that a discount is valid only with certain payment methods

Thank you

 

[lesley]

@Raymond You can set the discount to be applied based on the carrier as well. That should solve your issue. 

[Raymond]

Hi Lesley

If the seller do create a payment method and assign it to a special carrier, and assigns certain products to be shipped with that carrier do not enable clients to use other payment methods for those specific products, that, although a sort of reverse logic is used, do work and and solve the problem, this kind of compromise solution is fine enough even though according to me would be much more logically linear the possibility to assign a payment method directly to products, however, it is a workaround and there is nothing wrong in using it.

Now let's say that the seller for all other products decide that clients can chose which payment method they prefer, and can also chose which carrier they prefer, for all these other products how can the seller let the client have a discount only if decide to pay with bankwire transfer and not let the client have the discount if decide to pay with credit card, but, at the same time let the client chose one of the several carriers available?

The only idea that comes to my mind is to create a double for each carrier, one telling to the client e.g. "Pay with bank wire and ship with DHL, you get a discount X%" and the other one "ship with DHL", this would work, but is not an easy going workaround and does not look good in several respects.

To look good he client should be just prompted to chose a carrier and chose a payment method, if do chose a payment method that impose a surcharge or allow a discount should be settled within the payment configuration itself, that is what I think every client expects to see, easy, clear, two clicks and done.

In my opinion forcing the clients to read a lot of extra not needed options and the seller e.g. to deal with a double amount of carriers' configurations, e.g. update the shipping fares in more carriers and so on.... is not a good thing, nor very attractive for those who do not know yet thirty bees and are evaluating which software to adopt for own shop or a client shop.

Even though in fact somehow is possible to solve these issues with workarounds I still insist that would be a very nice thing to have it settled in a more straight and simple way, so ability to assign a payment method directly to products and in the customized payment module add the possibility to directly add a discount or a surcharge (eg. for COD payment) without the need to create a cart rule.

In my opinion that would be greatly appreciated.

Thank you

Best regards

[oliiix]

Here's another thing that might be interesting: AGE VERIFICATION

and it would probably be very fast implemented as there's already a free prestashop module available for it. That's a functionality I'd call basic functionality in todays eCommerce:

https://www.prestashop.com/forums/topic/717631-free-module-age-verification-popup/

I sadly haven't had any time yet to check, why it's not working in TB (just doesn't show the age verification popup but seems to work fine "otherwise").

If I can find the time, which in the moment i really can't, I'll try to fix it and put it up for download but might be faster if someone else might be able to do so 😉

It's an age verification module I use in some of my prestashops. Full shop verification or category based with a one button option or having to enter the whole birthdate for approval. 

Edited March 26, 2021 by oliiix

[lesley]

@Raymond There is no good option for what you want to be honest, in any e-commerce package. What you are going to end up introducing is more ways to break the checkout imo. When you are able to set payment methods on a per product basis this is what will happen. Someone will order a product that has payment restrictions, they will order another product that has no restrictions. What happens in that case is the same thing that happens with carrier restrictions, you get a message that the order cannot continue and the customer cannot pay or complete the order. Multi-carriers per order is not something that is supported, so I doubt that multi-payments per order would be supported either. Then again, I am no longer with the project so I do not have any say over this. 

[Raymond]

Hi Lesley

I understand, and yes, much care about how to create and manage the catalogue and all the rules would be needed if those features are used.

Sure is that if a seller do not pay enough attention and do not keep up a rigorous logic would end up with some messy situations or worst even quite a mess.

However, that would be up to the seller, if does setup a logical clear scheme would take the advantages, if begin to mess up the catalogue would surely end up with many products that cannot be bought.

That said, I still think that would be good to have the opportunity to use these features, not all e-commerce shops do sell "simple" products in which it is sufficient to have same carriers and same payment methods for all products.

Personally as a seller I would be more than happy to have the features I mentioned, I know that some extra care should be taken, but this is part of our job as sellers.

As an example, in some shops a few core products do the big part of sales, for the seller is much more important to have those specific groups of products fixed in a very precise and proper way according to the case, if a client want to buy also other side products which cannot fit in the same cart due to restrictions it is not a great problem, the important thing is that they can proceed with the core product, the problem of the side products can be very easily solved explaining to the client that must do another separate order with all the side products, that can be included in the core product info as an example, or communicated at the sign up time e.g. " welcome Mr X, thank you ....etc..., If you want to buy other products other than CORE PRODUCT; please do a separate order, or just contact us and we will help you ...."

With that I just want to underline the fact that clients can be very happy to deal with unusual shops as long as they can concentrate on the core interests that they have, in a way it can even be positive to stimulate a direct contact or in general to keep the attention focused on the core reason for which the client landed on the shop.

According to me there is no strict need to keep the e-commerce platform "dummy proof", the special features can be there, who do not need it do not use it, who do play with it and fail can reset and try again in better ways, who need it and know what is doing can take advantage of it, on the contrary no special features=less chances, it is that simple IMHO.

Thank you for the information given so far, was pretty useful, I already fixed a few things.

Thank you

Best regards

Edited March 26, 2021 by Raymond

[lesley]

@Raymond I totally understand what you mean. One aspect you might take into account with all of this, is if you use a major processor like stripe, auth.net, any paypal products, they will all close your account over this. So it is something to be aware of and it is a key reason why it never made it into PrestaShop before thirty bees was forked from PrestaShop. 

[Jon88]

Hi everybody

My future requests sorted by importance are: 

1. Keep the current prestashop 1.6 compatibility

2. Continuously maintenance (something like Petr suggested is perfect!

3. Onboarding third party developers. If they released something based on 1.6 and they did not release anymore, just for 1.7. You guys need to try to convince them to release the same module/theme also for 1.6 / TB (Lesley did a good job in the past) and if possible their content to be available on Thirty Bees Marketplace!

4. Improve Thirty Bees Marketplace. Create lots of modules. Modules are one of the best ways to generate revenue. Do not add significant new features to the next TB releases. Just keep it up to date! Features must be added as modules as much as possible. If lack of ideas, try to inspire from: presta-market-place (+ 5000 downloads or similar), other ecommerce shopping carts.

5.I think that's it 🙂 I just wanted to add one more point to be five. 

I believed in you guys, I was a baker some time ago, and donated 5 bucks each month. But after a while shit erupted. Lesley was no more involved (hope you are ok with your health), Petr somehow excluded. I felt that the project was lost in space.

These days are past now and the future seems good!

You guys have my small support back!

[Websprint]

Please!! Remove Full Cache System from core in to separate module. Because is not working as need and do not allow to install third-party modules, that working perfect in Prestashop - 1.6-1.7

[the.rampage.rado]

I would be happy to see a tool which scans db and shows images that are no more associated with the shop and some easy option for review and bulk removal from storage.
Also the reverse tool will be cool also - scan for missing images.

[led24ee]

2 hours ago, the.rampage.rado said:

I would be happy to see a tool which scans db and shows images that are no more associated with the shop and some easy option for review and bulk removal from storage.
Also the reverse tool will be cool also - scan for missing images.

For missing images You can try Consistency Check.

[the.rampage.rado]

Yes it works but the oposite situation is much more important imho. And simply they can be build in the same place for ease and simplicity.

 

[Raymond]

Hello Everybody

Doing searches in order to have my SSL and then the Headers set right I had to begin to reason about one specific header, the Content Security Policy header aka CSP.

This header must be set in specific ways depending on the software used in the domain, CSP rules must be set specific for a given software or groups of software used on the domain, e.g if a person do use TB must have the proper rules in the CSP header in order to have it working right and at the same time harden the security of the website.

While searching I stumbled upon an interesting module done for wordpress, it analyses all the broken requests after implementing a CSP rule and output the formatted string to be added to the CSP rules set in order to have wordpress work fine.

So I thought to express this wish, would be very nice to have a native TB module doing this task, the principle is very simple, the user build the website installing all the modules needed and so on, when done do install the module to check the broken requests, thus do implement a simple restrictive CSP header in the httpd.conf file, then uses the website, the module record the broken requests and output the formatted rules to be added to the CSP header, with a few cycles of this routine should be able to figure out the "perfect CSP rule" for this specific TB installation....

Btw, I also found this post on prestashop forum where people do talk of this problem, seems that is a complex thing due to lots of inline stuff from within PS and from outside PS, I guess that for TB is the same.

https://www.prestashop.com/forums/topic/614928-prestashop-is-not-compatible-with-content-security-policy-csp/

I tried to implement a very very permissive CSP policy to start with, everything seems work fine so far:

Header always set Content-Security-Policy "default-src 'self';  font-src *; frame-src *; img-src * data:; media-src * data:; object-src *; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';"

However, with this rules the CSP header is there just for formal reasons, that according to the principle expressed by some allegedly security experts that having a very permissive CSP header is anyway better than having none.

In conclusion according to me would be nice to have a decent CSP header to rely on for TB.

So I launched a "quest"in another thread, whoever is interested in creating the "perfect CSP rule" for TB please read it:

Thank you

Best regards

R.

Edited April 7, 2021 by Raymond

[danwarrior]

An advanced integration with FB Ada, similar to Shopify. It would make TB unstoppable 😉

[musicmaster]

My wishes:

 - An option to start an attribute combination with “select a” instead of a default value. I know this is a template job...

 - Option to automatically hide categories without products or subcategories with products. You have now modules that do such a thing. But the problem is that while they disable you have to re-enable yourself.

 - Option to disable combinations.

 - Auto-save for customizations

 - Option to include attachments in messages to customers

 - And finally the big fish: a solution for the combination problems. 

There are several situations where the Prestashop combination structure gives problems:

 - with too many combinations everything becomes slow

 - some attributes don't influence stock

 - some attributes have their own stock

The solution that seems the most feasible to me at the moment is the following:

 - you need an additional table. Let's call it product-addons. 

 - a product-addon can be either a product or an attribute. If you need stock keeping you use a product. A product can be set to be used in this function only.

 - the attribute table is expanded with a weight and a price field

 - an addon product can have attribute combinations. If there is more than one attribute the combinations will be merged into a single select menu ("carpet size:large; color:red"). If an addon product has product-addons itself they will be ignored.

 - addon products without combinations and single value attribute groups will be displayed as checkboxes.

 - I hope there is some possibility to insert those extra fields with hooks in templates that don't support them.

 - the category_product table will need an extra field for the product-addons. In the order_detail table the information can be part of the name field.

Edited April 9, 2021 by musicmaster

[Raymond]

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

 

 

[Sean Alcorn]

A means for customers to register please

[haylau]

3 hours ago, Sean Alcorn said:

A means for customers to register please

You may need to add some detail to this. Register for what? They can already create an account and register for newsletters