seantwalsh → credited anoopjohn → .
anoopjohn → created an issue.
It looks like KeyCloak supports OpenID Connect, and SAML for SSO. We really don't need any additional information from Drupal.org other than the email id saying that the email id has been authenticated through the drupal.org authentication system. For external clients - we don't even need authorization services from Drupal.org, just authentication should be enough.
In terms of setting up a site to start using it - Drupal already has OpenID Connect and SAML support. All we need to do is to configure Drupal.org KeyCloak server to allow authentication from a set of registered client appications (domains that are allowed to redirect requests to d.o). Keycloak already allows this out of the box.
If KeyCloak is already set up, then the next question is - is there anything that is preventing us from rolling this out for all our Camp websties to start using?
JD has started a thread for discussing this in the event organizers channel in Drupal slack - https://drupal.slack.com/archives/C03KZ3BETNH/p1740330500636009
The idea is to allow more people who come visit the Drupal.org website to interact with the developer community already on slack.
Lower the cost of engagement for these users so that we can attract and retain more of these users into active engagements within the community.
Being able to interact live with people who actually maintain the module or other users who use the module is definitely going to be a value add for a person who is looking into the module / Drupal but not quite yet coming in to raise an issue.
They will never go to slack without a need to go there but if we bring the slack widget live into the website, we can get them to start interacting and engaging with the community.
Again the idea is to drive more engagements and interactions with current and potential new users of Drupal so that we can build deeper relationships with people who already use Drupal and maybe attract those not already using Drupal to start using Drupal.
We will continue to use "modules" when we talk about modules? Will we use the word "contrib"? Or we just move to generic "Addons". Will we talk about "Core modules"
Given D8 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D8 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D8 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
Given D7 EOL, closing this issue. If somebody is still looking to get help, please reach out.
I have updated the default branch to 2.x
I have asked the developer assigned to this to look at the issue. Apologies for the omissions in pending issues. We will address those quickly.
@Anybody - You should already have the permission to make commits and create releases. Please let me know if otherwise.
Why is this still open? Isn't Thunder already on Drupal 10?
Moving this to the AI initiative project.
anoopjohn → created an issue.
seantwalsh → credited anoopjohn → .
anoopjohn → created an issue.
anoopjohn → created an issue.
This would be a great feature to have. Especially with projects that are under active development / enhancements / customization, there would be a lot of time savings for its developers.
Is that all you need to enforce namespacing and preventing collisions?
Don't we want to enforce module name prefix when we are loading permissions from the file
Also any reason whey we can't auto prefix the module name to the permission name when we load permissions from the file?
The patch works correctly on a 10.1.6 drupal site and stops showing warnings against views in the database.
Yes, he has been contributing in the queue as well. Thanks @Grevil. I have also set you up as a maintainer.
I have set up 'Anybody' as a maintainer on the project.
The project is maintained by the company and different developers working in the company are requested to look into these issues when they are allocated to work on this. However, I definitely do agree that the module could do with some 'love'. Hope @Anybody will be able to bring that to the table.
anoopjohn → created an issue.
anoopjohn → created an issue.
anoopjohn → created an issue.
Committed and pushed to dev branch
Wouldn't this be an easy update to show the date in the releases listing? If a patch is created, would it make it as a feature that goes live?
anoopjohn → made their first commit to this issue’s fork.
Ok. Let me get somebody on this and get a first cut done and get back.
This is absolutely fabulous.
Drupal agencies should rally behind this. All commercial Drupal organizations, who have the ability to send out press releases, should send out a press release saying this and also cover this in all of their newsletters going out and also on their websites.
Drupal can emerge as the platform of choice for all Government organizations across the world. That would be a huge win for the Drupal community.
Thanks specially to @Daniel for taking that first step and also putting in all the effort through the collection of data for the application. Thanks also to Tim Lehnen, Tim Doyle, Von Eaton, Kristin Romaine, Rachel Norfolk and all the anonymous contributors who have contributed towards the application process and also to Dries for supporting and taking this through formally. Thanks to Tim Lehnen and Tim Doyle for taking this through the formal application process both at DPGA and within DA.
We should use geolocation and show targeted local event ads - both camps and meetups - to all visitors on Drupal.org. If we can promote our local communities better and get better participation and support, we will be able to get more people to come become part of the larger Drupal ecosystem.
Sorry, missed this earlier. Happy to see this fixed. Thanks for pushing the fix @Gábor Hojtsy
nicxvan → credited anoopjohn → .