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

Comments data model #5

Open
mickmister opened this issue May 9, 2024 · 2 comments
Open

Comments data model #5

mickmister opened this issue May 9, 2024 · 2 comments

Comments

@mickmister
Copy link
Member

mickmister commented May 9, 2024

I'm thinking comments would have these columns:

entity_type: 'section',
entity_id: 'some section id',
project_id: 'some project id',
mm_post_id: 'some post id',

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 or mm_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. And channel.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.

@mickmister
Copy link
Member Author

mickmister commented May 9, 2024

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

@mickmister
Copy link
Member Author

Files should also have that entity relationship, so you can upload a file onto a section or a project

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Status: No status
Development

No branches or pull requests

1 participant