Use the Tasks API to associate tasks with CRM records.

[rpenha]

Adds support for the Tasks API.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter suggests that using optional parameters can lead to ambiguity and can make the method signature less clear. Instead of using optional parameters, it recommends using method overloading to provide different variations of the method for different use cases. This can improve code readability and maintainability.

To address this, we can create an overloaded method that omits the propertiesWithHistory parameter. Here’s how you can modify the method signature:

Suggested change

	ICollection<string>? propertiesWithHistory = null,
	Task<CrmPage> GetPageAsync(int? limit = null, string? after = null, ICollection<string>? properties = null, ICollection<string>? associations = null, bool? archived = null, CancellationToken cancellationToken = default);

This change removes the optional parameter propertiesWithHistory from the original method signature, allowing for a clearer method definition. You would also need to create an overloaded version of the method that includes propertiesWithHistory as a required parameter.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter suggests that using optional parameters can lead to ambiguity and may hinder method overloading. Instead of using optional parameters, it is recommended to create overloaded methods that provide distinct signatures for different scenarios. This enhances clarity and makes the API more intuitive.

To address this issue, we can create an overloaded version of the GetAsync method that does not include the properties parameter. This way, we avoid using optional parameters altogether.

Here is the suggested change:

Suggested change

	[Query] IReadOnlyList<string>? properties = null,
	Task<HubSpotObject> GetAsync(string id, CancellationToken cancellationToken = default);

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter is related to the use of optional parameters in the method signature. The linter suggests that instead of using optional parameters, you should use method overloading to provide different method signatures. This can improve clarity and usability by allowing callers to specify only the parameters they need without ambiguity.

To fix this issue, you can create an overloaded version of the GetAsync method that does not include the archived parameter. This way, you can maintain the functionality while adhering to the linter's recommendation.

Here's the code suggestion to implement this change:

Suggested change

	[Query] bool? archived = null,
	Task<HubSpotObject> GetAsync(string id, IReadOnlyList<string>? properties = null, IReadOnlyList<string>? propertiesWithHistory = null, IReadOnlyList<string>? associations = null, CancellationToken cancellationToken = default);

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter is that optional parameters can lead to ambiguity and may complicate method overloading and usage. Instead of using optional parameters, it's recommended to create overloaded versions of the method to handle different scenarios. This can improve code clarity and maintainability.

To fix the issue, we can create an overloaded version of the GetPageAsync method that does not include the archived parameter. This way, we maintain clarity and avoid potential pitfalls associated with optional parameters.

Here's the code suggestion to implement this change:

Suggested change

	bool? archived = null,
	Task<CrmPage> GetPageAsync(int? limit = null, string? after = null, ICollection<string>? properties = null, ICollection<string>? propertiesWithHistory = null, ICollection<string>? associations = null, CancellationToken cancellationToken = default);

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Performance issue: Return 'Task' instead.

The issue identified by the SonarC# linter is that the method CreateReadUpdateAndDelete_Succeeds is defined with a return type of async void. This is generally discouraged in asynchronous programming because it can lead to unhandled exceptions and makes it difficult to await the completion of the method. Instead, asynchronous methods should return a Task, which allows the calling code to await the method and handle exceptions properly.

To fix this issue, you should change the return type from async void to async Task. Here's the code suggestion to implement this change:

Suggested change

	public async void CreateReadUpdateAndDelete_Succeeds()
	public async Task CreateReadUpdateAndDelete_Succeeds()

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter is that the use of optional parameters (like int? limit = null) can lead to ambiguity and make the method signatures less clear, especially when there are multiple optional parameters. Instead, it is recommended to use method overloading to provide different variations of the method for different parameter combinations. This approach enhances readability and maintainability.

To fix the issue, we can provide an overloaded version of the GetPageAsync method that does not take the limit parameter, allowing the caller to choose between the two versions.

Here's the code suggestion to implement this change:

Suggested change

	int? limit = null,
	Task<CrmPage> GetPageAsync(CancellationToken cancellationToken = default) => GetPageAsync(null, cancellationToken);

This line adds an overload of the GetPageAsync method that defaults to not specifying a limit, thus addressing the linter's recommendation.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter is that using optional parameters can lead to ambiguity and can complicate method overloading. Instead of defining parameters as optional (with a default value of null), it's recommended to create overloaded methods that provide different combinations of parameters. This improves code clarity and usability.

To address the issue, you can remove the optional parameter and create an overloaded version of the GetAsync method that does not include propertiesWithHistory.

Here’s the single-line code suggestion to fix the issue by removing the optional parameter:

Suggested change

	[Query] IReadOnlyList<string>? propertiesWithHistory = null,
	Task<HubSpotObject> GetAsync(string id, IReadOnlyList<string>? properties = null, IReadOnlyList<string>? associations = null, bool? archived = null, CancellationToken cancellationToken = default);

You would then create a new overload for the method that includes the propertiesWithHistory parameter:

Suggested change

	[Query] IReadOnlyList<string>? propertiesWithHistory = null,
	Task<HubSpotObject> GetAsync(string id, IReadOnlyList<string>? properties = null, IReadOnlyList<string>? propertiesWithHistory = null, IReadOnlyList<string>? associations = null, bool? archived = null, CancellationToken cancellationToken = default);

This way, you can call the appropriate version of the method based on the parameters needed, avoiding the use of optional parameters.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter is that using optional parameters, such as CancellationToken cancellationToken = default, can lead to ambiguity and can complicate method overload resolution. Instead of using optional parameters, the recommendation is to create an overload of the method that does not include the optional parameter. This approach improves clarity and allows for more precise method invocation.

To fix this issue, you can create an overloaded version of the GetAsync method that does not include the cancellationToken parameter, while keeping the original signature intact. Here's the suggested code change:

Suggested change

	CancellationToken cancellationToken = default
	Task<HubSpotObject> GetAsync(string id, IReadOnlyList<string>? properties = null, IReadOnlyList<string>? propertiesWithHistory = null, IReadOnlyList<string>? associations = null, bool? archived = null);

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter is that optional parameters can lead to ambiguity in method overloads, especially when there are multiple optional parameters of the same type. Instead of using optional parameters, the linter suggests using method overloading to provide clearer and more maintainable code.

To fix the issue, we can create an overloaded version of the GetPageAsync method that does not include the properties parameter. This way, we provide an alternative method for cases where the caller does not need to specify properties.

Here's the suggested change:

Suggested change

	ICollection<string>? properties = null,
	Task<CrmPage> GetPageAsync(int? limit = null, string? after = null, ICollection<string>? propertiesWithHistory = null, ICollection<string>? associations = null, bool? archived = null, CancellationToken cancellationToken = default);

This change involves creating an overload that omits the properties parameter, allowing for clearer method calls without the ambiguity of optional parameters.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue highlighted by the SonarC# linter indicates that using optional parameters can lead to ambiguity and can complicate the method signature. Instead of using an optional parameter for associations, the linter suggests using method overloading to provide a clearer and more explicit API.

To fix this issue, we can create an overloaded version of the GetAsync method that does not include the associations parameter. This way, we can keep the method signatures clear and avoid potential confusion.

Here’s the suggested code change:

Suggested change

	[Query] IReadOnlyList<string>? associations = null,
	Task<HubSpotObject> GetAsync(string id, [Query] IReadOnlyList<string>? properties = null, [Query] IReadOnlyList<string>? propertiesWithHistory = null, [Query] bool? archived = null, CancellationToken cancellationToken = default);

This change involves creating a new overload of the GetAsync method without the associations parameter, which allows users to call the method without having to specify that parameter if it is not needed.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter suggests that instead of using optional parameters (like string? after = null), you should utilize method overloading. This is because optional parameters can lead to ambiguity and make the API less clear for consumers. Overloading allows you to create multiple methods with the same name but different parameters, enhancing readability and usability.

To resolve this issue, you can create an overloaded version of the GetPageAsync method without the optional after parameter.

Here’s the suggested change:

Suggested change

	string? after = null,
	Task<CrmPage> GetPageAsync(int? limit = null, ICollection<string>? properties = null, ICollection<string>? propertiesWithHistory = null, ICollection<string>? associations = null, bool? archived = null, CancellationToken cancellationToken = default);

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Use the overloading mechanism instead of the optional parameters.

The issue identified by the SonarC# linter suggests that instead of using optional parameters in the method signature, you should consider using method overloading. This is because optional parameters can lead to ambiguity and make the API less clear, especially when there are multiple optional parameters.

To resolve the issue, you can create an overloaded version of the GetPageAsync method that does not include the associations parameter. This way, you provide a more explicit API design.

Here's the suggested change:

Suggested change

	ICollection<string>? associations = null,
	Task<CrmPage> GetPageAsync(int? limit = null, string? after = null, ICollection<string>? properties = null, ICollection<string>? propertiesWithHistory = null, bool? archived = null, CancellationToken cancellationToken = default);

This change creates a new method overload without the associations parameter, allowing users to call the method without needing to specify all optional parameters.

---

This comment was generated by an experimental AI tool.