• catalogue.Store, fields available through GET name, slug, about, url, logo, payment_options

  • GET
    • /store --> list of all Store instances
    • /store/ --> specific Store instance
  • POST
    • /store --> disabled
  • PUT and PATCH
    • /store/ --> disabled
  • DELETE
    • /store/ --> disabled
  • OPTIONS
    • /store --> implemented methods + model field descriptions

• catalogue.Brand

  • GET
    • /brand --> list of all Brand instances
    • /brand/ --> specific Brand instance
  • POST
    • /brand --> disabled
  • PUT and PATCH
    • /brand/ --> disabled
  • DELETE
    • /brand/ --> disabled
  • OPTIONS
    • /brand --> implemented methods + model field descriptions

• catalogue.Product, fields title, slug, description, extra_information, price, old_price, primary_image, extra_images, product_id, external_url, color, sizes, material, brand, store, category, subcategory

  • GET
    • /product --> list of all Product instances
    • /product/ --> specific Product instance
  • POST
    • /product --> disabled
  • PUT and PATCH
    • /product/ --> disabled
  • DELETE
    • /product/ --> disabled
  • OPTIONS
    • /product --> implemented methods + model field descriptions

• catalogue.Category
• catalogue.Subcategory
• catalogue.Label
• catalogue.Certificate

Overview input parameters:
"categories"
"subcategories"
"colors"
"size"

Overview output:
"id"
"thumb_image" --> Hebben we het over gehad
"main_image" --> Nog aanpassen naar bij Mancelot gehost
"sizes"
"colors"

Detail input:
"id"

