-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Hide bots and apps UI when managed by Apps Framework #7850
Conversation
@@ -195,6 +195,66 @@ function oauthApps(state: IDMappedObjects<OAuthApp> = {}, action: GenericAction) | |||
} | |||
} | |||
|
|||
function appsOAuthAppsIDs(state: string[] = [], action: GenericAction) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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} |
There was a problem hiding this comment.
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={[]} |
There was a problem hiding this comment.
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)} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@@ -36,6 +36,7 @@ describe('components/integrations/InstalledOAuthApp', () => { | |||
onRegenerateSecret: jest.fn(), | |||
onDelete: jest.fn(), | |||
filter: '', | |||
fromApp: false, |
There was a problem hiding this comment.
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/installed_oauth_apps.test.tsx
Outdated
Show resolved
Hide resolved
export function getAppsOAuthAppsIDs(): ActionFunc { | ||
return bindClientFunc({ | ||
clientFunc: Client4.getAppsOAuthAppsIDs, | ||
onSuccess: [IntegrationTypes.RECEIVED_APPS_OAUTH_APP_IDS], |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
packages/mattermost-redux/src/reducers/entities/integrations.ts
Outdated
Show resolved
Hide resolved
packages/mattermost-redux/src/reducers/entities/integrations.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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 = () => { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 : []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
|
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. |
There was a problem hiding this 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!
@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 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. |
/check-cla |
Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour. |
* Hide bots and apps UI when managed by Apps Framework * Make OAuthAppsIDs into OAuthAppIDs * don't hide bot account management controls
@hanzei Can you also help cherry-pick this to |
/cherry-pick cloud |
Cherry pick is scheduled. |
* 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)
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