astrolicious / studiocms

A dedicated CMS for Astro DB. Built from the ground up by the Astro community.
https://studiocms.xyz
MIT License
245 stars 19 forks source link

Feature Request: Optional diff option #293

Open louisescher opened 1 month ago

louisescher commented 1 month ago

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.

Adammatthiesen commented 1 month ago

The idea i had to make this work would be adding something along the lines of the following:

  1. An option in the settings to enable/disable the diff tracking system
  2. How far back should this system track? 5? 10? 20? 15? 30? I feel this could be handled by either a select or number entry?
  3. Add a table schema with the following type:
    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
    }
  4. Add a check whenever someone adds a new edit that checks the current length of matching content being checked to ensure that the oldest gets deleted when it should so that the DB does not overflow
  5. Create the dashboard pages to facilitate these checks and edits and restrict to admin level (or above).
  6. Integrate with the current API endpoints with a toggle

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 })
    },
});
louisescher commented 1 month ago

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

Adammatthiesen commented 1 month ago

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