Provide Person-centric Group management; includes subnavigation refactoring (CFM-291) #367
Conversation
arlen
force-pushed
the
feature-cfm291-personGroupMemberships
branch
from
b2c6239 to
80ca5d9
Compare
| public function beforeRender(EventInterface $event) { | ||
| $link = $this->getPrimaryLink(true); | ||
|
|
||
| if(!empty($link->value)) { | ||
| $this->set('vv_bc_parent_obj', $this->FileProvisioners->ProvisioningTargets->get($link->value)); | ||
| $this->set('vv_bc_parent_displayfield', $this->FileProvisioners->ProvisioningTargets->getDisplayField()); | ||
| $this->set('vv_bc_parent_primarykey', $this->FileProvisioners->ProvisioningTargets->getPrimaryKey()); | ||
| } | ||
|
|
||
| return parent::beforeRender($event); | ||
| } |
There was a problem hiding this comment.
We seem to be adding a bunch of copy/paste boilerplate to plugins for logic that should instead be dynamically calculated in a parent controller (ie: StandardPluginController) or possibly a Trait. It looks like we're trying to render the breadcrumbs like
ProvisioningTargets > FileProvisioners
but for the most part we can determine our parent object via getPrimaryLink and then automatically inflect that and inject the appropriate breadcrumb without needing to hardcode this in every plugin controller. (There may be a small number of exceptions that need to be hand crafted, but those should be the exception, not the rule.)
There was a problem hiding this comment.
Indeed, there actually already seems to be similar logic in StandardPluginController::beforeRender (and StandardEnrollerController), so why are we not using/updating that?
This PR provides Group management from the Person view:
This PR also refactors subnavigation handling so that all subnavigation tabs are now configured at the view level in fields.inc or columns.inc.