Closed (fixed)
Project:
Inmail
Version:
8.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
23 Jun 2016 at 10:21 UTC
Updated:
5 Aug 2016 at 11:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
miro_dietikerYeah, this is important and i'd say critical to contextual processing.
I was hoping to find a patch here... :-)
Comment #3
arla commentedSounds like an appropriate way to handle certain things.
Note that account switching can have unwanted effects. For example, with Feeds, we had a problem with automatically setting a text field because anonymous did not have access to the necessary filter format.
Could this be applicable also by the current bounce analyzers? They now do BounceAnalyzerResult::setRecipient (where "recipient" means "recipient of the prior message", thus = sender of the current message). Or is that scope separate from how account switching is intended to be used? Do we have example use cases?
Comment #4
mbovan commentedThanks for the feedback.
Agree this could be a problem... For this case, we could assert user has access to the specific format before assuming the filter format access is granted.
I think it can apply for bounce analyzers too. The idea would be that each analyzer can update the "identified user" = sender (or recipient in bounce messages language).
I'm attaching the first patch. At this point, I think we are overlapping with #2754253: Lack of standard result in collaboration of analyzers.
In case we introduce a standardized analyzer result, do you think identified user should be set on
InmailAnalyzerResultorProcessorResult? The problem can occur if some analyzers use their own result object (e.g. BounceAnalyzerResult) and still want to set the global (Inmail) user. On the other side, I am not sure we want to allow plugins (analyzers) to make changes onProcessorResult?Comment #6
miro_dietikerIMHO the code should be clear in that being anonymous is the default behaviour. We only want to switch away if the target user is non-anonymous. Similarly, switching back is optional only.
Agree that committing this as is, is useless as it doesn't do anything. At the same time we need the result with a user context.
The only way to generalise it on this level is by introducing an account switcher result interface and checking for that.
And indeed, the bounce doesn't need to implement that.
Comment #7
miro_dietikerFunctional code will follow once the standard result is in.
Comment #8
miro_dietikerComment #9
arla commentedComment #10
mbovan commentedUpdated the patch according to the latest changes and #6.
Added tests as well.
Since we have
$accounton default result and as a "current user" too, I guess it would be preferable to use\Drupal::curentUser()rather than$default_result->getAccount()on handler's level?Comment #11
arla commentedSome suggestions, but nothing serious. I'm fine with committing as is.
This could be a place to use
$default_result->isUserAuthenticated(). We wouldn't have to use $anonymous_user then.Vaguely related: DefaultResult could lazily call getAnonymousUser() in getAccount(), then MessageProcessor doesn't have to setAccount().
This test doesn't really test any handler. It's just handler-related. Maybe consider moving the method to ProcessorTest?
Comment #12
miro_dietikerIt's very important that we guarantee that if we switch the account, we call switch back.
This should not call twice an API. (Handlers could accidentally alter values...)
Instead, we should determine a local variable for it in MessageProcessor.php and check it.
Comment #13
mbovan commentedRe #11.1: Replaced with
$default_result->isUserAuthenticated().Re #11.2: I missed ProcessorTest at first. Moved it there.
Re #12: Added a local
$has_account_changedvariable.Comment #15
mbovan commentedFixed
AnalyzerTest.Comment #16
miro_dietikerVery nice. :-)