search

RickDBCN / filament-email

Log emails in your Filament project
https://filament-email-demo.marcogermani.it/
MIT License
77 stars 23 forks source link

[Bug]: Column not found: 1054 Unknown column 'team_id' in 'where clause' #57

Closed hyphen81 closed 4 months ago

hyphen81 commented 4 months ago

What happened?

Going to the view page, I expect to see a list of emails.

How to reproduce the bug

Config is the stock config, I added this to my Filament panel which doesn't have tenancy. I have other panels that do have tenancy, but the email logging is not in place for those.

Package Version

1.3

PHP Version

8.3

Laravel Version

10.48.10

Which operating systems does with happen with?

Linux

Notes

Getting this error when attempting to view the emails: Column not found: 1054 Unknown column 'team_id' in 'where clause'.

This is the query that's failing: SELECT count(*) AS aggregate FROMfilament_email_logWHEREteam_idIS NULL.

There is not a team_id field on the filament_email_log table.

This was previously working, until today.

https://flareapp.io/share/dmkDvqDP

hyphen81 commented 4 months ago

Just updated to v1.4 and still getting the same error.

hyphen81 commented 4 months ago

Just saw the release notes. I believe in semantic versioning a change like this would necessitate incrementing the major release number, since this is a breaking change. I would expect a minor release to be backward compatible.

marcogermani87 commented 4 months ago

Hi @hyphen81, how mentioned into new release details you need to publish the new migrations and run artisan migrate:

image

hyphen81 commented 4 months ago

After publishing the migrations, everything is working as expected.

iAmKevinMcKee commented 4 months ago

I would strongly recommend reverting back to 1.3.1 and making this release 2.0.

This is a breaking change for any app (including my own). As the other poster mentioned, semantic versioning says you should never have a breaking change in a minor release.

I have fixed my own app, but others who are using this package are going to have either test failures or prod issues if they don't have tests.

marcogermani87 commented 4 months ago

I would strongly recommend reverting back to 1.3.1 and making this release 2.0.

This is a breaking change for any app (including my own). As the other poster mentioned, semantic versioning says you should never have a breaking change in a minor release.

I have fixed my own app, but others who are using this package are going to have either test failures or prod issues if they don't have tests.

Hi @RickDBCN, what do you think? In the next release with PR #58 we can remove v1.3.0, v1.3.1, v1.4.0 and bump to v2.0.0?