Skip to content
This repository has been archived by the owner on Mar 13, 2024. It is now read-only.

Hide bots and apps UI when managed by Apps Framework #7850

Merged
merged 9 commits into from
Apr 30, 2021
Merged

Conversation

larkox
Copy link
Contributor

@larkox larkox commented Apr 9, 2021

Summary

Hide bots and OAuth apps UI when managed by the apps framework.

When the apps framework plugin is disabled, they show as normal apps/bots.

Ticket Link

https://mattermost.atlassian.net/browse/MM-33158

Related Pull Requests

Proxy Plugin: mattermost/mattermost-plugin-apps#138

NONE

@larkox larkox added 2: Dev Review Requires review by a core commiter 3: QA Review Requires review by a QA tester labels Apr 9, 2021
@@ -195,6 +195,66 @@ function oauthApps(state: IDMappedObjects<OAuthApp> = {}, action: GenericAction)
}
}

function appsOAuthAppsIDs(state: string[] = [], action: GenericAction) {
Copy link
Contributor

@catalintomai catalintomai Apr 9, 2021

Choose a reason for hiding this comment

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

nit: curious why using OAuthAppsIDs (plural) vs BotIDs (singular), since both OAuth app and bot are apps-related artifacts - why not use either singular or plural for both. Is it because we could conceivably have multiple bots per app, but only one OAuth app?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are two main reasons for this:

  • Me not being native speaker, and doubting which of the two ways sounded better.
  • Me not going over the changes and ensure consistency.

That being said, I have no preference over singular or plural, so which one do you think is better? I will make sure it is consistent for the choice we decide.

Copy link
Contributor

Choose a reason for hiding this comment

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

0/5 on singular vs. plural (prob. singular makes more sense), I just advocate aligning on one vs. another for both.

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.

Functionality looks good 👍

I have just a few requests. For my comments related to adding more tests, I'd say to prioritize testing on components that have logic around the props, rather than testing a component that is just passing a prop to a child.

@@ -206,6 +210,7 @@ describe('components/integrations/bots/Bot', () => {
accessTokens={accessTokens}
team={team}
actions={actions}
fromApp={false}
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a test for a bot that has fromApp={true}?

@@ -120,6 +126,8 @@ describe('components/integrations/bots/Bots', () => {
owners={owners}
users={users}
actions={actions}
appsEnabled={false}
appsBotIDs={[]}
Copy link
Member

Choose a reason for hiding this comment

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

Same here, can we have some tests that have app bots involved?

@@ -169,6 +187,7 @@ export default class Bots extends React.PureComponent<Props, State> {
accessTokens={(this.props.accessTokens && this.props.accessTokens[bot.user_id]) || {}}
actions={this.props.actions}
team={this.props.team}
fromApp={this.props.appsBotIDs.includes(bot.user_id)}
Copy link
Member

Choose a reason for hiding this comment

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

Is there an async operation that could momentarily have fromApp={false} before the getAppBotIDs() response comes back?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If getAppBotIDs takes too long, the user will see the whole information, and then disappear when that information finally arrives. We could keep the loading state until we have all the information. What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

I think we should keep showing the loading animation. But if the bot id fetch fails, then show all of the information.

components/integrations/bots/index.ts Outdated Show resolved Hide resolved
@@ -36,6 +36,7 @@ describe('components/integrations/InstalledOAuthApp', () => {
onRegenerateSecret: jest.fn(),
onDelete: jest.fn(),
filter: '',
fromApp: false,
Copy link
Member

Choose a reason for hiding this comment

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

Does it make sense to have an apps-related test here?

components/integrations/installed_oauth_apps/index.ts Outdated Show resolved Hide resolved
export function getAppsOAuthAppsIDs(): ActionFunc {
return bindClientFunc({
clientFunc: Client4.getAppsOAuthAppsIDs,
onSuccess: [IntegrationTypes.RECEIVED_APPS_OAUTH_APP_IDS],
Copy link
Member

Choose a reason for hiding this comment

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

Do we need the arrays around the onSuccess values? It looks inconsistent throughout the file, but it caught me off guard at first glance here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No. It is not needed. Nevertheless, for consistency, I would prefer to keep it as a list.

Copy link
Member

Choose a reason for hiding this comment

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

The array is left over from when we always used to have a _SUCCESS action dispatched for every request in addition to something like a POST_RECEIVED action. I think it might still be used in some cases, but we could definitely consider adding a non-array form in the future.

Copy link
Member

@hmhealey hmhealey left a comment

Choose a reason for hiding this comment

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

One question, but I assume it's not going to result in any changes unless we want to add some heavy future proofing.

@@ -2548,6 +2548,20 @@ export default class Client4 {
);
};

getAppsOAuthAppIDs = () => {
Copy link
Member

Choose a reason for hiding this comment

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

Is there any chance either of these will ever need paging in the future? That's obviously a bigger question than just something that affects the web app, but I find it never hurts to ask

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Being small amount of information (a list of ids) I hope there is no case where this may become a problem (e.g. having 100 Apps installed?). That being said, I am open to suggestions or comments.

appsEnabled,
(state: GlobalState) => state.entities.integrations.appsOAuthAppIDs,
(apps, ids) => {
return apps ? ids : [];
Copy link
Member

Choose a reason for hiding this comment

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

👍

@DHaussermann
Copy link

DHaussermann commented Apr 14, 2021

@larkox there may be an issue here where the UI can revert to the old version. I'm still investigating. I think I turned off bot creation in the system console and re-enabled then the UI no longer appers changed. I'll try and pin this down.

For the time being... a question - is @appsbot new to this bersion of the proxy?
image
This should have a Mattermost logo and not Jira. If this bot is unrelated to the changes, I'll make a new issue.

@DHaussermann
Copy link

We can disregard the comment above. I cannot repro this issue. I took some time to investigate this and it seems as though the bots where left over data from before the corresponding proxy plugin build was deployed. Seem when you remove apps using debug commands, the corresponding bot is left behind which causes some confusion.

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

  • Backstage UI change to hide config are implemented successfully
  • Bots and oAuth have the option removed
  • No changes to conventional bots or oAth apps unrelated to MM Apps
  • No issues found on subsequent installations when using proper uninstall and reinstall commands
  • A couple unrelated issues were found. I will create follow up tasks.

LGTM!

@DHaussermann DHaussermann added QA Review Done Do Not Merge Should not be merged until this label is removed and removed 3: QA Review Requires review by a QA tester QA Review Done labels Apr 15, 2021
@DHaussermann
Copy link

DHaussermann commented Apr 15, 2021

@larkox I need to test additional cases. The Jira ticket you referenced may require a broader solution than removing the option. We may actually need the ownership to change. 0/5 The Apps plugin should own the bot.

This UI clean-up does not guard against the owner being deactivated. Further more - as pointed out by @mickmister, it causes an additional issue if the sysadmin who owns the bot becomes deactivated (the stock config deactivates the bots owned by this user), as the bot can then no longer be re-enabled.

@DHaussermann DHaussermann added the 3: QA Review Requires review by a QA tester label Apr 15, 2021
@larkox
Copy link
Contributor Author

larkox commented Apr 16, 2021

@DHaussermann For the bots, it might be possible to add something like owned by the plugin (actually, we could create these bots with the plugin RPC methods). The potential problem I see is for OAuth Apps, which with the current APIs we would not be able to do something like that.

@hanzei hanzei added this to the v5.35.0 milestone Apr 22, 2021
@amyblais
Copy link
Member

/check-cla

@amyblais amyblais added the AutoMerge used by Mattermod to merge PR automatically label Apr 29, 2021
@mattermod
Copy link
Contributor

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

@hanzei hanzei assigned hanzei and unassigned larkox Apr 29, 2021
@hanzei hanzei added Do Not Merge Should not be merged until this label is removed and removed Do Not Merge Should not be merged until this label is removed AutoMerge used by Mattermod to merge PR automatically labels Apr 29, 2021
@cpanato cpanato merged commit 7430755 into master Apr 30, 2021
@cpanato cpanato deleted the HideAppsBotsUI branch April 30, 2021 10:38
hanzei pushed a commit that referenced this pull request Apr 30, 2021
* Hide bots and apps UI when managed by Apps Framework

* Make OAuthAppsIDs into OAuthAppIDs

* don't hide bot account management controls
@hanzei hanzei added CherryPick/Done Successfully cherry-picked to the quality or patch release tracked in the milestone and removed CherryPick/Approved Meant for the quality or patch release tracked in the milestone labels Apr 30, 2021
@hanzei hanzei removed their assignment Apr 30, 2021
@amyblais
Copy link
Member

@hanzei Can you also help cherry-pick this to cloud?

@amyblais
Copy link
Member

/cherry-pick cloud

@mattermod
Copy link
Contributor

Cherry pick is scheduled.

mattermost-build pushed a commit to mattermost-build/mattermost-webapp that referenced this pull request Apr 30, 2021
* Hide bots and apps UI when managed by Apps Framework

* Make OAuthAppsIDs into OAuthAppIDs

* don't hide bot account management controls

(cherry picked from commit 7430755)
@amyblais amyblais added Changelog/Not Needed Does not require a changelog entry Docs/Not Needed Does not require documentation labels Apr 30, 2021
mattermod pushed a commit that referenced this pull request Apr 30, 2021
@hanzei hanzei unassigned larkox and hanzei Apr 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
4: Reviews Complete All reviewers have approved the pull request Changelog/Not Needed Does not require a changelog entry CherryPick/Done Successfully cherry-picked to the quality or patch release tracked in the milestone Docs/Not Needed Does not require documentation release-note-none
Projects
None yet
10 participants