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

Fixed issue #172 #182

Merged
merged 30 commits into from
Sep 15, 2023
Merged

Fixed issue #172 #182

merged 30 commits into from
Sep 15, 2023

Conversation

ayusht2810
Copy link
Contributor

@ayusht2810 ayusht2810 commented Apr 21, 2023

Summary

  1. Added a feature to open the incident modal using the slash command and to create incidents using the slash command.
  2. Added a feature in the incident modal to subscribe to the newly created incident.
  3. Added a feature to open the incident modal from post menu actions and auto-fill the "Short description" and "Description" fields with the post data.

Screenshots

image
image

Ticket Link

Fixes #172

@codecov-commenter
Copy link

codecov-commenter commented Apr 21, 2023

Codecov Report

Patch coverage: 44.64% and project coverage change: +1.57% 🎉

Comparison is base (fefb220) 65.22% compared to head (bcfcd59) 66.79%.
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #182      +/-   ##
==========================================
+ Coverage   65.22%   66.79%   +1.57%     
==========================================
  Files          16       16              
  Lines        1990     2027      +37     
==========================================
+ Hits         1298     1354      +56     
+ Misses        653      633      -20     
- Partials       39       40       +1     
Files Changed Coverage Δ
server/plugin/client.go 76.11% <0.00%> (-1.55%) ⬇️
server/plugin/plugin.go 60.00% <0.00%> (-2.07%) ⬇️
server/plugin/command.go 76.88% <25.92%> (-4.02%) ⬇️
server/plugin/util.go 64.55% <50.00%> (+0.64%) ⬆️
server/plugin/api.go 75.76% <100.00%> (+6.75%) ⬆️

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

@trilopin trilopin self-requested a review May 8, 2023 18:59
@trilopin trilopin added the 2: Dev Review Requires review by a core committer label May 8, 2023
Copy link
Contributor

@trilopin trilopin left a comment

Choose a reason for hiding this comment

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

Thanks for your work @ayusht2810

here I write some minor things I noticed from a first review:

  1. distance between buttons/labels in modal seems too small

