METRON-2179: Make navigation in both UIs consistent #1460
Conversation
| it('deleteSensorEnrichments', () => { | ||
| sensorIndexingConfigService.deleteSensorIndexingConfig('squid').subscribe( | ||
| result => { | ||
| expect(result.status).toEqual(200); |
There was a problem hiding this comment.
I noticed this test because of a failing Type Error. However, because we are mocking the backend and injecting the response, this test is just checking what we are injecting and is unnecessary. As a result, I removed it.
| sensorEnrichmentConfigService | ||
| .deleteSensorEnrichments('bro') | ||
| .subscribe(result => { | ||
| expect(result.status).toEqual(200); |
There was a problem hiding this comment.
I noticed this test because of a failing Type Error. However, because we are mocking the backend and injecting the response, this test is just checking what we are injecting and is unnecessary. As a result, I removed it.
| component.riskLevelRule = {name: 'rule1', rule: 'initial rule', score: '1', comment: ''}; | ||
| component.ngOnInit(); | ||
| component.onSave(); | ||
| fixture.detectChanges(); |
There was a problem hiding this comment.
I'm not sure how this passed before, but this set of tests would fail after updating to Angular 7 because the riskLevelRule property's value was updated without calling change detection. Because we are directly and synchronously updating the component property's value in the test, we have to explicitly call change detection so the Angular testing environment knows of the value update.
🤣 |
Can you elaborate on this? Is there a discuss thread or user list around this, or did this come from offline communications? I personally like this change, but I'm concerned that I don't recall having seen any discussion in the community around making the UI's have a common nav backbone. Again, I think this change is a good idea and it's pretty easy to justify imo. |
This should be performed in a separate PR in advance of this work. We pretty universally split any and all upgrade tasks from features that depend on that work. |
@mmiklavc There was a discussion thread in the dev email list that I sent out back in March. The feedback from @JonZeolla in that thread and offline discussions I had with @simonellistonball seem to indicate that there are use cases out there to switch between both UIs. I also brought this up in the user list. You and @justinleet proposed a good idea in having an endpoint that helps determine what links to expose based on user/group roles. However, I didn't see any user feedback indicating a desire to implement the nav this way. Is this endpoint possible to implement currently, or is there more work to be done on the backend around user/group roles first?
I thought this might be the case. I intentionally committed my upgrade work separately from my implementation work here, so I can easily split these out into two separate PRs. |
Perfect, thanks for linking that back to the PR here - I do recall that now. I just gave the Angular upgrade a +1 and will take another look at this one as well. Thanks @sardell! |
|
@mmiklavc Thanks for reviewing the Angular upgrade PR so fast. Rather than force pushing to update this PR, I think I'm going to close this and open a new PR containing only the Central Navigation work once I merge the Angular update into master. I think things will be a little cleaner that way. I'll be sure to reference this discussion in the new PR so folks aren't confused. Is this okay with you? |
Works for me |
|
A new PR containing only the central navigation work can be found here: #1464 |
2 participants
Contributor Comments
READ FIRST: This Pull Request seems very large, but a majority of the line changes are in the auto-generated package-lock.json file. There are maybe a one or two hundred lines of code changes outside of that auto-generated file. Now, breathe a sigh of relief. 😄
Link to original JIRA ticket here: https://issues.apache.org/jira/browse/METRON-2179
Currently, both UIs approach navigation in two different ways. This makes the interfaces seem inconsistent and can be confusing for new users. Both ways are also not collapsible. We also cannot navigate between both UIs (this was intentional in the original implementation, but feedback from users over time seems to indicate separating the personas is not necessarily beneficial).
This is how the navigations currently look on master:
In this PR, I added a collapsible sidebar navigation and removed the previous implemented navigations.
In order to do this, I utilized the Angular-version of Ant Design's component library. I did this because bootstrap does not contain a collapsible side navigation like this, and Ant Design allowed me to quickly implement this feature.
I also had to upgrade our version of Angular to the latest stable 7 release. Upgrading from 6 to 7 did not introduce any breaking changes.
Testing
Open either the Alerts or Management UI. A navigation should exist on the left-hand side of the screen (see above screenshots), and you should be able to minimize it by clicking on the arrow at the bottom of the menu. Besides navigating within the app, you should be able to navigate between both UIs.
Pull Request Checklist
Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:
For all changes:
For code changes:
Have you included steps to reproduce the behavior or problem that is being changed or addressed?
Have you included steps or a guide to how the change may be verified and tested manually?
Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
Have you written or updated unit tests and or integration tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?
For documentation related changes:
N/A
Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes viasite-book/target/site/index.html:N/A
Have you ensured that any documentation diagrams have been updated, along with their source files, using draw.io? See Metron Development Guidelines for instructions.Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.