🇩🇪Germany @Peter Majmesku

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.

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.

peter majmesku → created an issue.

If I do install group_content_menu_bundles with the issue fork, which is just requiring menu_item_extras in version 3.1.0, then I do get that error:

drush en group_content_menu_bundles -y
The following module(s) will be installed: group_content_menu_bundles, menu_item_extras

// Do you want to continue?: yes.

In SqlContentEntityStorageSchema.php line 1843:

The SQL storage cannot change the schema for an existing field (bundle in menu_link_content entity) with data.

Failed to run drush en group_content_menu_bundles -y: exit status 1

Do you know any solution for this already?

peter majmesku → created an issue.

I've encountered this issue, as I liked to install a groups config via recipe, before the group module was installed. Installing the group module upfront helped.

Simple IP login is now compatible with Drupal 11.

Nice! 💪🎉🥳

Thanks again for testing. I feel that we are close. :)

I've resolved your notices. The return type declarations are reverted to the previous state, where they are not causing errors. Please test again.

I found a solution regarding to custom exposed filters and the pager counter, which might help you.

There is this Pager-ID field in the views pager settings. After trying a couple things, I've tried to set a different numeric ID there, too. Afterwards this pager and other pagers worked correctly. The description of this field also already suggests, that it can help, if there are "problems". So there might be some side effects, which can be worked around by this field setting. Maybe this information helps others also.

Lost a couple of hours with this not quite intuitive pager behavior in views...

@harlor: Thanks for your hints and the suggested changes. 👍 I've tested the module manually on a local Drupal playground site and there were no errors. The tests are all green. Please review.

@harlor: I resolved all your notices. Please review.

Makes sense. 👍 We should ditch everything, which could be API breaking, after creating the first stable release.

@harlor: I have answered on your notices. Could you please review again?

Ah, I've seen your notices for the merge request. Let me check them.

The static code analysis is also tests. It's tests without explicit written tests. That way the Drupal coding standards are proven. You are loosing nothing here. I would like to ask you kindly about merging.

After I installed the validator dependency from the following issue, I could see the progress in my database table: https://www.drupal.org/project/opigno_scorm/issues/3281986 🐛 opis/json-schema dependency missing Needs review

I cannot reproduce that. Installed a fresh Drupal site and I do not see this error:

➜  drupal-10-pbt d drush en permissions_by_term -y
>  [notice] Message: The content access permissions have been rebuilt.
>
 [success] Module permissions_by_term has been installed. (Help - Permissions - Configure)
➜  drupal-10-pbt d drush cr
 [success] Cache rebuild complete.
➜  drupal-10-pbt d launch
➜  drupal-10-pbt d composer show | grep drupal/core
drupal/core                              10.4.1  Drupal is an open source content management platform powering millions of websi...
drupal/core-composer-scaffold            10.4.1  A flexible Composer project scaffold builder.
drupal/core-project-message              10.4.1  Adds a message after Composer installation.
drupal/core-recommended                  10.4.1  Core and its dependencies with known-compatible minor versions. Require this pr...
➜  drupal-10-pbt   

You might check your individual Drupal website. Maybe this error is tight to individual implementations. If you are able to break down the error, then you could a provide a step-by-step instruction to reproduce the error in a basic Drupal 10 site. There is no error visible after a ordinary module installation.

I do also confirm that the changes from the MR do work for my project.

You must be careful, that you really install the ^2.3 version and not just the latest version. Because the latest version of opis/json-schema cannot be auto-loaded via composer.

peter majmesku → created an issue.

Added tests in the related issue: https://www.drupal.org/project/form_decorator/issues/3499316 📌 Add test for example module Active

I am considering this issue here as a duplicate now.

peter majmesku → created an issue.

I am done with my changes. Please review. I made the following changes:

* Fixed Drupal coding standards and Drupal practices
* Implemented static code analysis via PHPStan and PHPCS
* Added testing via PHPUnit. The test proves if a new form field is attached via form_decorator_example with the API that form_decorator provides
* Spellchecker via cspell

peter majmesku → created an issue.

@hydra: Merged in the current 1.x branch and made the pipelines pass. Please review.

Thanks for your explanation!

I read your list for reproduction. If there is just a term related with the node, but no permissions for the term are set, then there is no permission restriction.

Hi crutch, it looks like your database server reached limits. Yes, PbT needs some resources on the database site. Even we do have already optimized here really a lot. From your report I do not see, how PbT could be optimized more, to help you out.

It might be a good approach to check the database server resources and configs there.

max_statement_time setting in your my.cnf could be a place to optimize your database server settings. E.g.:

[mysqld]
max_statement_time = 300 # 5 minutes

However, database server optimization is not in the scope of the PbT module. That is a different topic.

peter majmesku → created an issue.