Screenshot 2023-05-09 at 12 33 49
Screenshot 2023-05-09 at 12 38 57
Screenshot 2023-05-09 at 12 39 20
Screenshot 2023-05-09 at 12 41 07
Screenshot 2023-05-09 at 12 41 10

  1. add comments modal has cta button enabled before adding context inside the textarea (update state is correct)

  2. Update-State modal raises in multiple devices at the same time, not only on the window that was triggered (it doesn't happen with the create incident modal)

server/constants/constants.go Outdated Show resolved Hide resolved
server/plugin/command.go Outdated Show resolved Hide resolved
@trilopin
Copy link
Contributor

trilopin commented May 9, 2023

Additionally I get It seems that you are not authorized to manage subscriptions in ServiceNow. Please follow the instructions for setting up user permissions available in the plugin's documentation. The instructions can also be viewed by running the "/servicenow help" command. message when I try to raise the modal with /servicenow create incident (it works fine for post dialog)

I could understand that I lack permissions for subscriptions, but should they apply to create-incident? if so, should it apply for create incident from post dialog too?

@ayusht2810
Copy link
Contributor Author

@trilopin regarding point
3. Update-State modal raises in multiple devices at the same time, not only on the window that was triggered (it doesn't happen with the create incident modal). We fixed this issue previously in a PR but this caused the issue of modals not opening through the Playbooks plugin. You can refer to these issues for more detailed discussion.
#120
#167

@ayusht2810 ayusht2810 self-assigned this May 10, 2023
@trilopin
Copy link
Contributor

@hanzei @mickmister

[MI-3071] Fix review fixes for issue 172 of importing incident featur…
@ayusht2810
Copy link
Contributor Author

@trilopin fixed the review fixes

Copy link
Member

@lieut-data lieut-data left a comment

Choose a reason for hiding this comment

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

Just a handful of comments, but nothing blocking.

server/plugin/api.go Outdated Show resolved Hide resolved
server/plugin/util.go Outdated Show resolved Hide resolved
@@ -270,9 +270,13 @@ func (c *client) GetMe(userEmail string) (*serializer.ServiceNowUser, int, error
}

func (c *client) CreateIncident(incident *serializer.IncidentPayload) (*serializer.IncidentResponse, int, error) {
queryParams := url.Values{
constants.SysQueryParamDisplayValue: {"true"},
Copy link
Member

Choose a reason for hiding this comment

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

Can you clarify what this does?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this query param helps in retrieving the display values instead of their IDs for the fields

Copy link
Member

@mickmister mickmister left a comment

Choose a reason for hiding this comment

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

Just a few non-blocking comments

onClick={handleClick}
>
<img
src={`${Utils.getBaseUrls().publicFilesUrl}${Constants.SERVICENOW_ICON_URL}`}
Copy link
Member

Choose a reason for hiding this comment

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

We'll want to make sure we take into account the server's Site URL when contacting the plugin via HTTP. At the moment we are just parsing the browser's URL:

const url = new URL(window.location.href);
const baseUrl = `${url.protocol}//${url.host}`;
const pluginUrl = `${baseUrl}/plugins/${pluginId}`;
const pluginApiBaseUrl = `${pluginUrl}/api/v1`;
const mattermostApiBaseUrl = `${baseUrl}/api/v4`;
const publicFilesUrl = `${pluginUrl}/public/`;

server/plugin/command.go Outdated Show resolved Hide resolved
webapp/src/containers/createIncident/index.tsx Outdated Show resolved Hide resolved
webapp/src/containers/createIncident/index.tsx Outdated Show resolved Hide resolved
@DHaussermann
Copy link

HI @ayusht2810
I have done a round of testing on this and it seems to be working. I still have some edge cases to explore and such.

I do have a coupe questions with the business logic on the "caller" field. From what I can tell...

  • When creating an incident not based on a post - the creator may assign any Service Now user as the caller.
  • When creating an incident based on a post of a user not connected to Service Now - the creator may assign any Service Now user as the caller.
  • When creating an incident based on a post of a user who is connected to Service Now - The author of the post must be assigned as the caller
    Is this ☝️ correct?

If so...

  1. Are we certain we want to enforce that the author of the post must be the caller if they are connected to Service Now? As it is, the short description can be edited from the post content and it may be the case that you want to create an incident based on another users post

  2. When using slash command to create (or creating based on a post from a user not connected to SN) any user can be the caller. The problem is that both the Mattermost username and the ServiceNow username are shown.
    image
    In this image - both users are the same person and called will be abel.tutor in SN regardless of which option I select. Can we add some kind of logic to hide Mattermost username if Service Now username is already included? I am worried this could cause alot of "duplication" and confusion.

  3. When caller is locked to the author of the post, can the field be read-only? Even though there is not affect on the SN side, it could be confusing that they can attempt to change this value
    image

…sers (#58)

* [MI-3182] Fix issue: ServiceNow icon not visible in app bar for new users

* [MI-3182] Self review fix

* [MI-3182] Review fix

Co-authored-by: Manoj Malik <manoj@brightscout.com>

---------

Co-authored-by: Manoj Malik <manoj@brightscout.com>
@raghavaggarwal2308
Copy link
Contributor

@DHaussermann The icon issue should be fixed now. Can you please confirm?

Copy link

@DHaussermann DHaussermann left a comment

Choose a reason for hiding this comment

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

Tested and passed
Icon and all other know issues are now resolved.

LGTM!

@DHaussermann
Copy link

@raghavaggarwal2308 Thanks for the effort on this. I have 2 related questions that do no block the PR.

  1. Do you know what's happening with the App Bar? This plugin shows in the app bar even when it does not seem enabled for other plugins (see below) I imagine this is intentional. Do you recall anything about this plugin always showing in the app bar?
    image

  2. Can you please clarify for me if this PR will now be cherry picked to a v2.x.x branch?

@raghavaggarwal2308
Copy link
Contributor

raghavaggarwal2308 commented Jun 22, 2023

@DHaussermann

  1. I cannot understand the issue you are getting here. I tried disabling the app bar and the plugin, but the icon was not visible in both cases. Can you please send us the steps to reproduce the issue?
  2. The issue Modify the Create Incident Message Action Dialog and back-port it to the 2.X stream #172 was to move the create incident dialog from v3.x.x to v2.x.x. So, once this PR is merged we will create a new v2.x.x release.

@DHaussermann
Copy link

  1. Yes I suppose you have answered my question as that is the issue.
    To clarify, when the app bar is disabled, the icon will not show in the channel header the way the other icons do. This must be by design and I simply don't recall. Can you find a technical reason why the icon does not show in the channel header? This was done intentionally correct?

  2. Thanks. I understand 👍

@DHaussermann
Copy link

@raghavaggarwal2308 sorry I missed the at mention for you ☝️

@raghavaggarwal2308
Copy link
Contributor

@DHaussermann The icon will be visible in the channel header when the app bar is disabled but the icon color will be changed. Please check the below screenshots. Let me know if you are unable to see the icon.
Screenshot from 2023-06-23 21-09-19
Screenshot from 2023-06-23 21-09-32

@DHaussermann
Copy link

@raghavaggarwal2308 Sorry. I was confused. For some unrelated reason the state of the app bar is not showing in my system console.

In my screen above I thought the icon was somehow forcing the app bar on because the other 2 plugins are in the header.
What's actually happening is app bar is enabled but the other two plugin on this server version are too old to move to the app bar.

Yes, SN plugin works as expected and moves to the channel header when needed.
Thanks for looking :)

I believe we can merge this now.

@DHaussermann DHaussermann added 4: Reviews Complete All reviewers have approved the pull request and removed 2: Dev Review Requires review by a core committer labels Jun 23, 2023
@DHaussermann
Copy link

DHaussermann commented Jun 29, 2023

@raghavaggarwal2308 please ping mw once we have this merged and packaged into a release for release testing.

Is there unresolved code review conversations still to sort out?

@raghavaggarwal2308
Copy link
Contributor

@mickmister Can you please merge this PR if nothing is pending?

Copy link
Member

@mickmister mickmister left a comment

Choose a reason for hiding this comment

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

I gave the PR another review. In general looks good 👍 Just a few comments for discussion

webapp/src/utils/index.tsx Outdated Show resolved Hide resolved
webapp/src/plugin_constants/index.ts Outdated Show resolved Hide resolved
server/plugin/util.go Outdated Show resolved Hide resolved
server/plugin/util.go Outdated Show resolved Hide resolved
server/plugin/api_test.go Outdated Show resolved Hide resolved
webapp/src/app.tsx Outdated Show resolved Hide resolved
…cident modal) (#59)

* [MI-3273] Rview fixes on ServiceNow PR mattermost#182 (Add create incident modal)

* [MI-3273] Review fix

* [MI-3273] Added logic to get the MM site URL from redux and pass it into getBaseUrl function

* [MI-3273] Fix ci

* [MI-3273] Review fix

* [MI-3273] Fix failing testcases

* [MI-3273] Review fixes
@raghavaggarwal2308
Copy link
Contributor

@mickmister FIxed the review comments mentioned by you

Copy link
Member

@mickmister mickmister left a comment

Choose a reason for hiding this comment

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

LGTM, just some thoughts for improvement

webapp/src/utils/index.tsx Outdated Show resolved Hide resolved
Comment on lines +1 to +2
// eslint-disable-next-line import/no-unresolved
import {BaseQueryApi} from '@reduxjs/toolkit/dist/query/baseQueryTypes';
Copy link
Member

Choose a reason for hiding this comment

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

Is this type still useful if the import can't be resolved?

Copy link
Contributor

Choose a reason for hiding this comment

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

@mickmister Yes, it's useful, we are using it as the type of parameter in handleBaseQuery function.

Copy link
Member

Choose a reason for hiding this comment

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

But if it can't be resolved, how does it work? Is it the case that your editor can resolve it, but for whatever reason resolver being used by eslint cannot find it?

Copy link
Contributor

Choose a reason for hiding this comment

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

@mickmister Yes, it is being resolved by the editor but not by eslint.

Copy link
Member

Choose a reason for hiding this comment

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

I wonder why that's the case. I would prefer we didn't have to do this, but it's pretty negligible in this case

webapp/src/index.tsx Outdated Show resolved Hide resolved
@raghavaggarwal2308
Copy link
Contributor

@mickmister Fixed the review comments mentioned by you

@mickmister
Copy link
Member

@raghavaggarwal2308 please ping mw once we have this merged and packaged into a release for release testing.

Merging due to @DHaussermann's approval above

@mickmister mickmister merged commit bd58e0b into mattermost:master Sep 15, 2023
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4: Reviews Complete All reviewers have approved the pull request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Modify the Create Incident Message Action Dialog and back-port it to the 2.X stream
7 participants