output MVP:
"id"
"name"
"info"
"main_image"
"brand" (en uit "brand:, dan weer de brand description, zou mooi zijn als die meteen mee komt)
"labels" --> deze wordt nu nog niet meegegeven
Opmerkingen bij overige velden die er nu in stonden:
"extra info" --> Voor als we meer info willen tonen. Naar mijn idee niet nodig.
"slug" --> Voor als we "delen" feature implementeren
"price" --> Voor als we prijzen toch inzichtelijk willen maken
"price_currency" --> Voor als we prijzen toch inzichtelijk willen maken
"from_price" --> Wij focussen niet op sale
"from_price_currency" --> Wij focussen niet op sale maar dit is toch ook altijd gelijk aan price_currency..?
"extra_images" --> later zeker nodig, maar besloten voor MVP
"cece_id" --> Voor link naar direct kopen via Cece?
"url" --> Voor link naar direct kopen via Site aanbieder?
"materials" --> Materials gebruiken we nog niet als filter, mogelijk later wel.
"store" --> Wij werken enkel met merken, niet met stores. Nooit nodig lijkt me.

e.g. using the Google Translate API. But we'll have to investigate quality of the output...

Resources for which serializer retrieves related instances are unacceptably show.

• Example. Product has a total of 128 instances. Fetching the first 48 takes min = 165, max = 1062, mean = 269.82, std = 129.33 milliseconds (N=1000). The time spent proxy'ing the request is hardly larger than the time spent by uWSGI. The majority is wasted on inefficient queries (257 O_o). The serializer fetches the pivot tables for each Product instance for the related brand, store, materials, sizes, colors, categories, subcategories. Better may be to select_related and prefetch_related to see whether this changes performance.

• Brand has 660 instances and Store 152

Most-likely caused by the TinyMCE widget of the info field. Oddly, blank=True but the field is bold-face in Django admin (indicating optional field on the model, but required according to the admin interface).

Possibly accounts.Orders

• products
• payment_status (Mollie, Paypal?)
• status (received, processed, in transit, received)

accounts.ShoppingCart?

• products
• status (browsing, at checkout, paid, abandoned)

MANCELOT-BACKEND-Q: NameError/admin/catalogue/product/{object_id}/history/

• PaymentOption

  • name
  • logo

• Store

  • name
  • slug
  • about
  • url
  • logo
  • address
  • payment_options

• Labels

  • name
  • slug
  • about

• Certificate

  • name
  • slug
  • teaser
  • about

• Brand

  • name
  • slug
  • logo (not available at Cece)
  • about
  • labels
  • certificates

• Section

  • name [Men/Women/Kids]

• Subcategory

  • name
  • slug

• Category

  • name
  • slug
  • section

• Product

  • title
  • slug
  • description
  • extra_information
  • price
  • old_price
  • primary_image
  • extra_images
  • product_id
  • external_url
  • color
  • sizes
  • material
  • brand
  • store
  • category
  • subcategory

• Particularly for Product instances. It would be incredibly useful to filter on

  • categories, particularly on particularly on Category.section

  • categories, particularly on particularly on Category.name

  • subcategories, particularly on particularly on Category.category.section

  • subcategories, particularly on particularly on Category.name

  • brand

  • brand.labels, particularly on CeceLabel.name

  • brand.certificates, particularly on Certificate.name

  • store

  • sizes, particularly on Size.name

  • colors, particularly on Color.name

  • material, particularly on Material.name

  • price (both > and <)

  • from_price not null (i.e. items that are on sale)

• For Brand it would be useful to filter on

  • labels, particularly on CeceLabel.name
  • certificates, particularly on Certificate.name

• For Store it would be useful to filter on

  • payment_options, particularly on PaymentOption.name

• For Category it would be useful to filter on

  • section
  • name

• For Subcategory it would be useful to filter on

  • section
  • name

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.mancelot.nl/api/v1/auth/jwtoken/?. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Bij voorkeur ~10 kb per thumbnail. De totale file size voor thumbnails in de catalogue implementatie van de app moet <= 3 MB zijn voor ~300 images.

Plot distributie van file size voor de totale image set gegeven verschillende values voor de width.

• accounts.UserModel

  • GET
    • /users/me --> specific UserModel instance. Requires authentication.
  • POST
    • /users --> create a new UserModel instance. Required fields: email, first_name, last_name, password1, password2
  • PUT and PATCH
    • /users/me --> update the UserModel instance
  • DELETE
    • /users/me --> delete (b/c GDPR) or anonymize the UserModel instance. TODO: which data are required to be stored?
  • OPTIONS
    • /users --> implemented methods + model field descriptions

Add deactivated = BooleanField to models. Then API will only return .exclude(deactivated)

We have sent around 80 welcome emails to addresses that do not look genuine since Jan 1, 2020. Perhaps it would be useful to add a Captcha to the form. This repo seems to implement a simple non-Google Captcha, tho like most Captchas it seems to have limitations.

In order to be compliant with article 5 sub 1 of the partnership agreement d.d. May 23, 2019

The data can fluctuate considerably due to scrapers / add_products implementation in the Cece pipeline. So we may want to implement a simple model that holds a timestamp, content_type_pk, and instance pk, and count.

We can then use these timeseries data to monitor the number of certificates/brands/stores/products in our database, and set limits for warnings (e.g. if one Store/Brand suddenly drops from 100 to 40 products).

Example. Product has FKs to Brand and Store, in which case it's clear to CASCADE on deletion of the Brand / Store (i.e. delete the related Product instances too).

However, for M2M it's less clear. How to handle deletion of (the last instance of)

• categories --> ideally Product instances always fall in at least one Category instance. Perhaps could provide a fixture w/ Category(pk=1, name="Orphaned")?
• subcategories --> fine, Product instances could be free of any Subcategory instance
• materials --> fine, Product instances could be free of any Material instance
• sizes --> ideally Product instances are always associated with at least one Size instance. Perhaps could provide a fixture w/ Size(pk=1, name="Unknown")?
• colors --> ideally Product instances are always associated with at least one Color instance. Perhaps could provide a fixture w/ Color(pk=1, name="Other/Multi")?

Semi-related: if a new Subcategory instance is added to (removed from) a Product.subcategories, we should also add (remove) its parent Category to Product.categories. This could be implemented in the save method, or in a m2m_changed signal.

As for Brand instances, it's perfectly fine not to have any labels / certificates.
As for Store instances, it's perfectly fine not to have any payment_options.

Ha {NAAM},

Super dat je je hebt aangemeld voor Mancelot! Dat was makkelijk toch? En
het vervolg is ook makkelijk!

In 3 simpele stappen verduurzaam je je kledingkast en strijdt je mee voor
eerlijkheid in de kledingindustrie:

1: Kies de kleding die je leuk vindt en zet het op je wishlist;

{INDIEN BETAALVERZOEK:}
2: Accepteer elke maand een betaalverzoekje voor {BEDRAG};
{INDIEN INCASSO:}
2: Zorg dat je elke maand minimaal {BEDRAG} op je rekening hebt voor ons
incasso;

3: Je ontvangt elke 3 maanden verantwoorde kleding

Heb je nog vragen? Check onze website of onze
socials: FB, Insta!

Ridderlijke groet,
Stichting Mancelot

76% of database size is LogEntry instances (1.6 GB) ^_^

• For 404 we may want to temporarily exclude the instance for each queryset. Perhaps after settings.CECE_DATA_RETENTION = 6 months of consecutively hitting 404s we can safely remove the instance altogether (careful for CASCADE tho)

• For 200 we can update model fields that have changed. TODO: how to handle manual updates to the Mancelot admin?

FavoriteProduct instances could have a Product/Size combination that is not available ...

Avatar?
Sizes?
Style?

Probably have to first GET such that Django's session engine kicks in, then retrieve the token from the session cookie. Once the CSRF token is obtained it can be passed through a request header?

Project Cece scrapers all product information nightly. Several Stores + Brands are added weekly. Our update tasks could perhaps run at 06h00, 08h00, 10h00, and 14h00.

We probably want to add to the Brand, Store, Product class (but possibly to any class for which data is retrieved through the Cece API).

• date_added
• date_last_updated
• cece_endpoint

This way the task can run for each Brand, Store, and Product that has not been updated within the last 24h.

Example: User would like to add 5 times the same boxershort to the wishlist. We currently only support saving a particular product, given its id, once.