@fathima.asmat

gábor hojtsy → credited fathima.asmat → .

Just cut a release for this fix - 2.0.0

fathima.asmat → created an issue.

mikelutz → credited fathima.asmat → .

I can confirm the MR from #26 is working fro me. I have rerolled it as a patch for D10.2

@marcoliver, the PR looks good but just a query. is there any reason why we didn't upgrade @babel/core to 7.24.0 but instead 7.23.9. 7.24.0 was released 7 days ago and I think the first commit on the PR was made before then?

fathima.asmat → created an issue.

fathima.asmat → created an issue.

fathima.asmat → created an issue.

Great news, thanks everyone!!!

Many thanks for your feedback, Apaderno. All your comments are addressed and the updates are pushed to 1.0.x branch.

Thanks andrei.vesterli for the feedback.

I have added the suggested improvements to README, composer.json files along with the hook_help to the module.

I haven't added a default install config for default settings as I don't want to keep the bulk option on for any entity type by default until the admin manually turns that option on after installation.

Could @apaderno or one of the core reviewers please kindly review this application and feedback? It is affecting our live deployment as our client is really pushing hard to get the security cover for this project before go live.

Many thanks in advance.

Thanks, Yogita, for the suggestion to clarify the warning message. As Vishal pointed out, this pertains to a security application issue for the project, and we should only use this for addressing security-related or breaking issues.

Since the reported issue is more of an improvement, it needs to be created as an issue in the project's issue queue. I've just done that for you and marked it as resolved in a new release. Feel free to review and provide feedback on that project's issue here: https://www.drupal.org/project/author_bulk_assignment/issues/3398675 🐛 Make the warning message clearer when the author assignment fails for entities inaccessible for the selected assignee Fixed . I've credited you for your contribution in checking the module and suggesting the improvement. 😊

Vishal, your continued feedback and advice are greatly appreciated! +1

Added a new release with the changes. Module description is updated too

fathima.asmat → created an issue.

Normally, does it take really long for the other reviewers to review and verify the application? Drupal Con Liile might have caused some delays :D

Ah, thanks @vishal.kadam - I have missed it from the title but added to description field. I have pushed the requested fix now, see https://git.drupalcode.org/project/author_bulk_assignment/-/commit/4a1f6...

fathima.asmat → created an issue.

fathima.asmat → created an issue.

fathima.asmat → created an issue.

thanks for the new release. I'll mark it as fixed

Re-rolled 35 for D9.5 compatibility

Gábor Hojtsy → credited fathima.asmat → .

There is a new release for D10 compatibility - https://www.drupal.org/project/permissions_by_term/releases/3.1.22 → .

Great, thanks for the quick work @Peter. The release is done, https://www.drupal.org/project/permissions_by_term/releases/3.1.22 → , tada!!!

Thanks @Kristen for all the help with this +1

@Peter, I'm assigning this issue over to you to push this froward with the hope of creating the new release soon :)

A new issue is created to create a project release for the new tag, https://www.drupal.org/project/permissions_by_term/issues/3353813 📌 Create 3.1.22 release for Permissions by Term Fixed

fathima.asmat → created an issue.

So as majority suggested, I have merged the patch to dev branch and committed a tag 3.1.22. I will speak to Kristen Pol and get a module release out as I don't have enough permissions to do that. Thanks to everyone who contributed with this +1.

@amitvin, what issues were you having while applying the patch? Could you add the interdiff for the patch you created so that it would be easy to view the changes that you have made with the patch, there is some guidance here about interdiff in case it's useful, https://www.drupal.org/node/1488712 → .

The patch #51 though enforces HttpKernelInterface::MAIN_REQUEST that can't still be replaced for HttpKernelInterface::MASTER_REQUEST as MAIN_REQUEST constant is only supported by Drupal 10 but not D9. To keep the module compatible for both D9 and D10, we should retain HttpKernelInterface::MASTER_REQUEST. This would not be a problem for D10 still as the constant will not be dropped by Symfony until version 7.

Thanks Larowlan and Kristen +1. I'm happy to commit this to Git and will need help creating a release for it as I don't have permissions for it.

I just tested my git push access to the repo and it seems like it's working, https://git.drupalcode.org/project/permissions_by_term/-/tree/d10-compat....

Here is an updated patch for the formatting issue and the info.yml compatibility for the sub module permissions_by_entity.

The patch applies cleanly on D9.5 and D10 as well, upgrade_status seems happy just with a flag for Symfony HttpKernelInterface::MASTER_REQUEST which can't be replaced to use HttpKernelInterface::MAIN_REQUEST yet as the module has to support D9.5 as well.

Kristen Pol → credited fathima.asmat → .

Kristen Pol → credited fathima.asmat → .

Kristen Pol → credited fathima.asmat → .

Thanks Peter for adding me as a co-maintainer +1

I will take a look at the D10 compatibility issue this week, review and coordinate :)

Hi Peter,

