We haven't discussed this, but after some time to mull this over, it may be best to allow the Order model to have a paid field. This allows you to always create the order in the store (upon checkout) and have it either listed as paid or unpaid. This is best because:

1 - For users without a stripe integration, you might provide a button to mark the order as paid.
2 - For users with a stripe integration you can pass the order_id to metadata, and upon the webhook trigger, grab the order from the db and mark it as paid.
This is overall more robust.

• The paid_on field can be a boolean but ideally would be a DateTime field that you can treat as a boolean in your orm_queries. paid_on__isnull=False. Why a datetime field? Well, datetime fields are better booleans because not only can they provide truthfulness they also give you a date of that truth.

Let's discuss this as a future enhancement.

Increase test coverage by ensuring the logic to create a store is fully tested.

As discussed on today's call (29-July-24):
Going with Strip hosted page: https://docs.stripe.com/checkout/quickstart?lang=python

Here is some code we created today as an example of integrating the quickstart into your project. Not tested but should be close to the final thing:

def create_checkout_session(request, order_id):
    order = get_object_or_404(Order, pk=order_id)
    try:
        checkout_session = stripe.checkout.Session.create(
            line_items=[
                {
                    'price': ord.get('price'),
                    'quantity': ord.get('quantity'),
                } for ord in order.orderitem_set.all()
            ],
            mode='payment',
            success_url=DOMAIN_NAME + '/success.html',
            cancel_url=DOMAIN_NAME + '/cancel.html',
        )
    except Exception as e:
        return str(e)

    return redirect(checkout_session.url, code=303)

The orders page should list all orders for the logged in users store.

• create a orders_admin view in your views.py
• add loginRequiredMixin
• list the orders that are currently in the store
• clicking on the order should open the product up for viewing or editng
• add a delete option to delete the desired order if required
• ensure that the route to the orders admin page is added on the Store Admin menu

This issue further breaks out issue #2

Deploy the website on your desired platform

Ever since adding the store, our test suite continues to fail seemingly due to the Store subfactory?

• troubleshoot the failure to resolve the current tests written up to this point

Think about the user story with django-ecommerce.

1. they go to the site
2. add products to bag from the list of available products (across any store)
3. checkout the order and then are required to select a store? - probably not the best user experience right?

• consider listing available stores on home page or providing a route per store /store or store.
• when the user either navigates to the store, only that store's products are displayed.

In this way, the user checkout eliminates the need for them to pick a store as you can pass the user's store to the form in code.

By adding a 'Store' model and related o2m, fk relationships across relevant models you can allow the app to be utilized as a Saas.

How to do this:

1 - Add a Store model in your models.py. This model needs a 'name' and 'owner' fields. The owner field should be a FK to User model.

class Store(models.Model):
    name = models.CharField(max_length=100)
    owner = models.ForeignKey(
        User, on_delete=models.CASCADE
    )

2 - Add the store field to the Product and Order models as a FK.
store = models.ForeignKey('Store', related_name='products', on_delete=models.CASCADE)

3 - Make Migrations/Migrate addressing any db issues that might arise such as assigning a default value for the non-nullable 'store' field.

• don't forget to add a str method for the Store model.

How does this store model give the app Saas capability?

• Now that you have the store model it is possible to know who the owner of each db row is. This allows you to perform the necessary filters in your views or queryset managers when returning db values.

After the user signs up and logs in, they will want to create a store.

• add logic that allows a user to create a store
• consider the user story, Product Admin etc should not be an option until the user creates a store.

In addition to your happy path tests, I'd like to see tests for the following:

• test that a user from a different store is unable to modify or delete products that do not belong to their store using the routes you have defined.
• test what happens when a user has multiple stores, does the app still work as expected? Are there errors? How will you address?

Think about the user story.

Some thoughts to consider

• Is the user allowed to have items in his/her bag from multiple stores?
• Even if the user cannot purchase from multiple stores there doesn't seem to be a need to include store on the order model.
• If the user can only shop from one store at a time what logic needs to be added when a user attempts to add a product to bag from another store?

Proposed Action

• store field should be removed from Order model. Each product already contains the fk to the store

The product page should list all the products in the store for the currently logged in admin and so on.

• create a products_admin view in your views.py
• add loginRequiredMixin
• list the products that are currently in the store
• clicking on the product should open the product up for viewing or editng
• add a delete option to delete the desired product
• ensure that the route to the products page is added on the Store Admin menu

This issue further breaks out issue #2

Given the current state of the db due to the phonenumber field class I recommend blowing away your migrations and rebuilding your DB. Optional, but I would also move to sqlite for this phase of the project. Here are the steps to take:

• Delete all migrations or move to new folder
• modify DATABASES setting in settings.py for store app to:

    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db.sqlite3",
    }
}

• Make migrations python manage.py makemigrations
• migrate python manage.py migrate
• finally run your tests and verify that there are no db or migration errors. You will have some failed tests due to phone number field validation that you should resolve as needed.

In this space, the administrator should be able to:

• perform crud operations on products
• perform crud operations on customer orders
• perform crud operations on customers
• run desired reports
• export data as csv and or pdf (customers, orders, products)

This will allow you to have the same level of dependency management across your projects making them easier to maintain and upgrade in the future.

Under the Store Admin or where best suited add the ability to run reports.
Reports should be downloadable csvs or printable pdfs.

Initial Reports:

• Customer list
• Sales Report
• Products Listing

For these reports

• you might create a function in your class to render_to_response that you might accept an argument for csv or pdf as an example.
• csv can be the default and simply return a httpresponse with a csv file.

https://github.com/django-crispy-forms/django-crispy-forms/

You don't need to implement if you don't wish to but having knowledge of these libraries and how to implement them make you more well-rounded as a django developer.

To add the ability to login with all of the necessary actions such as

• forgot password
• reset password
• social login / don't need to implement right away
  https://docs.allauth.org/en/latest/

ipdb is an excellent debugger. So good that later versions of python will include some of its functionality baked right into pdb.

to add ipdb

1. pip install ipdb
2. (don't forget to add to req.in)
3. in your manage.py add the following:

# set ipdb as my default breakpoint
os.environ["PYTHONBREAKPOINT"] = "ipdb.set_trace"

Now whenever you use breakpoint() you will go into a much richer debugging experience. Remember you spend most of your time debugging code.

Improve the look and feel of the e-commerce website using CSS.
The aim is to make the site feel modern. You may consider the following challenges (optional):

• adding dark-mode support
• adding 1 or 2 themes that the user can select under their admin

@kjcioffi I wanted to break down #2 issue down further so that it is more easily addressed:

• create a view in views.py that returns a page store_admin.html
• • This view should have the loginrequired mixin
• on this template render a menu as desired (e.g sidebar or vertical bar menu with the required pages, products, orders etc)

for staticfiles and user-uploaded files.

• Create a post sharing your win with the community.
  You will find that PyBites community members truly enjoy sharing in the winds of other community members - especially when they can take a look at what you've built.

• Add a link to signup in the navbar

https://docs.github.com/en/actions

• setup a rust linter on your code on push
• setup a test runner to run your unit tests on PR
• Create an action to check code coverage on PR

Take a look at Weasyprint (write html/css and turn into pdf - easiest): https://doc.courtbouillon.org/weasyprint/stable/

or ReporLab (use their templating language to create reports - more involved): https://docs.reportlab.com/

• Select a library based on the documentation and add it to project dependencies