Hi guys,
Just tested the new functionality for disabling the out-of-stock combinations (Very nice!!!) and noticed that the product availability is shown as "Out of stock" by default (even though the first attribute is not even selected i.e Please select) and the product has several attribute combinations that are in stock (Track inventory by attributes is selected for the product).
This may confuse the customers and they may decide the product is out of stock and not even select any attributes. Maybe show the availability once a given combination is selected.
Thanks,
Boyko
nopCommerce 4.40 - Bug fixes and improvements
团队成员
- 16616
- 155915
- 2008/10/22
- Armenia
Nop-Templates.com wrote:
Thanks again! We'll check that soon - https://github.com/nopSolutions/nopCommerce/issues/5510
Just tested the new functionality for disabling the out-of-stock combinations (Very nice!!!) and noticed that...
Thanks again! We'll check that soon - https://github.com/nopSolutions/nopCommerce/issues/5510
团队成员
- 138
- 1640
- 2018/4/2
- Armenia
Nop-Templates.com wrote:
Done! Please see this commit.
I believe this is needed only after filtration.
Done! Please see this commit.
团队成员
- 112
- 1366
- 2019/5/13
- Armenia
Nop-Templates.com wrote:
Done. Thanks!
Hi guys,
There are some hard-coded styles here.
Could you please move them to the css files so that we can style them in the themes without overriding these views?
Thanks,
Boyko
There are some hard-coded styles here.
Could you please move them to the css files so that we can style them in the themes without overriding these views?
Thanks,
Boyko
Done. Thanks!
MVP
银牌解决方案合作伙伴
认证开发者
- 2639
- 42712
- 2010/1/21
- United States
Hi guys,
Thank you for the quick fixes!
Following a previous discussion about the changes, you did in nopCommerce 4.30 for having all the addresses to be part of the address book.
It turned out to be a problem for many of our customers that are starting the checkout but do not finish it. Then they end up with several "broken" addresses in their accounts and we have quite a lot of support tickets for this.
Could we think of a way to mark certain addresses as "hidden" and do not show them in the address book or in the customer addresses in the administration?
Maybe something like a parameter:
This way we can get all addresses where needed but show only the ones that are not "hidden" in the public area i.e Addresses page in My Account etc.
I know it is short notice but it will be much appreciated if you could do something to solve this before the official release of nopCommerce 4.40
Many thanks,
Boyko
Thank you for the quick fixes!
Following a previous discussion about the changes, you did in nopCommerce 4.30 for having all the addresses to be part of the address book.
It turned out to be a problem for many of our customers that are starting the checkout but do not finish it. Then they end up with several "broken" addresses in their accounts and we have quite a lot of support tickets for this.
Could we think of a way to mark certain addresses as "hidden" and do not show them in the address book or in the customer addresses in the administration?
Maybe something like a parameter:
GetAddressess(bool showHidden = false)
This way we can get all addresses where needed but show only the ones that are not "hidden" in the public area i.e Addresses page in My Account etc.
I know it is short notice but it will be much appreciated if you could do something to solve this before the official release of nopCommerce 4.40
Many thanks,
Boyko
银牌解决方案合作伙伴
认证开发者
- 332
- 2270
- 2018/3/2
- Norway
Nop-Templates.com wrote:
Anton, thanks a lot for the suggestion! But we've decided not to mark these methods as public. Otherwise, we'll have to mark all protected methods as public (in the entire solution) just in case of someone could use it. I hope for your understanding
Hi Andrei,
Please note that we don't ask you to change all protected methods to public in the entire solution.
We only want the ones in the Model factories to be public.
Of course, we understand that since they are not used from outside they should be protected but from an extensibility point of view, we think that it makes sense to make them public.
Since these factories contain common logic that is used in the controllers and components of nopCommerce then it is quite useful for plugin developers to "re-use" this logic.
Otherwise, we will need to "copy" this logic and duplicate that code in our plugins.
Of course, we can easily do that but the problem is that if someone overrides these factories with their own implementation then they will not be able to have their custom logic in our plugins (since we will not use the factories but our own "copy" of the logic).
Basically, we are now going a few years back and be in the situation we were in the previous versions of nopCommerce when the logic was in protected methods in the controllers and we had to inherit from the controllers in order to reuse the logic. At least then the logic was shared since we inherited the controllers and reused the same protected methods but now we can't reuse it.
Now the logic is properly extracted into model factories but they are not easily accessible.
I hope you will reconsider this and make an exception for the methods in the Model factories.
Even if the nopCommerce team does not use these methods outside of the factories it doesn't mean that we (as plugin developers) won't need to use them in our plugins (actually we use them a lot).
Thanks a lot!
Boyko
I agree!
Anton, thanks a lot for the suggestion! But we've decided not to mark these methods as public. Otherwise, we'll have to mark all protected methods as public (in the entire solution) just in case of someone could use it. I hope for your understanding
Hi Andrei,
Please note that we don't ask you to change all protected methods to public in the entire solution.
We only want the ones in the Model factories to be public.
Of course, we understand that since they are not used from outside they should be protected but from an extensibility point of view, we think that it makes sense to make them public.
Since these factories contain common logic that is used in the controllers and components of nopCommerce then it is quite useful for plugin developers to "re-use" this logic.
Otherwise, we will need to "copy" this logic and duplicate that code in our plugins.
Of course, we can easily do that but the problem is that if someone overrides these factories with their own implementation then they will not be able to have their custom logic in our plugins (since we will not use the factories but our own "copy" of the logic).
Basically, we are now going a few years back and be in the situation we were in the previous versions of nopCommerce when the logic was in protected methods in the controllers and we had to inherit from the controllers in order to reuse the logic. At least then the logic was shared since we inherited the controllers and reused the same protected methods but now we can't reuse it.
Now the logic is properly extracted into model factories but they are not easily accessible.
I hope you will reconsider this and make an exception for the methods in the Model factories.
Even if the nopCommerce team does not use these methods outside of the factories it doesn't mean that we (as plugin developers) won't need to use them in our plugins (actually we use them a lot).
Thanks a lot!
Boyko
I agree!
MVP
银牌解决方案合作伙伴
认证开发者
- 2639
- 42712
- 2010/1/21
- United States
foxnetsoft wrote:
Hi,
Please don't take my suggestion out of the context. I never mentioned "published" etc.
It was just to illustrate what we need and not to tell them how to do it.
We need a way to NOT to show certain addresses to the customer in my account area, during the checkout (select Billing or Shipping address), and in the administration.
These addresses will be used to persist temporary address data like country, city, etc. during the checkout or for any other reasons that make sense to the plugin developers.
It is not even needed to change the database. All we need is an abstraction i.e as part of the interfaces that will allow us to implement this ourselves (the default implementation could simply return all addresses).
I am sure the nopCommerce team knows best what is good and bad and they will come with the best solution possible.
Thanks,
Boyko
>GetAddressess(bool showHidden = false)
I think that adding the new column "Published" in the table Address is a bad idea.
I think that adding the new column "Published" in the table Address is a bad idea.
Hi,
Please don't take my suggestion out of the context. I never mentioned "published" etc.
It was just to illustrate what we need and not to tell them how to do it.
We need a way to NOT to show certain addresses to the customer in my account area, during the checkout (select Billing or Shipping address), and in the administration.
These addresses will be used to persist temporary address data like country, city, etc. during the checkout or for any other reasons that make sense to the plugin developers.
It is not even needed to change the database. All we need is an abstraction i.e as part of the interfaces that will allow us to implement this ourselves (the default implementation could simply return all addresses).
I am sure the nopCommerce team knows best what is good and bad and they will come with the best solution possible.
Thanks,
Boyko
MVP
银牌解决方案合作伙伴
认证开发者
- 2639
- 42712
- 2010/1/21
- United States
foxnetsoft wrote:
No worries, next time we will create 2 threads - one for the nopCommerce team only and one for arguing with other developers.
Thanks,
Boyko
>Nop-Templates.com
I thought you created this thread for communication between the nop team and the developers about nop 4.40. I didn't know that you meant only developers from nop-templates and another developers can't write their minds.
I thought you created this thread for communication between the nop team and the developers about nop 4.40. I didn't know that you meant only developers from nop-templates and another developers can't write their minds.
No worries, next time we will create 2 threads - one for the nopCommerce team only and one for arguing with other developers.
Thanks,
Boyko