Open louisescher opened 1 month ago
The idea i had to make this work would be adding something along the lines of the following:
type StudioCMSDiffTracking = {
id: string; // UUID for this diff
userId: string;
pageId: string;
timestamp: Date; // Creates a default that will set the date automatically
pageMetaData: {}; // we can use this to store the pageData as well for being able to track changes in the top section?
pageContentStart: string; // this could be used to allow rollback potentially?
diff: string; // Optional in case the only change is to the metadata for the page and not the primary content
}
The StudioCMSDiffTracking
table would have a setup as such.
export const StudioCMSDiffTracking = defineTable({
columns: {
id: column.text({ primaryKey: true }),
userId: column.text({ references: () => StudioCMSUsers.columns.id }),
pageId: column.text({ references: () => StudioCMSPageData.columns.id }),
timestamp: column.date({ default: NOW, optional: true }),
pageMetaData: column.json(),
pageContentStart: column.text({ multiline: true }),
diff: column.text({ multiline: true, optional: true })
},
});
I feel this could be handled by either a select or number entry?
Number entry might be best, although a warning should be shown below the input that this takes up a lot of DB space.
this could be used to allow rollback potentially?
Could you elaborate? Not quite sure how this would work when multiple edits at multiple locations had been made
Number entry might be best, although a warning should be shown below the input that this takes up a lot of DB space.
COULD take up a lot of space depending on how large your project is (how many pages you have) In fact, even @astrojs/web-vitals
could trigger this issue, since they store a ton of data, IMO that data is helpful hence why i built optional support into our dashboard for it, now i'm glad i did simply due to the fact that web-vitals
rely's on Studio's Dashboard normally for viewing the stats, but with the sunset of Studio it was almost going to get left behind before i convinced the maintainers to keep it!
Could you elaborate? Not quite sure how this would work when multiple edits at multiple locations had been made
If we store both the original version, as well as the diff
between the original and the new version (new version would obviously been published and would be available on the main table anyway at this point) than in theory we could make it so that when that button is clicked, it can replace the Main table content with that of the stored data within the tracking table, using the pageContentStart
and pageMetaData
columns stored data
Is your feature request related to a problem? Please describe. Currently, there is no way for an administrator to tell what an editor has done to a text when edited. Since authors are a feature that is planned according to #187 it might be worth looking into giving administrators an option to see what editors changed on their last edit.
Describe the solution you'd like Similar to GitHub, a diff to see what changed in a post would be great to keep editors in check. See this demo of the diff package on NPM with the "Patch" option selected.
Describe alternatives you've considered Not implementing diffs.
Additional context Implementing your own diff algorithm (or at least implementing A diff algorithm) is a rather difficult undertaking. Just using the
diff
package would be easiest, or at least basing the solution on that package.