I'm interested in co-maintaining this module if this offer is still open :)

Thanks,
Fathima

fathima.asmat → created an issue.

Rerolled patch 54 to resolve warning "Undefined index: title_display in template_preprocess_text_format_wrapper".

Thanks @gisle.

1. There has been no activity from the existing maintainers with the module in the last two years so I don’t think there is likely any chance for them to push this forward :(

2. I found the guide, but I can't see anything there on how to get that without having my own module. I don't have my own module unfortunately and I'm a budding contributor

3. I have asked in the #d10readiness channel if anyone is up for partnering up

I’m not sure of the next steps here so I have checked this in #d10readiness Drupal slack channel. Berdir suggested that I partner up with someone who has permissions to progress this as an alternative way forward. Would anyone who has already commmeted on this issue with enough permissions be interested in partnering up to progress this further please?

Thanks Kristen. Moved the issue to the project ownership queue, https://www.drupal.org/project/projectownership/issues/3351646 → .

fathima.asmat → created an issue.

I believe we have hit 14 days since we contacted the maintainers and @apaderno can add me as a co-maintainer?

Why is the issue status marked to be 'postponed'? Shouldn't it be active as it's still an active issue at-least until the 14 days?

Just an updated to convey that I just sent a message to Domenic regarding the offer on 17/03/2023.

Hi everyone,

sorry for the slightly later response as the last few days were quite hectic. Of course, I'm still interested. It has been three days since I contacted Agnes. I'll send a message to the core maintainer as you both suggest :) Thanks for all your support +1

Contacted one of the maintainers, Agnes Chisholm ( https://www.drupal.org/u/amaria → ) on 14/03/2022.

Thanks @johnv for merging the fix.

I guess you have also installed Token module, and some module to add tokens in the view mode, like Automatic Entity Labels?

I haven't got the token module installed. If this is the case, shouldn't the module to declare the token and the other contrib module as dependencies from the info file and install them as well during the module installation?

The following bit of code checks the token module service to grab the token type and if not available the module skips from setting up the tokens from the token_info hook.

 $token_type = \Drupal::service('token.entity_mapper')->getTokenTypeForEntityType($entity_type_id);
    if (empty($token_type)) {
      continue;
    }

This seems like token is a strict dependency for this module, hence should be defined in info.yml as a dependency, perhaps this needs to be created as a separate issue?

Entity repository service corrected in this patch.

Patch attached.

fathima.asmat → created an issue.

Patch attached.

fathima.asmat → created an issue.

fathima.asmat → created an issue.

Gábor Hojtsy → credited fathima.asmat → .

#29 doesn't work for me when translating taxonomy or node field labels. Technically clearing entity_field.manager cache should do the trick, however it does not unfortunately. Only the combination of clearing render, page cache along with the entity field manager work for me. Though I don't like this workaround, I'm using this as an interim solution for my projects until a proper fix is released.

I have got these in config_translation/src/Form/ConfigTranslationFormBase.php:

\Drupal::service('entity_field.manager')->clearCachedFieldDefinitions();
\Drupal::service('plugin.cache_clearer')->clearCachedDefinitions();
\Drupal::service('cache.render')->invalidateAll();
\Drupal::service('cache.dynamic_page_cache')->invalidateAll();

Attached a patch if anyone wants to use the workaround for now.

Patch 6 works for new translations but does not affect existing draft translation that should be treated as default revision when there isn't a published translation. So we may need something like:

      // Check if any of the translation revision has a published version,
      // otherwise set the latest translation to default revision.
      if (!$update_default_revision && $entity instanceof TranslatableInterface && $entity instanceof RevisionableInterface) {
        $update_default_revision = $entity->isNewTranslation();
        if (!$update_default_revision) {
          $update_default_translation_revision = FALSE;
          $published_translation_revision = FALSE;
          $langcode = $this->languageManager->getCurrentLanguage()->getId();
          $storage = $this->entityTypeManager
            ->getStorage($entity->getEntityTypeId());
          $revision_ids = $storage->revisionIds($entity);
          if ($revision_ids) {
            foreach ($revision_ids as $revision_id) {
              $revision = $storage->loadRevision($revision_id);
              if ($revision->hasTranslation($langcode) && ($translation = $revision->getTranslation($langcode)) && $translation->isRevisionTranslationAffected()) {
                if ($workflow->getTypePlugin()
                  ->getState($translation->moderation_state->value)
                  ->isPublishedState()) {
                  $published_translation_revision = TRUE;
                  break;
                }
              }
            }
          }

          if (!$published_translation_revision && $entity->hasTranslation($langcode) && $translation = $entity->getTranslation($langcode)) {
            $update_default_translation_revision = !($workflow->getTypePlugin()
              ->getState($translation->moderation_state->value)
              ->isPublishedState());
          }

          $update_default_revision = $update_default_translation_revision;
        }
      }

Patch attached.

Kristen Pol → credited fathima.asmat → .

Patch attached.