Merge branch 'main' into fix_janushytte_info

Author: AndreasTauge

.github/workflows/ci.yml

@@ -104,7 +104,7 @@ jobs:
             APP_ENV=production
 
       - name: Upload artifact
-        uses: actions/upload-artifact@v3
+        uses: actions/upload-artifact@v4
         with:
           name: ${{ env.dockerfile }}
           path: /tmp/${{ env.dockerfile }}.tar
@@ -131,7 +131,7 @@ jobs:
         uses: actions/checkout@v4
 
       - name: Download image from previous job
-        uses: actions/download-artifact@v3
+        uses: actions/download-artifact@v4
         with:
           name: backend-production
           path: /tmp
@@ -222,7 +222,7 @@ jobs:
             APP_ENV=test
 
       - name: Upload artifact
-        uses: actions/upload-artifact@v3
+        uses: actions/upload-artifact@v4
         with:
           name: ${{ env.dockerfile }}
           path: /tmp/${{ env.dockerfile }}.tar
@@ -244,7 +244,7 @@ jobs:
         uses: actions/checkout@v4
 
       - name: Download image from previous job
-        uses: actions/download-artifact@v3
+        uses: actions/download-artifact@v4
         with:
           path: /tmp
 
@@ -262,7 +262,7 @@ jobs:
         run: docker compose -f docker-compose.integration.yml up -d
 
       - name: Run Cypress
-        uses: cypress-io/github-action@v6.7.6
+        uses: cypress-io/github-action@v6.7.8
         with:
           record: true
           parallel: true

README.md

@@ -561,6 +561,75 @@ An outline of how a developer may work with this project:
   - Respond to any questions or concerns they may have with your Pull Request
   - If an automatic test fails, click `Details` on it to see what went wrong in the logs
   - Once your Pull Request is approved, and the tests pass, you can merge it - now your changes are live!
