Repository: dotkom/onlineweb4

Issue:
Broken date handling in careeropportunity display date
## What kind of an issue is this?

- [x] Bug report
- [ ] Feature request


## What is the expected behaviour?
A careeropportunity should be displayed from the start date.

## What is the current behaviour?
If the start date is in the past, but sufficiently close to the current date, the careeropportunity is not displayed. Setting the start date to an earlier date fixes the problem.

<!-- if this is a bug report -->


## How do you reproduce this problem? 

Set start date to the middle of the night the day before the current day.
Broken date handling in careeropportunity display date
## What kind of an issue is this?

- [x] Bug report
- [ ] Feature request


## What is the expected behaviour?
A careeropportunity should be displayed from the start date.

## What is the current behaviour?
If the start date is in the past, but sufficiently close to the current date, the careeropportunity is not displayed. Setting the start date to an earlier date fixes the problem.

<!-- if this is a bug report -->


## How do you reproduce this problem? 

Set start date to the middle of the night the day before the current day.


Discussion:
This has nothing to do with how much in the future the event is set.

The queryset attribute is evaluated when the process starts. If an opportunity object is set to start after the server evaluated the queryset, it won't make the cut, since `timezone.now()` was evaluated at the first execution and then stored.

A simple fix is to override the `get_queryset` method instead which will evaluate `timezone.now()` every time the request is run rather than the first time it is evaluated.
This has nothing to do with how much in the future the event is set.

The queryset attribute is evaluated when the process starts. If an opportunity object is set to start after the server evaluated the queryset, it won't make the cut, since `timezone.now()` was evaluated at the first execution and then stored.

A simple fix is to override the `get_queryset` method instead which will evaluate `timezone.now()` every time the request is run rather than the first time it is evaluated.

Resolving patch:
diff --git a/apps/careeropportunity/urls.py b/apps/careeropportunity/urls.py
--- a/apps/careeropportunity/urls.py
+++ b/apps/careeropportunity/urls.py
@@ -12,4 +12,4 @@
 
 # API v1
 router = SharedAPIRootRouter()
-router.register(r'career', views.CareerViewSet)
+router.register(r'career', views.CareerViewSet, base_name='careeropportunity')
diff --git a/apps/careeropportunity/views.py b/apps/careeropportunity/views.py
--- a/apps/careeropportunity/views.py
+++ b/apps/careeropportunity/views.py
@@ -24,10 +24,12 @@ class CareerViewSet(viewsets.GenericViewSet, mixins.RetrieveModelMixin, mixins.L
     Viewset for Career serializer
     """
 
-    queryset = CareerOpportunity.objects.filter(
-        start__lte=timezone.now(),
-        end__gte=timezone.now()
-    ).order_by('-featured', '-start')
     serializer_class = CareerSerializer
     permission_classes = (AllowAny,)
     pagination_class = HundredItemsPaginator
+
+    def get_queryset(self, *args, **kwargs):
+        return CareerOpportunity.objects.filter(
+            start__lte=timezone.now(),
+            end__gte=timezone.now()
+        ).order_by('-featured', '-start')


Test patch: