-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor/date limit soc feedback command #38769
base: contrib/hoxhunt_refactor/date-limit-soc-feedback-command
Are you sure you want to change the base?
Refactor/date limit soc feedback command #38769
Conversation
Thank you for your contribution. Your generosity and caring are unrivaled! Make sure to register your contribution by filling the Contribution Registration form, so our content wizard @sapirshuker will know the proposed changes are ready to be reviewed. |
Hi @tomaskukk, thanks for contributing to the XSOAR marketplace. To receive credit for your generous contribution please follow this link. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @tomaskukk ,
Thank you for your contribution!
Good work :)
Please see my suggestions.
In addition please fix the pre-commit issues.
Please feel free to reach out to me with any questions - I'm available here or on slack :)
Thanks again
Packs/Hoxhunt/ReleaseNotes/2_0_1.md
Outdated
|
||
##### Hoxhunt v2 | ||
|
||
- Added support for more flexible date formats in the `threat_feedback_reported_at_limit` argument. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Added support for more flexible date formats in the `threat_feedback_reported_at_limit` argument. | |
- Added support for more flexible date formats in the *threat_feedback_reported_at_limit* argument in the ***hoxhunt-incident-soc-feedback-send*** command. |
@@ -457,6 +457,10 @@ def camel_to_title(text: str) -> str: | |||
result.append(char) | |||
return ''.join(result).strip().title() | |||
|
|||
# Hoxhunt GQL API expects dates in ISO format | |||
def format_date_to_iso_string(date: datetime | None) -> str: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have the same functionality in the CommonServerPython timestamp_to_datestring and date_to_timestamp
These methods already exist, you can make use of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The date_to_timestamp returns the date as int (so probably epoch unix timestamp), and timestamp_to_datestring takes in the date as int or str, so I would need to parse the datetime to int / str first.
Would using the built in strftime
be okay here so no need to do extra conversions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the docs, timestamp_to_datestring parse timestamp (milliseconds) to a date string and takes str or int, str such as "1541494441222" and int such as 1541494441222
So you need to use date_to_timestamp in order to convert the date to milliseconds and timestamp_to_datestring in order to convert the milliseconds to iso format. Another way is to use date.isoformat()
Hey @sapirshuker, I fixed the documentation suggestion and commented on the other comment. Pre-commit is passing now (the validation passed locally without issues but raised issues on CI, even with newest Should be good to be reviewed again! |
For the Reviewer: Trigger build request has been accepted for this contribution PR. |
For the Reviewer: Successfully created a pipeline in GitLab with url: https://gitlab.xdr.pan.local/xdr/cortex-content/content/-/pipelines/2604160 |
@@ -232,3 +232,6 @@ tests: | |||
defaultclassifier: Hoxhunt-classifier | |||
defaultmapperin: Hoxhunt-mapper-incoming | |||
defaultmapperout: Hoxhunt-mapper-outgoing | |||
sectionOrder: | |||
- Connect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add the section header to the to the beginning of the file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! (this was formatting work of demisto-sdk format
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, thank you for your contribution! Did you notice the comment I wrote in response to your question? If not, I will write it again regarding the use of existing functions to convert the date to the requested format. Thank you! Waiting for your response.
|
||
|
||
def format_date_to_iso_string(date: datetime | None) -> str: | ||
return date.strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3] + 'Z' # type: ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the docs, timestamp_to_datestring parse timestamp (milliseconds) to a date string and takes str or int, str such as "1541494441222" and int such as 1541494441222
So you need to use date_to_timestamp in order to convert the date to milliseconds and timestamp_to_datestring in order to convert the milliseconds to iso format. Another way is to use date.isoformat()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I missed this comment completely earlier. I will fix it now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, used the date.isoformat
!
For the Reviewer: Trigger build request has been accepted for this contribution PR. |
For the Reviewer: Successfully created a pipeline in GitLab with url: https://gitlab.xdr.pan.local/xdr/cortex-content/content/-/pipelines/2625584 |
For the Reviewer: Trigger build request has been accepted for this contribution PR. |
For the Reviewer: Successfully created a pipeline in GitLab with url: https://gitlab.xdr.pan.local/xdr/cortex-content/content/-/pipelines/2625588 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @tomaskukk , thank you very much for the change, the contribution, and your patience. Working with dates can be frustrating and there are edge cases that need to be considered. While the contribution is short, we need to ensure that we are not causing bugs. We can schedule a meeting together to think about the solution together.
@@ -153,7 +156,7 @@ script: | |||
type: unknown | |||
- name: threat_feedback_reported_at_limit | |||
required: true | |||
description: Datetime limit as a iso string (e.g. "2024-10-30T08:37:42.359Z"). | |||
description: Datetime limit. Accepts (<number> <time unit>), e.g "7 days", "one month" or a iso string (e.g. "2024-10-30T08:37:42.359Z"). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to add this change to the readme file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point!
@@ -639,7 +645,7 @@ def get_modified_remote_data_command(client: Client, args: dict, params: dict): | |||
remote_args = GetModifiedRemoteDataArgs(args) | |||
last_update = remote_args.last_update | |||
last_update_parsed = dateparser.parse(last_update, settings={'TIMEZONE': 'UTC'}) | |||
last_update_utc = last_update_parsed.strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3] + 'Z' # type: ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's only change what's necessary for the command you want to modify (hoxhunt-incident-soc-feedback-send) to avoid from unwanted impacting on users.
@@ -577,7 +583,7 @@ def get_remote_data_command(client: Client, args: dict, params: dict): | |||
incident_id = parsed_args.remote_incident_id | |||
last_update = parsed_args.last_update | |||
last_update_parsed = dateparser.parse(last_update, settings={'TIMEZONE': 'UTC'}) | |||
last_update_utc = last_update_parsed.strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3] + 'Z' # type: ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's only change what's necessary for the command you want to modify (hoxhunt-incident-soc-feedback-send) to avoid from unwanted impacting on users.
@@ -502,7 +508,7 @@ def fetch_incidents( | |||
|
|||
max_fetch_parsed = min(int(max_fetch), 100) | |||
|
|||
timefrom = first_fetch_parsed.strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3] + 'Z' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's only change what's necessary for the command you want to modify (hoxhunt-incident-soc-feedback-send) to avoid from unwanted impacting on users.
@@ -742,7 +748,10 @@ def hoxhunt_send_incident_soc_feedback_command(client: Client, args: dict, param | |||
incident_id = args.get('incident_id') | |||
custom_message = args.get('custom_message') | |||
threat_feedback_reported_at_limit = args.get('threat_feedback_reported_at_limit') | |||
response = client.send_incident_soc_feedback(incident_id, custom_message, threat_feedback_reported_at_limit) | |||
threat_feedback_reported_at_limit_parsed = dateparser.parse(threat_feedback_reported_at_limit) # type: ignore | |||
date_limit = format_date_to_iso_string(threat_feedback_reported_at_limit_parsed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested your use case with the following code:
date_utc=dateparser.parse("2024-10-30T08:37:42.359Z") (as mentioned in the yml)
print(date_utc) >> 2024-10-30 08:37:42.359000+00:00
print(date_utc.isoformat(timespec='milliseconds')) >> 2024-10-30T08:37:42.359+00:00
print(date_utc.isoformat(timespec='milliseconds')+'Z') >> 2024-10-30T08:37:42.359+00:00Z
I don't think this is the wanted result, Please let me know if I'm wrong.
In addition when executing:
date_utc=dateparser.parse("7 days")
I get the result according to my timezone and you add "Z" to the output from "format_date_to_iso_string"
method meaning UTC so the the conversion is incorrect (What was also present before the change you made in the function format_date_to_iso_string in order to use the isoformat function).
Maybe let's figure out together what the use case and what we should do.
We can try and see if using the function arg_to_datetime can solve the problem for us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, it is not indeed the result we want. Seems like the unit tests didn't catch this, which I was relying in. I wonder if it would just be safest to use the custom formatting function that we already had in place, as in the original version of the pull request, as it's proven to work? Is there a specific reason we can't use that, which is proven at this point.
I did not go with the date_to_timestamp and timestamp_to_datestring functions because they lost milliseconds in the process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tomaskukk
I saw your original solution but as I wrote, when you are executing:
date_utc=dateparser.parse("7 days")
You get the time in the current time zone, for example my timezone is GMT+2 the time now is 2025-03-05 13:41:10.382902
When executing date_utc=dateparser.parse("7 days")
we get 2025-02-25 13:41:10.382902
Then print(date_utc.strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3] + 'Z')
as your original version you get >> 2025-02-25T13:41:10.382Z
mean the same time in UTC, I don't think this is the wanted result, Please let me know if I'm wrong.
date_7_days=dateparser.parse("7 Days") print(date_7_days) >>2025-02-25 13:41:10.382902 print(date_7_days.strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3] + 'Z') >> 2025-02-25T13:41:10.382Z
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @tomaskukk,
We have additional function from common server python named arg_to_datetime
Please check if this meets your need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that makes sense, I didn't realize in the beginning that the motivation of the comment was the timezone related issue 👍
I'll see and fix it (alongside the other comments)!
Contributing to Cortex XSOAR Content
Make sure to register your contribution by filling the contribution registration form
The Pull Request will be reviewed only after the contribution registration form is filled.
Status
Related Issues
fixes: No issue
Description
Added date parsing for the
threat_feedback_reported_at_limit
field which is used as an argument in a command. This allows users to pass the value in user-friendly formats.Must have