GSoC Coding Phase 2 in one glimpse

Microfarm For Everybody | WeField e.V. | coala e.V.

Hello everyone! This blog will give you all a short summary of all the achievements we have achieved till date and of the milestones for the GSoC Coding Phase 2. Here is the link to the project’s codebase on GitLab. The programming stack we have used so far are Django, Rest Framework, Celery, Celery-beat, Django All-auth. Still a lot more to achieve and we will surely achieve them!!

Milestones of Phase 2:

Listed below were the milestones for our project for the coding phase 2 and we were successfully able to complete them within the allotted time.

We were more close to the completion of the project after the first evaluation as the only thing left was `Implement mail notifications` but then we discussed our final product that is going to be in a few months later, it came to be a `flutter application`. So, we then decided to make our back-end specific to the application. So later we created few new milestones and successfully completed them within the deadline!! Let’s see in more detail!

1. Create Section and Bed objects automatically

  • When the user creates/registers the market garden, then we are providing the calculated parameters to make the optimum usage of the space. In that, we are also providing the number of sections that can be created and beds per section.
  • Using this information and django-signals , we are automatically creating the sections and beds when the market garden is created.
  • Related Merge Requests: create section and bed objects automatically

2. Implement Django Admin Views

  • Admin views were created along with each step. Whenever any model was created, it was registered in admin and customized the fields too such as read-only fields, etc.
  • Filter option is also made available, to filter objects by proper and sensible fields such as market-garden, user, etc.
  • Here is the link to the file where models are registered.

3. Creating task objects

  • This part was tricky, i.e., the implementation. We had to implement the tasks objects that have to be created every day and destroyed after the user wants to delete them.
  • These objects hold the status of the tasks, tasks details, market-garden/user details.
  • Creating mere objects having all this info was not feasible, because tasks could be the same for a lot of people, and creating and deleting all the info, again and again, is not that feasible.
  • The solution to this was keeping the details of the tasks separate and giving their reference in the task object. It looks like as below:
class TaskDetails:
class TaskStatus:
task_reference # task id
market_garden # market-garden id
status # upcoming,started,paused,completed or over-due
  • Also set up, celery-beat to generate tasks daily for the all the market-garden.
  • Related Merge Requests: create todo tasks objects

4. Create endpoints of the application

  • The front-end will only talk with the back-end through the APIs. So they are important.
  • The key element was setting the permission so that the user can see and alter objects that are owned by them and have access to change them.
  • Also, the APIs are structured such that they undergo validation before a successful request.

I have tried to use permissions in django as method to validate the urls.
For e.g., the url is api/market/garden/7/section/3/bed/4
Then the permission of IsMarketGardenOwner will check that the user requesting this url is the owner of this Market-garden or not? If yes, permission of IsValidSection then will check that is the section accessed is of the specified market-garden. If yes, then permission of IsValidBedwill check the bed accessed belong to the section provided. Whenever it is False, it will return Forbidden Error . Thus no one can hamper someone’s else data.

  • The permission looks like below:
class IsMarketGardenOwner(permissions.BasePermission):
Object-level permission to only allow owners of the market garden to edit its objects.

message = "You must be the owner of this MarketGarden."

def has_object_permission(self, request, view, obj):
data = get_user_id(request)
return obj.market_garden.user_id == data["user_id"]
class IsValidSection(permissions.BasePermission):
Object-level permission to only allow owners of the market garden to edit
its objects.

def has_object_permission(self, request, view, obj, **kwargs):
return == view.kwargs["pk_mk"]

class IsValidBed(permissions.BasePermission):
Object-level permission to only allow owners of the market garden to edit
its objects.

def has_object_permission(self, request, view, obj, **kwargs):
section = get_object_or_404(Section, pk=view.kwargs["pk_sec"])
if == view.kwargs["pk_mk"]:
return == view.kwargs["pk_sec"]
return False

5. Create APIs Documentation

  • No one wants to look at hundreds of APIs having no information about the Parameters and Methods Allowed ( GET, POST, PUT, PATCH, DELETE )
  • Yes, Django provides the default Browsable APIs feature but it doesn't work with JWT Token, so there was a need for an alternative.
  • We then added APIs Views and Document Views using drf-yasg which uses Swagger UI and ReDoc under the hood. It provides browsable API views. You can try out all the APIs but Registration/Login is required!!
  • Screenshots of the APIs and Document Views

Thus, we have completed and achieved all the milestones in Coding Phase 2. The GSoC coding period has ended. But still the project is on! I would like to thank my mentors Finn Peters, Keshav Garg, and Abhinav Kaushlya for their incredible support and guidance throughout this period and for making this GSoC project a successful one! It was such an amazing experience!

Thank you for reading the blog until here!!

Student Developer @WeField @coala | Cloud Enthusiast | Open-Source Contributor | NIT Surat