jamtools / section-view

Section view component for the Jam Tools Composition App
1 stars 0 forks source link

Comments data model #5

Open mickmister opened 1 month ago

mickmister commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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