feat: Apply default tag on recipe import (by URL)

[boc-the-git]

What type of PR is this?

• feature

What this PR does / why we need it:

The intent here is to allow for an "inbox" type of tag, that would get populated on every URL import and allows a user to review recipes that they haven't reviewed/checked for accuracy.
It might be that someone wants to go in and rename foods. Someone else might want to confirm nutrition looks right, etc..
Many reasons someone might want to confirm the end result of the parsing is exactly what they'd want.

This is just an enabler to make that easier to do - the tag gets added to all recipes imported by URL, bulk or single. It does not get added to other import types (e.g. zip, migration) as it's assumed those are already coming in in a clean state.

By default it's disabled, and requires the user to take action to enable it (in group settings).

Which issue(s) this PR fixes:

None.

Testing

Manual for the most part. Have added unit tests as well.

[boc-the-git]

Few minor issues to work through, will sort in the coming days and raise a new PR. Closing the PR might've been a bit dramatic, the effort to resolve type errors wasn't that great - though I really do need to be in bed!

[boc-the-git]

I guess SQLite doesn't enforce the foreign key constraints in tests, but Postgres does. Will resolve hopefully tomorrow. Review/comments are welcome in the meantime should anyone wish - I'm expecting the subsequent changes will be local to the unit test only.
Solution is to actually create a tag, not just generate a uuid.

[boc-the-git]

Have set this back to draft because I need to actually test the recent changes. Expecting it to go smoothly, but it won't get done today.

[boc-the-git]

Tested and ready for review again :)

[hay-kot]

We have this old issue/task

• [v1.0.0b] [Task] - Recipe Scraper Rules/Automations #1106

That I think has some cross concerns here. This implementation is very specific, and I'm wondering if there is a better way to generalize the implementation to be more flexible. Otherwise if #1106 ever gets implemented most of this work would likely have to be redone/removed.

Having a db structure for Import Automations might be a good step? We could store something like this

class ImportAutomation:
    rules: RegexAutomation | AlwaysAutomation | TagAutomation # json column maybe? 
    type: str
    groupd_id: UUID 
    order: int

Then we could have multiple rules that could apply in series on every import.

[github-actions]

This PR is stale because it has been open 45 days with no activity.

[boc-the-git]

FWIW, I agree with the prior comment and it is my intention to at some point make this more generalised.. I have no timeline for when though.

[github-actions]

This PR is stale because it has been open 45 days with no activity.