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

[frontend] fixed header colors (#8249) #8277

Merged
merged 1 commit into from
Oct 3, 2024

Conversation

stefan1anuby
Copy link
Contributor

@stefan1anuby stefan1anuby commented Sep 7, 2024

After fix:

image
image

Related issues

part of #8249

Checklist

  • I consider the submitted work as finished
  • I tested the code for its functionality
  • I wrote test cases for the relevant uses case (coverage and e2e)
  • I added/update the relevant documentation (either on github or on notion)
  • Where necessary I refactored code to improve the overall quality

Further comments

From what I can see, the problem is not limited to Light mode. Here are a few examples of drawers that have the same issue (though there are more):

  • Observations -> Observables -> Create
  • Observations -> Artifacts -> Create
  • Events -> Sightings -> Sighting -> Edit
  • Data -> Relationships -> Edit

Should I apply the same quick fix to each, or would it be better to refactor them to use the Drawer component? It looks like the 'correct' drawers use the Drawer component internally, but that would require a major refactor and take more time.

@Kedae Kedae added the community use to identify PR from community label Sep 7, 2024
@@ -49,7 +49,7 @@ const StixCyberObservableEditionContainer = (props) => {
>
<Close fontSize="small" color="primary" />
</IconButton>
<Typography variant="h6" classes={{ root: classes.title }}>
<Typography variant="subtitle2" classes={{ root: classes.title }}>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, your fix might work but I think there is a better way :

We do have an internal Drawer component that is using MaterialUI inside.
I think the correct fix is to handle the usages of StixCyberObservableEditionContainer by replacing the old Drawer by the new one. (For example you can look at ReportCreation.tsx to see how we use the new Drawer)

/>
</div>
</div>
<StixCyberObservableEditionOverview
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I add the custom Drawer here instead of in all three places?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well if you think this is relevant you can :)

Copy link

codecov bot commented Sep 10, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 66.22%. Comparing base (b29748b) to head (3416cac).
Report is 128 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #8277      +/-   ##
==========================================
- Coverage   66.23%   66.22%   -0.02%     
==========================================
  Files         597      597              
  Lines       60300    60436     +136     
  Branches     6196     6202       +6     
==========================================
+ Hits        39939    40023      +84     
- Misses      20361    20413      +52     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@Kedae
Copy link
Member

Kedae commented Oct 3, 2024

Ok, I have some bad news.

While testing it I found out I gave you wrong direction => the replacement is not straight-forward for StixCyberObs*
Can you go back to your first commit so I can merge your fix ?

Sorry about that.

You can still try to improve the Drawer in a second review but if you take a look at SCO Detail page or even some KnowledgeGraphs (Report for example) you will see that it's not displaying the way we want currently

@stefan1anuby
Copy link
Contributor Author

I recently reached the same conclusion during some unrelated testing. I could have done more testing earlier to catch the issue sooner, or at least addressed it right away when I discovered the problem.

@Kedae Kedae merged commit da277f9 into OpenCTI-Platform:master Oct 3, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community use to identify PR from community
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants