Problem/Motivation

My use-case:
An anonymous user can create a membership node. That form has many details that our client uses to determine if they want to approve od decline the membership.
Once the membership is approved the original author can then edit their own membership node but without all the registration details.

I want to control the displayed form by creating multiple form modes and then access the mode based on the role of the user trying to edit the node.

I know this can be achieved with field permission hooks but since drupal already offers the ability to create multiple form modes i just wanted to find a simple way to access them. Different form modes also allow you to have easy control over field groups and field widgets, if you want them differently per form mode.

Here is how we have been using it for a couple of weeks now without problems.

If you got to /admin/structure/display-modes/form and create an additional form mode for content you can then use this hook to access that form mode.

for example:

function MODULE_entity_form_mode_alter(&$form_mode, $entity) {
  $entity_type = $entity->getEntityTypeId();
  if ($entity_type === 'node' && $entity->getType() === 'membership') {
    $user = \Drupal::currentUser()->getAccount();
    if ($user->isAuthenticated()) {
      $form_mode = 'member'; // This is where we set the newly generated form mode.
    }
  }
  // Show the user form for admin in the form mode of 'staff_only'.
  elseif ($entity_type === 'user') {
    $user = \Drupal::currentUser()->getAccount();
    if (_is_user_an_admin($user)) { // Custom function that checks if user has admin roles.
      $form_mode = 'staff_only';
    }
  }
}

Proposed resolution

Write a hook that allows you to create custom conditions to alter the form mode before the form is loaded.

Remaining tasks

  1. Discuss if this is a good way to go

API changes

A new hook is added.

Comments

MaskOta created an issue. See original summary.

MaskOta’s picture

StatusFileSize
new698 bytes

My stab at it.

primsi’s picture

Status: Active » Needs review
primsi’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

Can you update the issue summary with a use case for this?

joachim’s picture

I'm also confused about the use case.

Though https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!EntityForm... doesn't seem to let you pick a form view mode.

MaskOta’s picture

Issue summary: View changes

I have added our use-case to the summary.

tim.plunkett’s picture

IIRC the $operation is also assumed to be the view mode.

\Drupal\Core\Entity\ContentEntityForm::init() calls
$form_display = EntityFormDisplay::collectRenderDisplay($this->entity, $this->getOperation());
\Drupal\Core\Entity\Entity\EntityFormDisplay::collectRenderDisplay() is defined as
public static function collectRenderDisplay(FieldableEntityInterface $entity, $form_mode) {

joachim’s picture

Yeah, it does seem that way.

But isn't that a little weird? What happens if I create a form view mode called 'delete'?

But anyway, if that's the case, can the form view mode maybe be changed by altering the route?

tim.plunkett’s picture

StatusFileSize
new4.1 KB

You can change the operation via a route alter, but that would also change which form is loaded. Less than ideal.

If we could break BC by changing EntityFormInterface, I would do this (see patch).
Then again, I highly doubt anyone is implementing EntityFormInterface without extending EntityForm, given the setter injection approach (see the weirdly specific methods on there like setStringTranslation, setModuleHandler, setEntityManager, and setEntityTypeManager).

MaskOta’s picture

Issue summary: View changes

Let me try to be a little more clear in what i am trying to do. (updated summary)

An anonymous user can create a membership node. That form has many details that our client uses to determine if they want to approve od decline the membership.
Once the membership is approved the original author can then edit their own membership node but without all the registration details.
I wanted to control that by creating multiple form modes and then access the mode based on the role of the user trying to edit the node.

I know this can be achieved with field permission hooks but since drupal already offers the ability to create multiple form modes i just wanted to find a simple way to access them. Different form modes also allow you to have easy control over field groups and field widgets, if you want them differently per form mode.

Does this make more sense? If i understand the patch by tim.plunkett, that allows you to access a form mode via a different URL?

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

woprrr’s picture

You can use all form-modes you needed with help of FormModeManager module. That permit you to use form-modes on each entities compatible with this and have out of the box an ui to use it totally intagrated with core UI.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

Also not super clear here but since it's been 10 years and a feature request without any movement or follow up is it really a desired feature for core?