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

Feature Request: Optional diff option #293

Open
Tracked by #333
louisescher opened this issue Sep 18, 2024 · 3 comments
Open
Tracked by #333

Feature Request: Optional diff option #293

louisescher opened this issue Sep 18, 2024 · 3 comments

Comments

@louisescher
Copy link
Member

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
Copy link
Member

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
}
  1. 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
  2. Create the dashboard pages to facilitate these checks and edits and restrict to admin level (or above).
  3. 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
Copy link
Member Author

louisescher commented Sep 19, 2024

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
Copy link
Member

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

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

No branches or pull requests

2 participants