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

Use SiteURL for all calls from the webapp #43

Open
mickmister opened this issue Jul 21, 2020 · 15 comments
Open

Use SiteURL for all calls from the webapp #43

mickmister opened this issue Jul 21, 2020 · 15 comments
Labels
Difficulty/1:Easy Easy ticket Good First Issue Suitable for first-time contributors Hacktoberfest Help Wanted Community help wanted Tech/ReactJS Type/Enhancement New feature or improvement of existing feature Up For Grabs Ready for help from the community. Removed when someone volunteers

Comments

@mickmister
Copy link
Contributor

If the server's SiteURL is configured with a subpath, the webapp's API calls do not work. The task here is to make this plugin's client to prefix its URLs with the SiteURL.

Here's an example of how the SiteURL may be computed:
https://github.com/mattermost/mattermost-plugin-jira/blob/19a9c2442817132b4eee5c77e259b80a40188a6a/webapp/src/selectors/index.js#L13-L26

@mickmister mickmister added Help Wanted Community help wanted Up For Grabs Ready for help from the community. Removed when someone volunteers Tech/ReactJS Good First Issue Suitable for first-time contributors Difficulty/1:Easy Easy ticket Type/Enhancement New feature or improvement of existing feature labels Jul 21, 2020
@duke7able
Copy link

@mickmister can you simply state for beginners what domain to be replaced with what domain as this looks like domain string replacement issue, thanks

@mickmister
Copy link
Contributor Author

@duke7able By default, the domain is blank in the request. For instance, an example might be:

fetch('/api/users');

But we want

const siteURL = getSiteURL(state);
fetch(siteURL + '/api/users');

There is no hardcoded domain to put here because each server is self-hosted, and thus will have a different domain. The main reason why this is needed is for deployments that host their server on a subpath. The site URL would be something like https://company.com/mattermost and so https://company.com/mattermost/api/users would be the resulting URL for example.

Have I made the task more clear?

@sudiptog81
Copy link

I can work on it if a PR for this does not already exist.

@larkox larkox removed the Up For Grabs Ready for help from the community. Removed when someone volunteers label Oct 22, 2020
@larkox
Copy link
Contributor

larkox commented Oct 22, 2020

Thanks @sudiptog81 ! All yours 😄

@jasonblais jasonblais added the Up For Grabs Ready for help from the community. Removed when someone volunteers label Jan 17, 2021
@jasonblais
Copy link
Contributor

Opening back up for grabs. You can find a PR that started work on this ticket at #58

@coltoneshaw
Copy link
Contributor

coltoneshaw commented Jul 15, 2021

@jasonblais / @DHaussermann - Looking into this one a bit it looks like it's related to the version of Mattermost Reduce in the package. The version that is included right now (5.26) does not accept the searchTeams parameter of (term, options), but it seems in later versions this is changed - mattermost/mattermost-redux#1200.

I updated the version locally and tested and it seems to be working fine. Do we know if there is an overall impact in bumping the version up?

@jasonblais
Copy link
Contributor

Thanks! Not sure, will defer to @mickmister and @DHaussermann who may know more.

@mickmister
Copy link
Contributor Author

@coltoneshaw Is this the ticket you meant to comment on? Where does the searchTeams action come into play with this ticket?

@coltoneshaw
Copy link
Contributor

Sorry, the original solution - #58 that is above appears to be a functioning solution to this issue. However, the issue isn't with that PR but with the version of mattermost-redux contained in the plugin. The link https://github.com/mattermost/mattermost-plugin-custom-attributes/blob/2800ede9ab3d5be1eaefb0b6701369c2d1a88737/webapp/src/components/admin_settings/teams_input/index.js#L12 does not accept the parameters that are passed to it based on the version of redux is what I'm seeing.

So, my curiosity is what impact would increasing the redux package version have on this plugin? I have a functioning version of this with the fix for this issue on an updated redux package.

@mickmister
Copy link
Contributor Author

Okay I understand the searchTeams issue now. The redux function had changed its arguments, and this plugin's code assumed the new changes, but is still importing the old version of the function. It's possible updating the redux package would have similar side effects with other functions that are in the opposite situation of expecting the old version of functions. I can take a look at all the imports if you'd like or I can do that during PR review if you are submitting a PR.

Should/does the searchTeams issue have its own ticket? I'm still curious how the discussion ended up on this one

@mickmister
Copy link
Contributor Author

@coltoneshaw Sorry I forgot to add the your mention above ^

@coltoneshaw
Copy link
Contributor

It looks like the discussion ended up here because when @DHaussermann was testing a fix for this issue it was throwing an error on the searchTeam but not searchUsers. Probably my fault for moving the conversation here, happy to open a new issue. Interestingly enough it looks like it may have been introduced here - #50 when swapping to a versioned release.

If you download the plugin from the repo in its unpublished state now you'll also see the searchTeams error.

@mickmister
Copy link
Contributor Author

@coltoneshaw Okay now I think I actually understand 😅 There was an issue discussed in the PR and you tracked down the root cause of that issue 🎉

Yes I think this should have its own issue for tracking. Updating the mm-redux repo should do the trick as you have noted and confirmed works

If you download the plugin from the repo in its unpublished state now you'll also see the searchTeams error.

Thank you for pointing this out 👍

@coltoneshaw
Copy link
Contributor

@mickmister - Sorry for that! I originally thought it was just a fix for that PR but the more I tested the more it just seemed outdated on redux.

I put in a PR / issue for it - #68

I do think the original code for this specific issue can be resubmitted as it does work with subpaths. Not sure what you think the best process for that is.

@mickmister
Copy link
Contributor Author

I do think the original code for this specific issue can be resubmitted as it does work with subpaths. Not sure what you think the best process for that is.

@coltoneshaw It seems fine to have both issues solved in one PR, since one of the fixes is just a dependency update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Difficulty/1:Easy Easy ticket Good First Issue Suitable for first-time contributors Hacktoberfest Help Wanted Community help wanted Tech/ReactJS Type/Enhancement New feature or improvement of existing feature Up For Grabs Ready for help from the community. Removed when someone volunteers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants