These are chat archives for mirumee/saleor

3rd
Jul 2018
NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 15:52

Would adding a "related_objects" (one to many) to the category and collection model sound a weird idea?

To explain the case, let's say: we have a category (or collection) of "Wall mounted lights", user may want to look for mounting accessories, that's where the related objects field enters in action: "you may also be looking for/ be interested for: wall mounting accessories"

It also prevent from adding a child to a category that would mess up the product listing by adding both screws, power supplies, accessories, ... to lights (which is really, really, really a nightmare in saleor as the current customization limits)

Then, of course, we can link specific product accessories compatible to a given produc through the description page. Or a db relation as well.

To disclaim: user may want to look for those accessories, not to buy both the light and the accessories (especially power supplies)

Example:
https://i.imgur.com/zDwjNVM.png

Patryk Zawadzki
@patrys
Jul 03 2018 15:55
wouldn’t it serve the user better if each product linked to the necessary equipment? or are these complementary in a way that is not directly related?
NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 15:58

Yes, to allow (and help) the user to bundle a product with potential wanted accessories.

But for the category/ collection side, it would allow to redirect the user to potential stuff they may be wanting to look at. Thing that child categories cannot provide as they would be loaded in the parent category (messy)

NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 16:03
That's our current case: https://i.imgur.com/iUnhtBf.png
The idea would be to get ride of the child ("Alimentations"/ Power Supplies), for a related object, and thus, remove the power supplies from the other products
(that's not really a good example though)
Patryk Zawadzki
@patrys
Jul 03 2018 16:04
hmm, does it need to be structured? I’m thinking about something more like a WYSIWYG editor for the sidebar maybe
because eventually we want to adopt draft.js and that in turn would make it very easy to add links like that
NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 16:06
That would be great if we could at least edit the header of categories and collections to allow to extend a little bit, yes
Patryk Zawadzki
@patrys
Jul 03 2018 16:06
ie. write custom draft.js block types for common objects (product, category, collection) and allow sidebars to be edited using draft.js
NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 16:06
That would nice
Patryk Zawadzki
@patrys
Jul 03 2018 16:07
then the same object types could be shared between all editors on the page (eg. embed a product inside an article)
but we’re not there yet
NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 16:07
Yeah, first we need to whole revamp of the frontstore, then... will see...
Patryk Zawadzki
@patrys
Jul 03 2018 16:08
there’s draftail by the Wagtail community that allows rendering draft.js blocks using Django on the server
so it would not be that hard to adopt draft.js where we are now
we just don’t have the necessary hands to do so
it’s also a good first step to allow images and files to be added as attachments
NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 16:09
Seems nice
Anyway, that was just to get thoughts over a possible solution to embed to Saleor (have to keep improving Saleor!)
In another news: Python 3.7 is available on travis-ci but only on xenial, an employee of travis said it was the way to go as python 3.7 is not compatible with trusty. (https://travis-ci.org/NyanKiyoshi/saleor/builds/399379173) Quite a positive news.
NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 16:16
I wonder something: why not making travis always test the latest stable release of django instead of master?
Patryk Zawadzki
@patrys
Jul 03 2018 16:19
we do test both
NyanKiyoshi
@NyanKiyoshi
Jul 03 2018 17:26
I mean, automatically testing the latest 2.x branch releases, like the 2.1 release instead of master by getting the latest. We only test 2.0.x on the 2.x branch