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

Store logs in a custom database tables #143

Open
benoitchantre opened this issue May 15, 2023 · 3 comments
Open

Store logs in a custom database tables #143

benoitchantre opened this issue May 15, 2023 · 3 comments
Labels
enhancement New feature or request vote Want this feature? Give the issue a thumbs-up

Comments

@benoitchantre
Copy link
Contributor

Describe your desired feature

The usage of custom database tables could provide better privacy. It would be easier to avoid the migration of personal data from production to staging/local environnements when sent emails are logged.

@benoitchantre benoitchantre added the enhancement New feature or request label May 15, 2023
@soup-bowl
Copy link
Owner

Since the current method is working fine, I'll leave this to a community vote whether this should be implemented or not. I'm not against this, but this was in the original version of the plugin and removed due to incompatibility with database adjustment plugins and Project Nami at the time, and yo-yo'ing between storage methods is not something I want to take lightly.

@soup-bowl soup-bowl added the vote Want this feature? Give the issue a thumbs-up label May 17, 2023
@benoitchantre
Copy link
Contributor Author

What kind of errors were reported? Many plugins add one or multiple database tables.

@soup-bowl
Copy link
Owner

soup-bowl commented Jan 9, 2024

Unfortunately I did not make any helpful notes about it years back (#2). I believe it was related to the fact custom queries had issues with the SQL runner in Project Nami at the time, back when this had a tie in to a project that utilised it.

Perhaps it's not an issue anymore, but since the current implementation is working, I haven't seen a compelling reason to undo this, along with the compatibility adjustments it would need to amend existing installations.

If you wish to make a fork re-using this orignal code, this commit is a good reference point of the original code. My comment on the issue indicates it worked fine, so it might not take a lot to make it compatible again (might need modernisation - was last mainstream 3 years back).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request vote Want this feature? Give the issue a thumbs-up
Projects
None yet
Development

No branches or pull requests

2 participants