🇳🇱Netherlands @fabianderijk

The target branch has now changed to the 6.0.x branch.

@bramtenhove the new 6.0.x branch has been created. Can you point your MR to this branch? See https://git.drupalcode.org/project/o365/-/tree/6.0.x

fabianderijk → created an issue.

Looks good! Marking it as reviewed and tested

This is now merged in the dev branch. Thanks for the work.

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

Thanks for the patches. However I am marking this as "Closed (won't fix)". Fortytwo is a base theme without any extended styling. As far as we are concerned the styling of the mini pager (and the full pager as well) should be done in a sub theme of fortytwo and doesn't have it's place in the base theme.

Thanks for the patch, I've tested it and everything works. I've also changed the error message so it shows how a GTM ID should look like.

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

Oops, added the credit to the users

Thanks for the good work. The MR is now merged and will be added in the new release.

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

So, it took some time, but in the new 2.0.x version there is a autocomplete function that allows users to search for photos and select those. It is not as extended as yours, however, it is a good start. Marking this as fixed, so we can continue on the new version and add stuff there.

This is now fixed in the new 2.0.x branch. A new release will be created soon!

I've merged the latest changes. Setting the status back to "Active" so the bot can pickup the issue further.

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

This patch seems to work great! Thanks.

I've created a MR to fix this issue

fabianderijk → created an issue.

fabianderijk → created an issue.

I've noticed this as well and released a fix for this issue. You can use the 5.0.18 version of the module. That will contain the fix.

This is now fixed and will be available in the upcoming release.

I've just released the 5.0.14 release with this fix in it

greggles → credited fabianderijk → .

I didn't think about that. I reverted the change on the 4 controllers used to login/logout a user. Thos are probably the ones that are being extended in one way or another.

It's already available in the dev branch. I will create a new release soon.

Renamed Office 365 to Microsoft 365

The patch has been added to the repo. The fix will become available in the next release

Updated the patch for the new version of the module

I've just tested this again with Drupal 10.3.6 and the dev branch of the module. I don't see the error message anymore with the provided steps. Can anyone confirm that is is now (somehow) fixed?

This is now fixed in the dev branch and will be available in the upcoming release

This is fixed in the main branch

fabianderijk → created an issue.

Hi @mandclu, for both modules it would be great to integrate with the Microsoft 365 Connector.. If you are willing, you can start on the Smart Date module.

I will take a look at the full calender module and see if I can come up with some ideas.

I have committed the changes from the MR (and some other fixes). I will create a D11 release soon.

Marking as fixed because of D11

I agree with the exits. All seems to work like it should, so I've committed the code. Thanks for the work!

For me the MR works. I've asked @batigolix to have a check as well.

I've created a fix for this issue. We now pass all e-mail addresses through the lowercase function so we only check, or add lowercase e-mail addresses.

This is now in the dev release and will be in the upcoming tagged release.

We have chosen to use the groups a user belongs to for mapping with Drupal roles. However, it is pretty easy to implement something like this yourself.

You can take a look at \Drupal\o365\EventSubscriber\RoleEventSubscriber and \Drupal\o365\RolesService::handleRoles to see how it is implemented now. If you would like to use the app roles you can use this endpoint: '/me/appRoleAssignments' for the logged in user. These are the docs in the Microsoft API reference: https://learn.microsoft.com/en-us/graph/api/user-list-approleassignments....

If you have any more questions, let me know!

I've checked the fork, and adjusted the code to make it work. All works now like it should. The code has been pushed in the dev release and will be added in the upcoming tagged release.

I've just testen the MR. Everything seems to be working fine, so for me, it is ready to be committed.

I will test the patch this week!

BramDriesen → credited fabianderijk → .

I've just created a new release. It was time to, I agree ;-)

@fgarciap that sounds great! Happy to be able to help!

This is now fixed and added as a setting on the SSO settings form

Mmm, I think that happens because it only uses this setting on creation of the user. For now it doesn't update existing users.

To fix this, I've created ✨ Update username on login Active that I will look into today.

fabianderijk → created an issue.

This is fixed in the 5.0.11 release version. On the admin page (/admin/config/system/o365/settings/sso) you can now enter the correct attribute to use for the username. The issue of the screenshot is something different, but it is fixed in the new release as well.

The release is created, it may take some time before it is actually available.

At this moment we cannot map the attribute. But I will see if I can create a new release with this feature. I can imagine this will happen more often.

The 5.0.7 release had been created and should be available in a few minutes

Great, I'll create the release ASAP.

About the always login. The o365 module won't fix that for you. The module can redirect your users to Microsoft if you want without interference of the Drupal login form, but it won't handle the permissions as you would like.

@fgarciap i've just updated the dev version of the module. Could you check this version? I can't reproduce this error anymore.

Thanks for the MR. This is now merged. A new release will be created in a few hours

Hi @sarwan_verma can you create a merge request for this patch?

fabianderijk → created an issue.

zach.bimson → credited fabianderijk → .

I would say that deleting their passwords is the most safe way to do this. Otherwise they might still be able to login for instance when using the basic_auth module.

Hi Zach, I've taken a look at your code, and everything seems to be promising. I will make you a maintainer on the module! Thanks for everything!

Thanks, I've applied the patch and created a new 5.0.2 release

This issue has been inactive, so closing it. All issues should be fixed by now

You are welcome. I've just created a new 5.0.4 version.

This should be fixed in the dev branch. Can you confirm?

I will take a look at this asap!

I totally forgot about this. We now have a setting to log users out of office when logging out of Drupal. This is also set as default in a update hook for security reasons.

You can use release 5.0.3 for this.

You should use the 5.x version like you said. I've just set that the 3.x version is not supported anymore.

I've reviewed everything on a working intranet we use the module on. Everything is working when using the code in de MR.

I will create a 6.0.x branch to merge this into and start writing documentation on how to upgrade.

Great work everyone!

I will do a check on this code today.

When this works we will have to come up with a strategy on how to release this because this is a major change and may (better yet, will) break working sites. So we probably need to make a 6.0.x branch first before so we can merge this MR into that branch, write documentation on how to upgrade, etcetera.

Thanks for the patch. I've applied it and changed it a bit. This is now available in the dev release.

Thanks for testing nomisgnos! I've just committed a fix for this issue. When the auto redirect option is enabled a non-existing user will be redirected to the frontpage.

Keep in mind, in some use cases this can still create a infinite loop. For instance when the frontpage itself is a page a user need to be logged in for. Maybe this is something we can improve even more in the future (like a special page that is always accessible).

This was related to a local patch we add to the module....

fabianderijk → created an issue.

Drupal 10 release is already there. Marking this issue as fixed

This fixed is now added to the dev branch of the 5.0.x release.

I've just added this option to the dev branch. You now have a checkbox in the SSO settings. When enabled, only user that already have an account on the website can login with SSO. Other users will be shown a error.

Hi @vnech, yes i would like to have this added to the module. I just haven't had a lot of time to check this.

In the meantime, the 5.0.x branch has been created, and I think this should be added there as well as all new features will be added there. I've c opied all changes from the MR to a MR for the 5.0.x branch. Everything seems to be working there. I've tested it, and I can login using multiple Azure apps.

Can someone check as well: https://git.drupalcode.org/project/o365/-/merge_requests/33

This is now fixed in the 5.0.x branch. And will be added to the new tagged release coming soon.

This has now been added to the 3.0.x branch dev release, and is added to the new 5.0.0 release tag

This is now merged. Thank you!

This is now merged. Thank you!