Skip to content

Add support for multi-valued status filter in tasks API #315

Closed

Description

@aromanet42

According to Crowdin API Documentation https://support.crowdin.com/developer/api/v2/#tag/Tasks/operation/api.projects.tasks.getMany, the API listing tasks accepts mutiple values for the status filter:

List tasks with specified statuses. It can be one status or a list of comma-separated status values

The SDK only accepts one status.

Could you support a list of statuses in Tasks APIs?

Thanks

Activity

  1. Rituraj2610 commented on Apr 2, 2025

    @Rituraj2610

    Hii, Can you help me understand more about this project?

  2. andrii-bodnar commented on Apr 2, 2025

    @andrii-bodnar
    Member

    Hi @Rituraj2610, please refer to the CONTRIBUTING guide.

  3. korzol commented on Sep 22, 2025

    @korzol
    Contributor

    Hello. I can get this issue as well. Kindly assign it to me

  4. korzol commented on Sep 22, 2025

    @korzol
    Contributor

    Hello @andrii-bodnar

    To support filtering by multiple statuses, I suggest adding a new method with a different name, like listTasksMultipleStatuses(...)
    Overloading the existing listTasks(...) with a EnumSet version causes issues when passing null, since Java can’t tell whether it's meant to be a Status or a EnumSet
    Hence it breaks existing code like:

    listTasks(projectId, null, null, null, null);

    Other solutions I looked at were either too complex or introduce breaking changes.
    A separate method is the simplest and safest solution with no breaking changes

    Let me know if adding new method with different name sounds like a good idea

  5. andrii-bodnar commented on Sep 22, 2025

    @andrii-bodnar
    Member

    Hello @korzol,

    I believe we can still have the overloaded listTasks method. For example, take a look at the listScreenshots implementation:

    public ResponseList<Screenshot> listScreenshots(Long projectId, List<String> stringIds, List<String> labelIds, List<String> excludeLabelIds, Integer limit, Integer offset) throws HttpException, HttpBadRequestException {
    ListScreenshotsParams screenshotsParams = new ListScreenshotsParams();
    screenshotsParams.setStringIds(Optional.ofNullable(stringIds).map(l -> String.join(",", l)).orElse(null));
    screenshotsParams.setLabelIds(Optional.ofNullable(labelIds).map(l -> String.join(",", l)).orElse(null));
    screenshotsParams.setExcludeLabelIds(Optional.ofNullable(excludeLabelIds).map(l -> String.join(",", l)).orElse(null));
    screenshotsParams.setLimit(limit);
    screenshotsParams.setOffset(offset);
    return this.listScreenshots(projectId, screenshotsParams);
    }

    There are three different overloaded methods for this case. It also has a similar requirement with the comma-separated values.

    In our case, we could probably create another listTasks with List<Status> status. Please let me know what you think.

  6. korzol commented on Sep 23, 2025

    @korzol
    Contributor

    Thanks for the example with listScreenshots

    The reason the overloads work fine there is that the method signatures differ not only by types but also by the number of parameters:

    // 6 parameters
    listScreenshots(Long, List<String>, List<String>, List<String>, Integer, Integer)
    
    // 4 parameters
    listScreenshots(Long, Long, Integer, Integer)
    

    So even if null is passed, Java can clearly resolve which method to call based on the number of arguments.

    In the case of listTasks(), we have two overloads:

    // Same number of parameters
    listTasks(Long, Integer, Integer, Status, Integer)
    listTasks(Long, Integer, Integer, EnumSet, Integer)
    

    These ^ have the same number of parameters, and both Status and EnumSet can accept null. So when calling:

    listTasks(projectId, null, null, null, null);

    Java throws an "ambiguous method call" error — it doesn't know which method to use.

    I see these possible ways to make overload works:

    • Explicitly cast null to make the call unambiguous, like:
      listTasks(projectId, null, null, (Status) null, null);

    • Use a different method signature (e.g. different number of arguments)

    • Use a differently named method for the multiple-status case

    • Never use it like
      listTasks(projectId, null, null, null, null);

    Kindly let me know what you think - happy to adjust the approach based on feedback

  7. andrii-bodnar commented on Sep 23, 2025

    @andrii-bodnar
    Member

    @korzol thanks for the explanation!

    Can we then have an overload like this: listScreenshots(Long projectId, ListScreenshotsParams params)?

  8. korzol commented on Sep 23, 2025

    @korzol
    Contributor

    @andrii-bodnar Absolutely. Will do it like this listTasks(Long projectId, ListTasksParams params)

  9. andrii-bodnar commented on Sep 23, 2025

    @andrii-bodnar
    Member

    Yes, something like this. This approach is ideal when we have many optional parameters. It's also very easy to update this class when we add new parameters to the API and maintain backward compatibility with existing users.

  10. korzol commented on Sep 23, 2025

    @korzol
    Contributor

    Thank you. Of course, this is definitely the cleanest and most flexible way to support optional parameters and future-proof the API.

  11. korzol commented on Sep 23, 2025

    @korzol
    Contributor

    @andrii-bodnar PR is ready for review #334

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions