spatie / laravel-model-flags Goto Github PK

First of all sorry for opening an issue, but Discussions is not enabled 😅

Let's pretend we have defined a receivedMail flag for our User model (not the best real world example, I know).

User::find(1)->flag('receivedMail'); // true
User::find(2)->flag('receivedMail'); // true
User::find(3)->flag('receivedMail'); // false

...and so on.

How can I retrieve (for example) all Users along with their flag status, without running n+1 queries?
Example use case: an administration panel that lists users and shows their receivedMail status.

Thank you

hello, im cant install your package on laravel i was also got message about:

  Problem 1
    - Root composer.json requires spatie/laravel-model-flags ^1.1 -> satisfiable by spatie/laravel-model-flags[1.1.0].
    - spatie/laravel-model-flags 1.1.0 requires spatie/laravel-package-tools ^1.13.6 -> found spatie/laravel-package-tools[1.13.6] but the package is fixed to 1.12.1 (lock file version) by a partial update and that version does not
match. Make sure you list it as an argument for the update command.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require spatie/laravel-model-flags:*" to figure out if any version is installable, or "composer require spatie/laravel-model-flags:^2.1
" if you know which you need.

Is after deletion spatie/laravel-activitylog

Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires spatie/laravel-model-flags ^1.1 -> satisfiable by spatie/laravel-model-flags[1.1.0].
    - spatie/laravel-model-flags 1.1.0 requires illuminate/contracts ^9.0 -> found illuminate/contracts[v9.0.0-beta.1, ..., 9.x-dev] but these were not loaded, likely because it conflicts with another require.

You can also try re-running composer require with an explicit version constraint, e.g. "composer require spatie/laravel-model-flags:*" to figure out if any version is installable, or "composer require spatie/laravel-model-flags:^2.1
" if you know which you need.

The new package is great. Would you consider adding a properties field for additional context. This is a feature that is in your Activity Log package and proves to be quite useful. This would extend the use cases for this great new package.

Add to migration

$table->json('properties')->nullable();

Method to add data

$user->flag('receivedMail')->withProperties(['customProperty' => 'customValue']);

@freekmurze Fantastic work on this package; a really elegant package to a common requirement.

Any thoughts on implementing an autoflagging closure? My thinking is you'd often flag a record after doing something (or unflag in the reverse).

Taking the example from the readme.

User::notFlagged('wasSentPromotionMail')
    ->each(function(User $user) {
        Mail::to($user->email)->send(new PromotionMail())
        $user->flag('wasSentPromotionMail');
    });
});

could be implmented as

User::notFlagged('wasSentPromotionMail', function(User $user) {
   Mail::to($user->email)->send(new PromotionMail())
});

// or even
User::notFlagged('wasSentPromotionMail', fn (User $user) => Mail::to($user->email)->send(new PromotionMail()));

Notice how the $user->flag('wasSentPromotionMail'); is not specified; the autoflag solution could handle flaging if the closure didn't throw an exception (or a boolean return if we wanted to be more explicit

Obviously, the reverse could be true and a flagged query would then unflag the record after closure complete?

Thoughts? I'm happy to throw a PR up if you think it's worth it.

I'd like to suggest using SoftDeletes on the Flags model.

This means that when flags are deleted you still have the original record of when the flag was added.

For example, you can mark a model (eg: a User) as “receivedMail”, however without soft deletes, if you decide to remove this flag, you wouldn't know when it was added or removed.

Using soft deletes would act as a log of not only when a flag was applied, but when it was deleted, providing an event history of the flags, making debugging flags related issues much easier as you could see the events over time.