🇧🇪Belgium @matthijs

These are server keys, not user keys. If somehow the private key of an OpenID server leaks they can revoke it, otherwise a malicious provider would be able to sign the authentication data with the leaked key and thus forge sign-ins.

Hi,

I'd say that twice or even once a day is fine.

The cronjob is indeed used to update the stored JSON web keys (which are used to verify the incoming OpenID Connect request).
But the validation code also contains a fallback, when an unknown key ID is specified it automatically updates they key set to make sure it ain't a new key.

The main reason to keep the cron is to also remove any revoked keys, so it's up to you to decide what "risk" (accepting a revoked key) you are willing to take.

Hope this helps a bit?

The MR fixes this issue + adds support for an array of IDs and I also refactored the entity loading.

matthijs → created an issue.

I haven't heard from Robin, neither did I get access. So I assume this issue this issue can proceed?

Should be fixed by the widget update to version 5.x.

Thanks for your MR.

I was looking at this myself a while ago, and it seems that in 9.0.0 the constants were replaced by enums so I assume a bit more changes are needed because we store their values.

Is this still an issue? I'm waiting on an ACM-IDM onboarding to test it.

Closing this one since it's not going to happen.

Thanks for your request.

Just for my understanding: is there a reason why you can't use the <role>-<context> format?
The company number is normally passed as :<scope> suffix and the module duplicates all <role>-<context>:<scope> roles as <role>-<context> so both mappings can be used.

Sure, sorry for the wait, 1.0.4 has een released.

Could I get an update on this one? Thanks!

I'm not sure if that solution is the best way to go, because this will obviously also change the behavior in the frontend + uses entity type specific permissions.

I just merged the functionality of this module in the Entity 404 → module (since version 2 was based on it anyway), there I fixed this by using a backtrace to get the language of the Url object. Far from ideal, but core doesn't provide another way to handle this.

Can you maybe try out Entity 404? If that approach works for you we can apply it here as well.

MR merged, thanks for your contribution!

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

So just adding ^11 is enough?

I can confirm the patch in #6 works as expected.

Made width and height nullable as a quick fix, their might be more to it.

matthijs → created an issue.

Created an MR from arwillame's changes and did some minor improvements.

matthijs → changed the visibility of the branch 1.2.x to hidden.

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

Moving to the Drupal.org project ownership queue as described in the official process.

Yes, I'll move the issue to the Drupal.org project ownership queue in 10 days. The MR here (not gonna create a new issue for it) is just FYI in case murilohp would like to do a review. Thanks both!

matthijs → changed the visibility of the branch 3519648-offering-to-maintain to hidden.

@murilohp Could you create a 2.x branch so I can create an MR to it? This will allow you to review what I did, but please don't merge (yet) nor publish a new version. Thanks!

Thanks for your offering to help murilohp! I can (once our module is finished) open an MR for sure, but that way of working will be a hassle in the long run, so let's hope robin.ingelbrecht replies.

matthijs → created an issue.

Good catch. Thanks for the patch, I committed it.

I see I forgot to give credit, sorry about that.

Patch applied an committed, thanks!

I created an MR with first attempt to get this fixed.

Further enhancements are probably required, but the code is rather all over the place so it will need a full cleanup.

matthijs → created an issue.

The MR does the initial part, their might be more needed (e.g. cleanup DI).

matthijs → created an issue.

matthijs → created an issue.

I created an MR with the changes that were also suggested in #2504709-10: Prevent _wrapper_format and ajax_form parameters from bleeding through to generated URLs → . It might not be the best nor a complete solution, but it fixes our issue.

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

This should be fixed in version 2.0.0.

This should be fixed in version 2.0.0.

This should be fixed in version 2.0.0.

I've hidden the 3194171-bad-interaction-between branch because it doesn't work as expected. Let's work on the other MR.

matthijs → changed the visibility of the branch 3194171-bad-interaction-between to hidden.

matthijs → changed the visibility of the branch 3107501-order-summary-shows to active.

matthijs → changed the visibility of the branch 3107501-order-summary-shows to hidden.

I encounter the same bug and tracked it down to the order changes in \Drupal\commerce_promotion\Plugin\Commerce\InlineForm\CouponRedemption::applyCoupon and \Drupal\commerce_promotion\Plugin\Commerce\InlineForm\CouponRedemption::removeCoupon having no effect on the order in the checkout flow form object.

If you add following code (which forces the order to be reloaded in the form object) after saving the order in these methods, the issue is fixed.

This is obviously not the proper fix. I guess the best solution would be to extend \Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowBase with a setOrder method?

