On every Entity Bundle deletion form, I notice a Revision Manager fieldset. Is that really necessary?
Could you please explain the background on why it was added there?

I understand that having it during Bundle creation makes sense, since the revision retention policy can be managed at that stage.
However, do we also need the same fieldset on Bundle deletion?

Kindly clarify.

Issue fork revision_manager-3568690

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

raajkumar.kuru created an issue. See original summary.

j-barnes’s picture

j-barnes commented
Assigned: Unassigned » j-barnes

@raajkumar.kuru - Hey, thanks for reporting this - you're absolutely right.

There's no reason to show revision manager settings on a deletion form. The bundle's about to be deleted anyway, so those settings are completely irrelevant at that point and just adds noise.

Should be a straightforward fix - we just need to check the form operation and bail early for things like delete, cancel, reset. Similar to how rabbit_hole handles it.

j-barnes opened merge request !12

j-barnes’s picture

j-barnes commented
Status: Active » Needs review
raajkumar.kuru’s picture

raajkumar.kuru
Location Chennai
commented

Thanks, Can you merge

  • j-barnes committed bb2a3e72 on 1.0.x 
    Issue #3568690: Excluded revision settings on bundle deletion form.
j-barnes’s picture

j-barnes commented
Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

sunny-lee’s picture

sunny-lee commented
Status: Fixed » Reviewed & tested by the community

Looks all good here, tested with removing a pre-existing content type (no more revision manager dropdown and settings showing) and successfully deleted. Created a new one and tried removal again and message is not showing.

j-barnes’s picture

j-barnes commented
Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

raajkumar.kuru’s picture

raajkumar.kuru
Location Chennai
commented

On Menu listing page its appearing.
Better we can remove all entity places

raajkumar.kuru’s picture

raajkumar.kuru
Location Chennai
commented
Status: Fixed » Needs work
j-barnes’s picture

j-barnes commented
Priority: Major » Normal

@raajkumar.kuru - thanks for following up.

Just want to make sure I understand what you're seeing. The fieldset showing on menu edit forms (like /admin/structure/menu/manage/main) is expected since menus act as bundles for menu_link_content, letting you set per-menu revision policies. But if it's appearing somewhere else or in a way that seems off, I'd like to take a look.

If you don't need revision management for menu links, disabling menu_link_content on the settings page should hide the fieldset entirely.

What were you expecting to see there instead?

raajkumar.kuru’s picture

raajkumar.kuru
Location Chennai
commented

Can we move the Revision Manger on top on menu entity. Currently its at the bottom after menu items

j-barnes’s picture

j-barnes commented
Status: Needs work » Fixed

Thanks for the follow-up. The main issue here has been resolved and verified, so I'm going to close this one out.

The fieldset lands at the bottom of the form which is standard Drupal behavior for settings added via form alter. Other contrib modules like Simple XML Sitemap, Metatag, Pathauto, etc. all end up in the same spot. If you'd like to see it handled differently, feel free to open a separate feature request.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.