Can we use scopes here instead? You may use this and this for reference.

as per slack discussion, we are agoing ahead with elasticsearch

Just wondering if it's a good idea to reuse the same argument variable.

Not sure if we follow this practice or not. But if the variable value is going to be updated and the old value is not going to be used anywhere then there is no harm in using the same variable.

Use let vs @ variables https://www.betterspecs.org/#let

@aditya-vector How can we reduce the use of these instance variables? let! seems to have a limit of 10 variables cc @shalapatil

we can use create_list to create lists of indentical records, and store it in one let variable. we can then use that variable for assertions. @rohitjoshixyz @shalapatil

Check https://github.com/thoughtbot/factory_bot/blob/master/GETTING_STARTED.md for definition on create_list.

Move this to a service class, controller is getting very big

Agreed, all filtering for the controller, perhaps

How about using diminutive return?
Eg:

return where_clause if params[:status].blank?

where_clause.merge(bill_status: params[:status].split(","))

Also, I'm inclined towards adding the presence check beforehand and not as a part of the method itself.

ditto

IMO, this can be fetched as a range directly. Why add separate methods just to fetch a range? We are anyways not using this anywhere else.

Nice!

Small feedback - inclusion totally depends on reviewees' discretion,
How about we use the parameter information at a single source instead, may prove easy to extend

class Filters < ApplicationService
  
  FILTER_PARAM_LIST = %i[date_range status team_member client_id]

  attr_reader :filter_params

  def initialize(filter_params:)
    @filter_params = filter_params
  end

  def process
    FILTER_PARAM_LIST.each_with_object({}) do |filter_param_key, where_condition|
      where_condition.merge(public_send("#{date_range}_filter")) if filter_params[filter_param_key].present?
    end
  end

  # Optional: Remove `_filter` and use filter_param_key as method directly
  def date_range_filter
    { work_date: from_date..to_date }
  end

  def status_filter
    { bill_status: filter_params[:status].split(",") }
  end

  # And other filters as methods and other required methods
end

Note: This is untested, so may need small changes

This is cool! Updated my code with few changes!

entries is too generic, please rename

We can consider adding a class method to reindex this model. Non-blocking To Do, is not a priority at all

Consider adding a trait to the timesheet entry factory for billable and non billable since this getting repeated

User URL helpers and query params in a hash, this is difficult to read

Same for all specs, try and use URL helper for get calls

@aditya-vector How can we reduce the use of these instance variables? let! seems to have a limit of 10 variables cc @shalapatil

suggestion: use let instead of instance variables for specs.

using let is exceeding the limits, which is set to 10 by us. So, can't use it.

For common records we can use create_list() instead of create() to create array of records and can access the record using timesheet_entry[0], timesheet_entry[1], etc.

Require different values for each timsheet entry, so can't create the same ones