I've implemented the GitLab CI pipeline configuration. It handles the static code analysis via PHP_CodeSniffer and PHPStan. This required some code and documentation changes to comply with the standards. All pipelines now pass. The code validation jobs are allowed to fail; this is the default behavior. I recommend always making sure that the jobs succeed. This essentially eliminates all syntax, spelling, and coding standard violations. Please review.

Great! Thanks for the new minor release. 🥳🎉

> We won't fix the phpcs issues in this branch anymore. A new version is coming with a new UI and fixed coding styles :)

I would like to see code style issues handled via pipeline. There are not many violations which need manual coding, so this could be resolved relatively quick. Drafted a MR for this in #3496183 (Static code analysis) → . So you could merge the pipeline config into your branch with the UI, if you like. However, I am pausing work on this issue for now. Just let me know, when it's reasonable to continue with this.

Do you like the current code changes, regarding the select form widget? Would be nice, if we could close this issue.

Thanks for your feedback! I did the requested changes. Your mentioned docblock comments and newline stuffs etc. is fixed. I also replied to your questions.

The phpcs stuff could be handled in https://www.drupal.org/project/slots/issues/3496183 ✨ Static code analysis Active so it could be just pointed by the CI pipeline. I run PHPCS against the module and there are already lots of other violations against the Drupal coding standard. Most of them could be fixed automatically. So I executed phpcbf to fix them, too.

The comments I wrote manually. However, I am not a friend of this docblock comments. I am more for good variable names, readable and also validated code. Doc comments can easily get legacy and misleading over time.

peter majmesku → created an issue.

Hi hydra! I've done the refactoring, based on your feedback. There's also a merge request now. Please check.

Thx again for the exchange. 👍 I've introduced the key-value store. The SlotsService::buildSlot() didn't brought up all slots, which are rendered on one particular page. Therefor the Slots module is now collecting the slot ids via SlotBlock::build() method. Please review the changes.

You need to enter the slot_id as a condition value

Thanks for the hint! 👍 I've improved the code within the issue fork and now it works. You can select the slot block via its readable block id:

After saving the block content, the content will appear in the slot:

See the related code changes here: https://git.drupalcode.org/issue/slots-3495680/-/commit/440778a95942f877...

I mailed you my contact data :)

I have not received anything, yet. Checked the contact function on d.o for my correct e-mail address and took a look into my spambox. I'll email you my e-mail address.

See my issue fork changes. Please review and give feedback.

I modified the form element type from machine name to select and provided the slot configs as options. At least the selection part in the custom block content does work now:

After I do save the block content, the placeholder text for the slot still appears:

Maybe anyone of the maintainers can check, why the block display via the selected slot does not work?

peter majmesku → created an issue.

> If you'd like to contribute, let's get in touch!

Sure, I've sent you a PM via your user profile.

I've tested slots and they look really promising. In my previous project, we anticipated blocks that were intended to be filled in the future.

However, I strongly advocate for improving the form display widgets for the slot selector in the custom block type. Typing a unique ID into a text field every time feels somewhat "hackish" and isn't intuitive enough for content editors, in my opinion. It would be great if the site builder could choose either a select or autocomplete widget here for custom blocks.

Thanks for sharing this information. I am really not able to reproduce your issue. I've also installed link_attributes and the exlink modules. Then I added a linkfield to my node. I was able to edit the node, without any exception.

Maybe you can solve your issue by checking the PHP version. Please make sure, that you are using a supported PHP version. I recommend using the latest stable PHP version: 8.3. The oldest supported PHP version is 8.1.

I have seen, that you are working with XAMPP on Windows. I really recommend using DDEV: https://ddev.com/. On Windows you can use DDEV via WSL2. This works pretty well.

This issue is outdated. Please use the latest version (3.1.35). https://www.drupal.org/project/permissions_by_term/releases/3.1.35 →

I cannot reproduce this. The error comes from Drupal core and not the PbT module. It could help, if you could check if there is more debug information in your log.

* Do you have any link or url specific contrib modules installed?
* important: Which field types does this node have? Is there the link field type?
* Does this error come up on other node types?
* Is this node protected by PbT via term relation?

Yes, the dependencies are resolved via cache flush (e.g. "drush cr"). I re-checked this by signing in into a newly installed Drupal 11 site with PbT installed. It worked. The error can't be reproduced. Therefor I am closing this issue.

Do you see the error on a specific page? I have tested the module. Please provide details.

Hi f2boot, I followed your description and tried to reproduce your issue.

However, it works on my end.

* I activate the "Require all terms granted" setting
* I do relate a media entity with terms
* I do set permissions for that terms
* I do access the file, which is related to my media, directly
* I try the access as guest user and admin user
* I do experience the expected result

Please notice, that files must be stored in the private filesystem to get secured. Also you must write your own hook_file_download() implementation.

E.g:

