-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments data model #5
Comments
Start developing with mattermost in local storage. Make it so there is a synchronize functionality between the two systems. Really it would be a node.js server at that point though. There would be a plug-in on the mattermost side that simply sends plug-in hook information through a webhook to other systems. This would decouple it from the matter music plug-in. There will also be a jam tools that are most plugin. That will live inside of the jam tools repository. The matter music repository will remain what it is for now, maybe it will be replaced. Write playwright tests for both systems to make sure that the sink works correctly. Since it's all in the same repository, the mattermost plug-in and jam tools logic, it can always be tested together with the same code. You can run a get pod workspace with all this stuff too Local storage version uses a web socket connected to matter most to receive new posts, instead of the web hook driven thing. You could really just use an outgoing web hook to get those posts, but you also want to know when channel members change I think |
Files should also have that entity relationship, so you can upload a file onto a section or a project |
I'm thinking comments would have these columns:
Then a comment can be put onto any entity that exists in a project. Like a file or a section. Or the project itself.
Any entity that can be commented on should have a
mm_thread_id
ormm_root_post_id
probably, since every entity is a thread. A thread is not created until a comment is made. Unless it's a file upload, because that should always have a root_post_id.This assumes every comment will be tied to a project in some way. This can be used for access control. Since a project belongs to a MM channel, this basically is a proxied pointer to the channel id. Projects would obviously have a
channel_id
field. Andchannel.props
could contain project id pointers.post.props
can contain a music sniper comment id.music sniper server should keep a cache of channel memberships, so it doesn't constantly ask MM who has access to what. And receive webhooks from Mattermost plugin when a user joins or leaves a channel. Debounce and batch them when they're done in quick succession.
The text was updated successfully, but these errors were encountered: