Maybe im missing it.. but isnt this about just the same as simply reporting from your VoterInterface::vote method? Whatever the report strategy is..

In other words.. what's the difference between doing it in initialize vs. vote? The data is the same-ish, the calling order is the same... 😕

vote is already all about decision making, just not sure this can/should be captured with a standard...

@ro0NL Same as constraint validation in the form component, I wanted to give more verbosity on voters. For example as, a voter can support one or several objects and attributes, it can choose a decision without knowing the exact reason on your side.

class MyVoter extends Voter
{
    // ...

   protected function voteOnAttribute($attribute, $subject, TokenInterface $token)
   {
        $user = $token->getUser();

        if ($user->isBad()) {
            return false;
        }

        if ($user->getAge() < 12) {
           return false;
        }

        return true;
   }
}

Here, for example, the voter can say no on an action with the current user but you can't tell that the user was a bad person or too young.

After for initialize, I know it's a bit a pollution and it's only for internal usage, that's why I tried to separate it from the VoterInterface but this method is in any case to be in decision making.

I understand the usecase, im not sure a) if belongs to core and b) we really need 2 methods on this.

From my POV vote is about decision-making, and where context diverges in many, many (i've seen some voters :)), many contexts. It's where the true magic happens.

Given

if ($user->isBad()) {
    return false;
}

if ($user->getAge() < 12) {
   return false;
}

return true;

These are 3 contexts already, not sure you propose the if/else structure in initialize as well? But to me this is about at simple as adding a $logger->info() something above each return in vote. And im not sure that should be standardized :)

Besides, i would do plain english i guess. Not translated; i think it's rather technical info (basically logs).

Using many voters will give better context by default.

But then again; im not sure why you exactly want to separate this in 2 methods.

I'm very happy to get a context of why it's not allowed. Imagine a list of options, but some are not allowed. As a person seeing those options, I want to know why they are not allowed. Currently I have to write a custom implementation on top of the voters (or next to it) to determine why, duplicating the domain logic.

Ok that makes sense :) Still the calling order of both is the same.. meaning we dont really "initialize" all voters beforehand, not giving context beforehand.

What about a special VoteResult...

//SomeVote::vote
return $yes ? self::GRANTED : new VoteResult(self::DENIED, 'report');

Quite like for a VoteResult, I will do some changes soon for a try

Basically it would allow to follow all authorization checks for a given request, and collect them for the profiler. Meaning we can follow each decision in detail, additionally with custom user messages.

@maxperrimond @iltar wdyt?

@ro0NL I like the idea of a vote report, but not the way it's implemented there. I don't like multiple return types, even if it enhances DX.

What about a second "introspectable" base Voter? It could be very similar to the original voter but has a different way to report:

public function reportVoteOnAttribute(string $attribute, $subject, TokenInterface $token): VoteReport;

We could always go with vote() : VoteResult of course :) (additional interface).

Im just not sure if duplicating logic to provide detailed reports is convenient? You end up creating a common method providing the result + report..

edit: i understand if the purpose is to report about context or so? And not so much about the actual vote result.

The "old" implementation could be nothing more than being decorated with a vote result without a message (for example)

Exactly.

I made a new version of it with VoterResult as you mention, let me know what do you think of this version.
Cheerz

@maxperrimond Any chance for this PR to be finished?

Hmm... I like the idea... but it's a lot of code in core to accomplish this. I'm moving to the 4.1 milestone. But, unless we find a simpler implementation (after all, this is effectively "fancy logging"), I'm 👎. So, I hope you can prove me wrong with something simpler :)

Based on @weaverryan's last comment, I'm closing this PR as the code won't be merged anyway.