Since the lifetime of the access token is rather short and there's no refresh token I saw no other workaround than adding a setting that allows you to use a realm only for authentication. This means that Drupal will not store the OpenID Connect tokens, validate the remote session or trigger a remote logout when applicable.

So basically when a user logs in using OpenID Connect the remote session is "forgotten" after the claims are processed.

There will be coming one later this week, but I first want to see if I can add a fix for #3507175 as well.

Changes have been merged, thanks for your effort.

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

Changes merged, thanks for the effort!

This was fixed in 🐛 With 10.2 image styles might get wrongly flushed Active

I've spend a long time investigating this bug and it seems image_effects_image_style_flush() is to blame, it doesn't implement the $path parameter causing the whole style to be flushed.

I wanted to share a simplified (aka extending on the default widget) version of the widget above:

namespace Drupal\module\Plugin\Field\FieldWidget;

use Drupal\commerce_order\Adjustment;
use Drupal\commerce_order\Plugin\Field\FieldWidget\AdjustmentDefaultWidget;
use Drupal\Core\Field\FieldItemListInterface;
use Drupal\Core\Form\FormStateInterface;

/**
 * Provides the adjustment with percentage widget.
 *
 * @FieldWidget(
 *   id = "commerce_adjustment_percentage",
 *   label = @Translation("Adjustment with percentage"),
 *   field_types = {
 *     "commerce_adjustment"
 *   }
 * )
 */
class AdjustmentPercentageWidget extends AdjustmentDefaultWidget {

  /**
   * {@inheritdoc}
   */
  public function formElement(FieldItemListInterface $items, $delta, array $element, array &$form, FormStateInterface $form_state) {
    $element = parent::formElement($items, $delta, $element, $form, $form_state);

    /** @var \Drupal\commerce_order\Adjustment|null $adjustment */
    $adjustment = $items[$delta]->value ?: NULL;

    $element['percentage'] = [
      '#type' => 'value',
      '#value' => $adjustment?->getPercentage(),
    ];

    return $element;
  }

  /**
   * {@inheritdoc}
   */
  public function massageFormValues(array $values, array $form, FormStateInterface $form_state) {
    $result = parent::massageFormValues($values, $form, $form_state);

    foreach ($values as $key => $value) {
      if (!$result[$key] instanceof Adjustment || empty($value['percentage'])) {
        continue;
      }

      $value = ['percentage' => $value['percentage']] + $result[$key]->toArray();
      $result[$key] = new Adjustment($value);
    }

    return $result;
  }

}

The solution of #3508677 also seems to work for this one

The MR adds a JavaScript callback to properly encode the current query parameters.

matthijs → created an issue.

matthijs → changed the visibility of the branch 3193844-leverage-views-grouping to hidden.

matthijs → changed the visibility of the branch 3193844-leverage-views-grouping-11.x to active.

Created a MR for 11.x, which also works for 10.4

matthijs → changed the visibility of the branch 3193844-leverage-views-grouping-11.x to hidden.

Initial code review looks okay, will do some more testing in the upcoming days.

Thanks for your work so far.

The patch still applies to 2.x and seems to work fine.

The patch seems to work nicely, but shouldn't we also require Paragraphs 1.18 in composer.json?

Thanks for the patch.

With the current setup you have a dedicated dev environment for the module. I agree it's not common, but it eases development a lot.

The unneeded dependencies are in require-dev, so they aren't installed when you install the module in your project. The only thing that would be visible it is the scaffold integration (as in core mentioning that it is ignoring it). I will investigate if I can remove/prevent that.

Noticing the same issue while updating from 3.0.1 to 3.0.5, the patch seems to fix it. It seems my project used 8.x-1.x-dev in the past, which explains why the class is known in the DB.

matthijs → created an issue.

Patch committed, thanks!

I created an MR in 🐛 Range slider settings don't allow different min/max type Needs review that also contains some range/rounding related (not sure if it will fix all issues mentioned here).

Created MR for Facets 3.0.x. I also fixed some issues related to the min/max being not in sync with the step (related to #3182839).

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

Fixed various issues, e.g. compatibility with the 6.x version.

matthijs → changed the visibility of the branch 3479830-the-enyodropzone-library to hidden.

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

I converted the patch from #3118296-17: Add extra fields to config → into an MR and fixed compatibility with 4.3.3.

matthijs → changed the visibility of the branch 4.x to hidden.

@vidorado @gaëlg I resolved them all.

Removed the fieldable property from the entity annotation as per https://www.drupal.org/node/2346455 →

The project has his own phpcs config, please use that one.

There's no "real" benefit, except preventing a call to the system's clock. But to be honest I'm not convinced of the timestamp usage, you could also display the file creation time when listing the files.

matthijs → created an issue.