Skip to content
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

"Start" and "Stop" Times not Saved When Creating Relationships #1079

Closed
securitiz opened this issue Feb 15, 2021 · 0 comments
Closed

"Start" and "Stop" Times not Saved When Creating Relationships #1079

securitiz opened this issue Feb 15, 2021 · 0 comments
Labels
bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR)
Milestone

Comments

@securitiz
Copy link

Description

When creating a relationship between two objects, analysts have an opportunity to set a Start and Stop date, characterising the relationship temporally. However, after setting the dates and creating the relationship, the dates don't appear to be saved.
This is confirmed by selecting the relationship in the Knowledge graph - the Start date is set to 12/31/1969, and there is no Stop time.

Environment

  1. OS (where OpenCTI server runs): Ubuntu 24
  2. OpenCTI version: OpenCTI 4.2.1
  3. OpenCTI client: frontend
  4. Other environment details:

Reproducible Steps

Steps to create the smallest reproducible scenario:

  1. Go to a Knowledge graph in a report,
  2. Create a Relationship between two objects, set a Start (1/1/2020) and Stop (2/2/2020) time. Save the relationship
  3. Select the relationship itself in the Knowledge graph (e.g. "uses")
  4. Click the edit button to edit the relationship

Expected Output

The Start date is the date originally set (1/1/2020). The Stop date is consistent with the date previously set (2/2/2020)

Actual Output

The Start date resets to 12/31/1969. The Stop date is blank.

Additional information

Changing the Start and Stop dates back to the originally specified dates appears to work, and doesn't reset.

@SamuelHassine SamuelHassine added bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR) labels Feb 15, 2021
@SamuelHassine SamuelHassine added this to the Release 4.2.2 milestone Feb 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR)
Projects
None yet
Development

No branches or pull requests

2 participants