Needs work
Project:
Permissions by Term
Version:
3.1.36
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Feb 2025 at 14:51 UTC
Updated:
14 Apr 2025 at 05:25 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
pemson18Comment #3
pemson18Comment #4
bohemier commentedIt would be great to have the option in the module configuration to disable the widget, similar to the "Show term selection in the user form" setting.
Comment #5
pemson18Comment #6
pemson18Comment #7
pemson18Refactor Patch add schema and install definition and description fixes
Comment #9
jepster_Thanks for your patch. I have reviewed it.
1. permissions_by_term_form_node_form_alter: Here you stopping the function via your return statement at the top of the function. That way you are removing all other functionality. E.g. the form access controlling.
2. In the `SettingsForm.php` the default value for the "hide_terms_permissions_info_in_node_form" setting is true. But actually the value is not set, if the setting has not been saved manually, yet.
Comment #11
jepster_I've added the changes to the new patch version release 3.1.36: https://www.drupal.org/project/permissions_by_term/releases/3.1.36
Please test the updates and reopen this issue and create a comment, if you stumble upon any issue with this update.
Comment #12
bohemier commentedThanks for the great work Peter and Pemson, this works beautifully.
Comment #13
pemson18Comment #14
pemson18I stumbled upon the setting not working if the condition is set in the permissions_by_term setting form. added #13 patch for the same. Requesting Peter for reviewing the same...
Comment #15
pemson18Comment #16
pemson18Comment #17
jepster_You cannot just add a return statement here. It breaks the entire function. Also how any error can be reproduced here? I have tested this.
Comment #18
jepster_I do not experience any issue here. If I switch the setting on or off via the settings form, I do see the expected behavior. The functionality works like designed.
See attached screenshots for clarification.
If you do experience an issue here:
* Please provide step-by-step instructions for the ability to reproduce this issue on a plain Drupal site with PbT installed.
* If you do have code changes: please create a issue fork with a merge request. That way code changes can be easily discussed via in-code comments.
Comment #19
jepster_Comment #20
pemson18Hello Peter, should the permission supersede the settings. Since for the admin user the permission is enabled by default and the setting "hide the terms info on node edit page" doesn't come into effect.
Comment #21
jepster_Hi pemson18, sorry - I do not follow. The config is global. This means that the config controls the form for all users. I think that's the intended behavior. Please provide more context, if you mean anything else.
Comment #22
pemson18Hello Peter,
I have enabled the " Hide terms permissions information in the node form" setting in module settings. Also the permission by default has the been enabled for the admin user, The widget is displayed differently in the node edit form. It should have overridden the permission "Enables the specific role to see the term permissions on the node edit page" for the admin user and not display the users info in the edit form as in the screenshot showing allowed user info. Hope I am able to convey this issue properly.
Comment #23
pemson18For Admin users the user information is loaded by default which sometimes breaks the site due to records having info 20k+ users. The show "Term permission information on node edit page" under permissions settings overrides the config "Hide terms permissions information in the node form." for admin users which in turn breaks the page load on Users info 20k+ records
Comment #24
jepster_Okay, thanks for your input. I do understand, that there is a mismatch between the config and permission setting. Then there should be a permission and config check in the merge request. This should be combined in one if-case. Feel free to provide a merge request and link it here. I can review it.
Comment #25
jepster_Merge request review is easier than patch review. Just hit the "create issue fork" button at the top of this page.