+### Comprehenceive Api and Backend Models Guide
+
+#### Making a model (changes to the database)
+
+The models.py file is essentially a description of what should be stored in our database. Types.py tells graphene, the service we use to autogenerate a ton of stuff what types the database has.
+
+If you are adding a brand new models.py file make sure to add your changes to LOCAL_APPS in the base.py of our django settings. In order to make the migrations work you will also need a migrations folder containing a file named **init**.py. The file init file is empty but nessecary.
+
+After changes have been made to thease files you need to push them to the database. This is done first by making the migrations using `docker compose exec backend python manage.py makemigrations` After the migrations are made you migrate useing `docker compose exec backend python manage.py migrate`. For the changes to show up in the admin panel you will need to restart docker
+
+#### Making a query
+
+A query is a request for data made to the backend by the frontend. The following is a guide on how to make queries.
+
+##### Queries in Backend
+
+All queries have a respective resolver function in the backends `resolvers.py` function. This is how the backend knows what to send to the frontend. A resolver function is ALWAYS named `resolver_something`. Note that Python uses camel case and GraphQL does not. This means that in communication the frontend is going to capitalize the letter(s) after the underscore(s) and remove the underscore. For example, the resolver, `resolve_get_winners_list`, will be referenced as `getWinnersList` in the frontend.
+
+All resolvers must also be referenced in the `schema.py` file. Here they are again named using camel case and given return types, often the type is just the model from `models.py`.
+
+If you are making the first queries of this backend folder you will also need to add the schema to `backend/config/schema.py`. This is to tell the command `python manage.py graphql_schema` to include the new schema file that it exists.
+
+After adding the new resolvers you can run `docker compose exec backend python manage.py graphql_schema` in the `indok-web` directory to add the new schema. The query is now done from the backend perspective. NOTE: if you have forgotten to add the resolver to the schema or done so incorrectly the terminal will say it was successful. After this command, there should be a change in `schema.json`.
+
+##### Queries in Frontend
+
+In the frontend all query defining is done in the `graphql` folder. The generated folder should not be touched! (However it can be useful to look at in troubleshooting).
+
+The `graphql` folder usually has 3 files, mutations, queries and fragments. Fragemnts are selections of fields on one of our API types, that can be reused across different queries/mutations to ensure consistent types. You can read more here: (https://www.apollographql.com/docs/react/data/fragments/). If a selection is used only once it can be written in the queries file directy.
+
+After having written your query run the command `yarn generate` in the frontend directory to generate machine readable queries.
+
+After the above is done the queries can be used and tested. In code they are used using the apollo function useQuery. Here is an example: `const { error, loading, data } = useQuery(GetWinnersListDocument);`. Notice the three terms before the query. Things can ALWAYS go wrong with queries and they requre data to be sent, therefore it is common to define what is done in rare cases.
+
+- `data` is the normal data when the query has returned something expected from the backend.
+- `loading` is a waiting status. Queries are not instant and it can be useful to define some action while waiting.
+- `error` is what you recive if the query returned that something has gone wrong. This should almost always have some sort of notification to the user and or admins.
+
+An important security notice: Permissions are handled in the backend. It is possible for anyone to try to call queries withut a frontend interface, it is therefore important that all queries that should have a permission check has them before it is pushed to production regardless of if there exists a frontend interface.
+
+One last note about queries is that we limit size. If you return more than about 300 items the query will fail. Therefore it is important that sorting and things of that kind is done in the backend.
+
+#### Making a mutation
+
+A mutation is a request for data to be changed or added made to the backend by the frontend. The following is a guide on how to make mutations. Note that it is very similar to making a query.
+
+##### Queries in Backend
+
+All mutations have a respective mutation class in the backends `mutations.py` file. This is how the backend knows what to change when the mutation is called. A mutation class has no strict naming scheme but it is higly reccommended to end the name in "Mutation". Every mutation class has a function named mutate that does the changing, an Arguments class that takes in the data that can be passed from the frontend, and an ok that is returned if the mutation is successful.
+
+All mutations must also be referenced in the `schema.py` file. Here they are named using camel case for the name of the mutation.
+
+If you are making the first mutations of this backend folder you will also need to add the schema to `backend/config/schema.py`. This is to tell the command `python manage.py graphql_schema` to include the new schema file that it exists.
+
+After adding the new resolvers you can run `docker compose exec backend python manage.py graphql_schema` in the `indok-web` directory to add the new schema. The mutation is now done from the backend perspective. NOTE: if you have forgotten to add the resolver to the schema or done so incorrectly the terminal will say it was successful. After this command, there should be a change in `schema.json`.
+
+An important security notice: Permissions are handled in the backend. It is possible for anyone to try to call mutations withut a frontend interface, it is therefore important that all mutations that should have a permission check has it before it is pushed to production regardless of if there exists a frontend interface.
+
+##### Mutations in Frontend
+
+In the frontend all mutation defining is done in the `graphql` folder. The generated folder should not be touched! (However it can be useful to look at in troubleshooting).
+
+The `graphql` folder usually has 3 files, mutations, queries and fragments. Obvously mutations are written in the mutations folder.
+
+After having written your mutation run the command `yarn generate` in the frontend directory to generate machine readable mutation.
+
+After the above is done the queries can be used and tested. In code they are used using the apollo function useUsemutation to define a function that can be run. Here is an example: `const [logTicTacToe] = useMutation(LogTicTacToeDocument);`. After this the `logTicTacToe` function can be used to run the mutation. It lookes like this: `logTicTacToe({ variables: { winner: "Draw" } })`; Note that this does not trigger a react rerender so if you need to change visuals you need to handle that as well.
+
+An important security notice: Permissions are handled in the backend. It is possible for anyone to try to call queries withut a frontend interface, it is therefore important that all queries that should have a permission check has them before it is pushed to production regardless of if there exists a frontend interface. Most mutations (mabye all the ones we currenly have) need a permission check.
 
 ## Tech Stack
 

backend/apps/ecommerce/resolvers.py

@@ -38,9 +38,22 @@ def resolve_user_orders(self, info):
     def resolve_all_user_orders(self, info):
         return Order.objects.all()
 
+    @login_required
     @staff_member_required
-    def resolve_all_shop_orders(self, info):
-        return Order.objects.filter(product__shop_item=True)
+    def resolve_paginated_shop_orders(self, info, limit, offset):
+        # Apply pagination if limit and offset are provided
+        orders = Order.objects.filter(product__shop_item=True).order_by(
+            "delivered_product", "payment_status", "timestamp"
+        )
+        if offset is None:
+            offset = 0
+        orders = orders[offset:]
+
+        if limit is None or limit > 300:
+            # Add hard cap of maximum 300 orders per query. A bigger query would crash the website
+            limit = 300
+        orders = orders[:limit]
+        return orders
 
     @staff_member_required
     def resolve_orders_by_status(self, info: "ResolveInfo", product_id, status):

backend/apps/ecommerce/schema.py

@@ -19,7 +19,7 @@ class EcommerceQueries(graphene.ObjectType, EcommerceResolvers):
     order = graphene.Field(OrderType, order_id=graphene.ID(required=True))
     user_orders = graphene.List(NonNull(OrderType))
     all_user_orders = graphene.List(NonNull(OrderType))
-    all_shop_orders = graphene.List(NonNull(OrderType))
+    paginated_shop_orders = graphene.List(graphene.NonNull(OrderType), limit=graphene.Int(), offset=graphene.Int())
 
     orders_by_status = graphene.Field(
         OrdersByStatusType, product_id=graphene.ID(required=True), status=graphene.String(required=True)

backend/apps/ecommerce/tests.py

@@ -457,3 +457,85 @@ def test_delivered_product(self) -> None:
 
         order = Order.objects.get(pk=order.id)
         self.assertTrue(order.delivered_product)
+
+
+class PaginatedShopOrdersResolverTests(ExtendedGraphQLTestCase):
+    def setUp(self):
+        # Create a staff user using the StaffUserFactory
+        self.staff_user = StaffUserFactory(username="staffuser")
+
+        # Ensure the user satisfies the requirements for the new decorators
+        self.staff_user.is_staff = True  # Required for @staff_member_required
+        self.staff_user.is_superuser = True  # Required for @superuser_required if added
+        self.staff_user.save()
+
+        # Create a product with `shop_item=True` to pass the resolver's filter condition
+        self.product = ProductFactory(
+            name="Test Product",
+            price=decimal.Decimal("1000.00"),
+            description="A test product description",
+            max_buyable_quantity=2,
+            total_quantity=5,
+            shop_item=True,  # Ensure this matches the resolver's filter condition
+        )
+
+        # Create multiple orders associated with the product and user
+        self.orders = [
+            OrderFactory(
+                product=self.product,
+                user=self.staff_user,
+                payment_status=Order.PaymentStatus.INITIATED,
+            )
+            for i in range(10)
+        ]
+
+    def test_paginated_shop_orders_with_fragment_and_product(self):
+        query = """
+        query paginatedShopOrders($limit: Int, $offset: Int) {
+          paginatedShopOrders(limit: $limit, offset: $offset) {
+            ...Order
+          }
+        }
+
+        fragment Order on OrderType {
+          id
+          quantity
+          totalPrice
+          paymentStatus
+          timestamp
+          deliveredProduct
+          product {
+            ...Product
+          }
+        }
+
+        fragment Product on ProductType {
+          id
+          name
+          price
+          description
+          maxBuyableQuantity
+          shopItem
+        }
+        """
+
+        # Execute the query using the query method from ExtendedGraphQLTestCase
+        response = self.query(query, variables={"limit": 5, "offset": 2}, user=self.staff_user)  # Use staff user
+        data = json.loads(response.content)
+
+        # Check if the response data matches expectations
+        self.assertIn("data", data)
+        self.assertIn("paginatedShopOrders", data["data"])
+        self.assertEqual(len(data["data"]["paginatedShopOrders"]), 5)
+
+        # Verify the structure of the nested product field in the first order
+        first_order = data["data"]["paginatedShopOrders"][0]
+        self.assertIn("product", first_order)
+        self.assertEqual(first_order["product"]["name"], "Test Product")
+        self.assertEqual(first_order["product"]["price"], "1000.00")  # Adjusted for consistency
+        self.assertTrue(first_order["product"]["shopItem"])
+
+        # Additional checks for other fields
+        self.assertIn("quantity", first_order)
+        self.assertIn("paymentStatus", first_order)
+        self.assertIn("timestamp", first_order)

backend/schema.json

@@ -301,11 +301,32 @@
               }
             },
             {
-              "args": [],
+              "args": [
+                {
+                  "defaultValue": null,
+                  "description": null,
+                  "name": "limit",
+                  "type": {
+                    "kind": "SCALAR",
+                    "name": "Int",
+                    "ofType": null
+                  }
+                },
+                {
+                  "defaultValue": null,
+                  "description": null,
+                  "name": "offset",
+                  "type": {
+                    "kind": "SCALAR",
+                    "name": "Int",
+                    "ofType": null
+                  }
+                }
+              ],
               "deprecationReason": null,
               "description": null,
               "isDeprecated": false,
-              "name": "allShopOrders",
+              "name": "paginatedShopOrders",
               "type": {
                 "kind": "LIST",
                 "name": null,

frontend/content/organizations/eiv.md

@@ -5,9 +5,11 @@ logo: /img/eivlogo.jpg
 image: /img/eivbilde.jpg
 board:
   ceo:
-    name: Johan Martin Emberland Johnsen
-    title: Sommelier
-
+    name: Olav Utle Kolltveit
+    title: Head of Red
+  cto:
+    name: Nora Vengstad Furøy
+    title: Head of Bread
 tag: kultur
 ---
 
@@ -20,4 +22,4 @@ Fagseksjonen for EiV legger grunnlaget for å gradere friskhet, sødme, fylde og
 ![Vin på Indøk!](/img/eivbilde.jpg)
 
 Ved spørsmål ta kontakt med styrets sommelierer:
-Phillip Kolkmeier, Erlend Heir, Haakon Døssland og Ane Sandvik Rognskaug
+Olav Utle Kolltveit og Nora Vengstad Furøy

frontend/content/organizations/rubberdok.md

@@ -5,14 +5,14 @@ logo: /img/rubberdok_logo_black.svg
 image: /img/rubberdoklogo1.png
 alt: Logoen til rubberdøk
 board:
-  cto:
-    name: Magnus Hafstad
-    title: Prosjektleder
-    mail: magnus.hafstad@rubberdok.no
   ceo:
     name: Hannah Köberle
     title: Prosjektleder
-    mail: hannah.koeberle@rubberdok.no
+    mail: leder@rubberdok.no
+  cto:
+    name: Oda Fu Zhe Runde
+    title: Prosjektleder
+    mail: leder@rubberdok.no
 tag: annet
 ---
 

frontend/package.json

@@ -58,9 +58,9 @@
     "@graphql-codegen/typescript": "4.0.6",
     "@graphql-codegen/typescript-operations": "4.2.3",
     "@graphql-typed-document-node/core": "^3.2.0",
-    "@next/bundle-analyzer": "^13.4.19",
+    "@next/bundle-analyzer": "^14.2.7",
     "@parcel/watcher": "^2.4.1",
-    "@repeaterjs/repeater": "^3.0.4",
+    "@repeaterjs/repeater": "^3.0.6",
     "@types/lodash": "^4.14.197",
     "@types/node": "18",
     "@types/react": "18.2.46",