CON-281 Fix activity page query

[koitoror]

What does this PR do?

creates a paginated response of events grouped by the user location

Description of Task to be completed?

• group paginated events response by the location of the user

How should this be manually tested?

1. Clone the repo: git clone https://github.com/andela/mrm_api.git
2. Setup project according to Readme.md
3. checkout to branch bug/CON-281-fix-activity-page-query
4. on insomnia to fetch a list of paginated events by user-location send the query

{
 allEvents(startDate: "Mar 21 2017", endDate: "Mar 21 2019", page: 2, perPage: 6) {
   events {
     eventId
     eventTitle
     startTime
     endTime
     room {
       name
       locationId
     }
   }
   pages
   hasPrevious
   hasNext
   queryTotal
 }
}

What are the relevant JIRA stories?

CON-281

Relevant Screenshots

[mnswaleh]

Nice implementation. However, have you considered that a super Admin user might need to view activities in different locations?

[koitoror]

Nice implementation. However, have you considered that a super Admin user might need to view activities in different locations?

Incorporated it. Thanks.

[rajeman]

@koitoror Kindly change the method you used in implementing this task. Fetching all events from DB and filtering by location is not efficient as these events can be very large. I suggest you do the location filtering at the DB level and in case of Super Admin you check if there is a location argument in the query. If there isn't, then you use the Super Admin's location

[koitoror]

@koitoror Kindly change the method you used in implementing this task. Fetching all events from DB and filtering by location is not efficient as these events can be very large. I suggest you do the location filtering at the DB level and in case of Super Admin you check if there is a location argument in the query. If there isn't, then you use the Super Admin's location

Noted

[koitoror]

@koitoror Kindly change the method you used in implementing this task. Fetching all events from DB and filtering by location is not efficient as these events can be very large. I suggest you do the location filtering at the DB level and in case of Super Admin you check if there is a location argument in the query. If there isn't, then you use the Super Admin's location

Noted