/**
 * Implements hook_file_download().
 */
function fancy_module_media_document_file_download(string $uri) {
  $files = \Drupal::entityTypeManager()
    ->getStorage('file')
    ->loadByProperties(['uri' => $uri]);

  foreach ($files as $file) {
    $multipleMedia = \Drupal::entityTypeManager()
      ->getStorage('media')
      ->loadByProperties(['field_media_file.target_id' => $file->id()]);

    $oneMedia = reset($multipleMedia);

    if ($oneMedia instanceof \Drupal\media\MediaInterface) {
      /** @var \Drupal\permissions_by_entity\AccessChecker $accessChecker */
      $accessChecker = \Drupal::service('permissions_by_entity.access_checker');
      $isAllowed = $accessChecker->isAccessAllowed($oneMedia);

      if (!$isAllowed) {
        throw new \Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException();
      }
    }
  }

}

You can find more detailed description about securing documents in your filesystem by PbT in the documentation: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Updated example for hook_file_download().

Unfortunately I am not able to reproduce it.

* Installed a new D11 site with PbE installed.
* Set "Require all terms granted" setting
* Referenced two terms to this media: admin role only, editor role only
* Referenced the media to a node
* Afterwards I was able to view the node and the related media as admin user

Does this error also occur with version 3.1.35? Please check.

Please do me a favor and test the latest patch release. Feel free to re-open this issue, if you stumble upon any Drupal 11 related issues.

Created release 3.1.35 → which is now supporting Drupal 11.

@somersoft, mark_fullmer, erutan, bradallenfisher:

I’ve made several changes, and the module is now installable on Drupal 11. I conducted a few tests, and everything worked as expected. However, I’m not finished yet. Could you please do some testing and provide feedback in the meantime?

peter majmesku → made their first commit to this issue’s fork.

peter majmesku → created an issue.

peter majmesku → created an issue.

MeToo 👍🏻

Your patch is wrong. It removed the id parameter. But the function name is called "iSubmitAFormById". Without the form ID parameter, the function would be broken.

Thanks for noticing this. I now have a project where we are using this module again, so I improved it a bit.

See new release: https://www.drupal.org/project/client_config_care/releases/2.0.0 →

Thanks for noticing this. I now have a project where we are using this module again, so I improved it a bit.

See new release: https://www.drupal.org/project/client_config_care/releases/2.0.0 →

Closed due to new release: https://www.drupal.org/project/client_config_care/releases/2.0.0 →

Has anyone experienced anything similar?

Peter Majmesku → created an issue.

Joachim Namyslo → credited Peter Majmesku → .

sanduhrs → credited Peter Majmesku → .

Thanks for the MR. Created an new patch release with it (3.1.23): https://www.drupal.org/project/permissions_by_term/releases/3.1.23 →

@jastraat This module is currently unmaintained. If you like to continue the maintenance, then please let me know.

Peter Majmesku → created an issue.

@fathima.asmat Would you please take a look on this?

@fathima.asmat: I have bumped your permissions. You are now able to create releases. Thanks for your support!

Hi Fathima,

thank you for your interest. :) I gave you also the following project permissions for now:
* Write to VCS
* Maintain issues

The current top prio issue is the following: https://www.drupal.org/project/permissions_by_term/issues/3289053 📌 Automated Drupal 10 compatibility fixes for Permissions by Term Fixed

Please be so kind and review the latest patch and help in creating a Drupal 10 version of Permissions by Term. Is this okay for you?

Thanks again and kind regards
Peter

@_KASH_: That looks weird. If a patch can be applied via Git, it should be applicable by Composer without any extra config. Which error do you get without this Composer extra-config? And why this extra-config is necessary?

Great, sudesh.solaskar. Could anybody with an ongoing project please test the recent D10 patch?

@sudesh.solaskar: Thanks. Do you think that the D10 upgrade patch is ready or do you see issues?

Super sudesh.solaskar, I gave you the following permissions:
* Write to VCS
* Maintain issues

Please be so kind and work on the following issue, since this is the most important one: https://www.drupal.org/project/permissions_by_term/issues/3289053 📌 Automated Drupal 10 compatibility fixes for Permissions by Term Fixed

If you have questions, you can also ask niko-. He is the other co-maintainer, who signaled his interest.

@niko: Do you have everything to solve this issue?

Super niko-, I gave you the following permissions:
* Write to VCS
* Maintain issues

@niko: Nice! Feel free to work on the existing patches. You can share your updated patch here and if it's tested, we can create an new release.

I am the maintainer of the Permissions by Term module. I do not have an ongoing project, which gathers value from this module. I was working on this module for a long time and did enough. If you like to have Drupal 10 compatibility, feel free to contribute: https://www.drupal.org/project/permissions_by_term/issues/3316032 💬 Searching for co-maintainers Needs review