Closed (fixed)
Project:
Scheduler
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
22 Jul 2016 at 17:33 UTC
Updated:
7 Aug 2016 at 09:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jonathan1055 commentedfixed title
Comment #3
jonathan1055 commentedThis seems to run OK on my local testing.
Comment #5
jonathan1055 commentedCan't see any problems with this. Happy to update if anyone notices something in future.
Committed.
Comment #6
mr.baileysSorry, was just reviewing your patch but cross-posted :(
Just minor things:
Actually, I think @current_user can be dropped here, since it is not used in the ScheduledListAccess constructor?
Typo. I couldn't find a reference in the documentation guidelines, but it seems the consensus is the have the first doc-line of a constructor be in the form "Constructs a ... [object]."
Comment #7
jonathan1055 commentedThanks for reviewing. I am relatively new to OO and symphony framework, so very much appreciate any help I can get.
It is not used in the constructor, but the access() function uses $account
public function access(AccountInterface $account) {So do we only need to specify parameters that are needed for the constructor? Does the system somehow know that
AccountInterface $accountis the current user?. It runs fine without that parameter so it must be OK.Comment #8
mr.baileysThe $account-parameter for the access()-function is passed in by its caller (in this case AccessManager, which has the current user injected into its constructor).
Correct, and in this case the current user was passed as 2nd parameter to the constructor, which just ignored it. You can also use setter injection by using 'calls' instead of injecting via arguments to the constructor, for example:
Comment #10
jonathan1055 commentedThanks for the explanation, that makes sence. I was confused because the original patch in #2755665-4: Restore original access requirement for scheduled content overview. had the @current_user parameter, but it seems this was not required back then, because we did not have a constructor method in that patch. Yes, just checked if the order of constuctor parameters is switched it fails badly.
Committed and fixed. Thanks