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
Plugin API: GetChannels method #12418
Comments
i'd like to take look at this |
Thanks @dnguy078 👍 |
@hanzei could i get some 👀 on this. Wanted to see if i was heading in the right direction with this ticket. had some questions around the channels_store.go test; i left them in the PR. |
Can I take this |
Awesome, thanks @nadalfederer 👍 |
I would like to work on this. |
That's great @kadir96. Please let me know if you have any questions. |
@hanzei Should the struct in the issue description be implemented as-is or it is an example? Also, I see that previous PRs added |
@kadir96 Good suggestion with
|
@hanzei I was thinking changing the signature to |
@kadir96 Bloating the signature is a good point. But I like keeping |
@hanzei after your last comment, I began implementing and I started to think having The callers (1 2 3) need to get all channels matching to be functional and to do so they will need to supply some weird Should we introduce a new method instead of updating |
ping @hanzei. I would love to hear your thoughts on my last comment. |
I think that |
@kadir96 admittedly I'm don't know too much about the same schema of store method. @streamer45 Do you have thoughts on the above proposal? |
I think the suggestion is reasonable. We can rename the current As far as the page/perPage dilemma we usually include those fields in the options structure: |
While I see the argument for consistency it's more important to me to be clear on the arguments. I'm 3/5 |
I saw some comments regarding whether including page/perPage in the options on one of previous pr for this issue. Maybe it helps to decide. |
I think #12649 (comment) is the final point. |
So, I will rename Is it ok? |
I think there's a slight confusion here. I am discussing the store method, which is internal and not part of any user exposed API and I think it's fine for that to accept a single options parameter since technically all fields would be optional from the store point of view.
As a side note, unless strictly necessary, I would avoid passing a pointer to the options structure but use value semantics instead. |
I think the approach you shared is way better and I would go with it. I can implement like this right away but I could not find similar approach, would not this approach require any proposal or something like that so it can be reviewed, discussed and decided to have it or not? It seems a big move to me (Its just my 2 cents of course :)) |
Well that's what we are doing in a sense. This is a public issue after all :) The biggest change we are making is renaming a store method. Everything else is adding some behaviour which is currently missing. As long as we keep existing functionality unaltered I think we are good. But you are right, let's keep it simple so you can focus on the issue at hand. We can always revisit the store parts in a separate PR. I think we can go ahead with the store method renaming and passing this GetChannels(page, perPage int, options model.GetChannelsOptions) ([]*model.Channel, *model.AppError) |
Introduce a
GetChannels
method to the base plugin API. This should serve as the basis for all bulk queries of channels.We may later build plugin helpers upon this RPC method to streamline certain kinds of queries, e.g. get all public channels for a single user, or get all direct messages for a single user.
If you're interested please comment here and come join our "Contributors" community channel on our daily build server, where you can discuss questions with community members and the Mattermost core team. For technical advice or questions, please join our "Developers" community channel.
New contributors please see our Developer's Guide.
JIRA: https://mattermost.atlassian.net/browse/MM-18566
The text was updated successfully, but these errors were encountered: