🇩🇪Germany @c-logemann

@smustgrave Thanks for committing. If I find some time I plan to check for some more scenarios on the file permissions. And in any case it is still a good idea to get test coverage.

I just found this Issue and wondering why the contrib module " EntityReference UUID → " isn't mentioned here. This already uses "target_uuid" . I use it for example for a base field definition in my contrib module " grant → ". But it also have an UI for Field API. I hope EntityReference UUID will find its way into core.

I completely disagree with the starting argument of 2016:
> Currently with Drupal 8 a UUID is useless.

There are so much things we can solve with UUIDs like config entity conflicts and hiding serial IDs (see my module U3ID → . And since 2016 we have much more entity types including logs etc. and still growing. On larger systems this index would be a very huge table and should probably handled like a cache table which can be excluded in backups etc.
Personally I only see this as an interesting idea to find an entity just via UUID. But I hope this is something we won't be dependent on this feature in future because I see a lot of performance issues coming with it. So this should be optional at all or at least optional on any (!) entity type as an OPT IN setting in my opinion.

https://drupalcamp.de

Virtual Host with let's encrypt cert is ready and the old static files are uploaded.

c-logemann → created an issue.

@bradjones1 Thanks for clarification.

The SQLite > MySQL migration ist just getting more important because of Drupal CMS. But this was always a question of migration.

Regarding MYSQL and MariaDB and the problem with growing differences are not in the focus of the Drupal community I think. After the fork there was no migration needed the dumps where just interoperable for a very long time. In my personal experience it's since MySQL 8 it became harder to just use both variants parallel.
On the database requirements page → "we" are still naming them together as "MySQL, MariaDB, or Percona Server (Recommended)". So I can argue the other way around like: We are currently not telling the users that they are (meanwhile) different kind of databases that needed migration.

Because I belief the differences of MariaDB and MySQL will grow in future I don't think we should put energy in supporting a direct interoperable usage of both. So migration is something we need in future between MySQL and MariaDB. I don't want to block anything here but it's clear that the JSON support is one of the things which needs at least documentation about how to handle DB migration. And maybe it would be good to think about this change if there is something we can do make migration between databases easier. Maybe we can tackle two problems at once if we provide an list of Json fields which can be used to show a warning on status page and can be used to export via drush as json list which can be used by commandline database tools.
So in my opinion the migration itself is something that should be managed outside the core with tools like drush. As long as the code is working the same way after migrating the database, everything is fine.

Eigentlich duplicate von #3258991: I attended the 9th Drupal DACH Meetup (February 2022) 💧 ❤️ →

@bradjones1 Thanks again for all the work you doing on this issue. But this is also a big change which isn't easy to understand fast. So I have a question about compatibility between Mysql and Mariadb:
Following their documentation Mariadb has implemented a method to convert "json" tables on import. Is there a similar support on Mysql?
Or al little bit more complex, Is the current approach is supporting situations like this:
Start a project with SQLlite with project browser etc. (see starhot initiative). Install a module with json field. Export database to a Dev-System with MariaDB and then bring it to live with a Mysql Setup etc.

Ein paar der Übersetzungsvorschläge erweitern die die Dokumentation. Das ist nicht Aufgabe der Übersetzung. Das sollte dann zuerst im Modul angepasst werden. Ich habe für ein paar dieser Fälle bereits Alternativ-Vorschläge gemacht aber auch schon ca. 40 Vorschläge bestätigt.

Link zum Projekt zur Summary hinzugefügt.

Ich reviewe da schon mal ein paar.

c-logemann → created an issue.

I hope in winter I find some time to push the file permission issues forward if no one else step in.

@smustgrave Sorry I was to busy in last time.I think we need an own route that can be triggered by drush also with basic auth credentials, see 🐛 Checks using sub requests with guzzle get wrong results in basic auth systems Active
But please do not close the issue. When I finde some tie in winter I try to solve if nobody else steps in.

@smustgrave Sorry I was to busy in last time. Especially this issue is easy to solve when maintainer decides how to manage credentials.

The code change is really simple. See MR.

c-logemann → created an issue.

I decided to keep this views plugin the next time. So it's not a blocker any more. When it's implemented in entity_reference_uuid or even core we can just extend the class. Maybe we remove it with a major upgrade.

There are several startegies in other contrib modules to extend content moderation. I used the same strategy of content_moderation_owner_permissions → . I did not tested yet if working with other contrib modules. Because the core integration with grant main module is complete this feature as "core module integration" is complete.

Ich bin gerade über die konkrete Anweisung "Use gender-neutral pronouns" im Style guide for case studies → gestoßen und habe dies in die Summary aufgenommen.

In case of relation the grant entity is inside $values->_relationship_entities. There are currently two possible relations, on field "user" and on field "assignee". Especially the asignee reverse would be helpful to create user lists.

c-logemann → created an issue.

@avpaderno OK you wrote "single request" but I think it's not so obvious on this doc page → . Now I will follow the process but I think it's a little bit unflexible in cases like this. First I came along and just wanted to offer my help. Yesterday I chatted with a maintainer and he gave me the idea for taking over ownership.

Changes without discussion with existing maintainers is currently even too easy in my opinion. In the past I had a situation where I was only a Co-Maintainer and was suddenly removed by a new owner who dropped any support for the old code. On another project I had a discussion with an owner (without any co-maintainers) and he just decided to give me ownership. What if the current maintainers of this project also want to do this in this case?

Since I dropped ✨ Provide a config to control which entity type to check Closed: outdated I can maybe also drop this. I will think about if I still see a need for this. In any case it's much easier to implement and maintain a hook than a config based solution.

@avpaderno I didn't know that yet. But it makes sense if this issue should be part of the official process. I will add a second issue and connect them.

@pwolanin: Can the test just be created as an addition to current test like a second base field in TestEntityTwo with target user oder do you want a complete separate test?

Already contacted two of the current maintainers. But the one I reached at slack cannot add additional maintainers. Will now contact rest of them.

@eiriksm You are right, when checks only run if there are fields configured to extract links this code is not needed any more. So I close as outdated.

c-logemann → created an issue.

There are now the two views access plugins for role and for permission check which are cloned from core user module and connected to grant context strategy. To get this running I did some refactoring to get the access check through the same main class function from route access which is also used by views and the second check of views. The route access check can now be configured as multiple role check also from other contrib/custom modules. If using in contrib please do it like views is doing it a dynamical route change based on config because roles itself are config based.

This is not a feature request because grant only provide UI fragments and Views is the current recommended way to create a custom UI.

c-logemann → created an issue.

c-logemann → created an issue.

c-logemann → created an issue.

c-logemann → created an issue.

Finished Invite with new feature "assign_auto".

Vllt. können wir das Thema mal beim kommenden Drupalcamp in Berlin besprechen.

c-logemann → created an issue.

c-logemann → created an issue.

c-logemann → created an issue.

Soweit ich das verstehe ist gendern "Inklusion auf Sprachebene". Vllt. kennt jemand dazu auch konkrete Informationen oder wir holen die einfach mal ein bei den entsprechenden Stellen der Drupal Community. Der DCOC gilt für alles hier auf drupal.org, auch für Übersetzungen denke ich.
Es steht zwar nicht explizit so im offiziellen " code of conduct → ", aber ich denke man kann da eher raus lesen, daß wir eigentlich gendern sollten, als daß sich ein paar Übersetzer*innen hier fröhlich nach Lust und Laune dagegen entscheiden. Siehe den Punkt: "We think about the impact of our decisions on others and make choices that are as inclusive as possible."
Ähnlich wie bei Coding Standards, die auch nur für neuen Code gelten glaube ich nicht, daß wir verpflichtet sind alle alten Übersetzungen nachzubessern.

P.s.: Den DCOC gibt es auch auf Deutsch und bräuchte auch evtl. mal ein Update und vllt. auch einen offizielleren "Platz" (falls nicht schon vorhanden). Denn wir müssen glaube ich auch auf Drupalcamps darauf verweisen in deutschsprachigem Content.

I created additional routes for /user/{uuid} and /user/{uuid}/edit in the u3id module and published already:
https://git.drupalcode.org/project/u3id

1. This is working fine.
2. The pathprocessing from actual patch makes it impossible for such clean route solution. So I strongly recommend to not commit for core. I currently even not recommend to not move to contrib or with add a warning for risks of breaking other code.

There are lot's of concerns against a pure uuid strategy as I read here: [1726734]

For getting forward I suggest to focus on a a minimal improvement:
1. First of all we should provide an entity_uuid ParamConverter. For u3id I copied of the core jsonapi: 🐛 Cannot use UUID as entity ID Needs work
2. Following the initial feature request we can just provide a possibility to access entities based on additional uuid route configurations.
3. Per default we can just do redirections and introduce settings.php options to change behavior to an entity view.

Everything else should be postponed for core until there is a larger support for more uuid in core routes. I'm currently fine with my contrib project u3id and already solved the problem of rendering the serial uid in the canonical html link with replacing the entity view controller and use now the uuid path.

I did some research of the current code and the actual patch. I still like to have an uuid everywhere strategy including revision routes. But currently the serial id strategy is deep integrated in a dynamical way. So a complete new strategy especially as dual solution ha a high complexity. So I think this should be postponed until there is more interest and some discussion and decision by core maintainers.

Meanwhile I will solve the user uuid situation in contrib and just created a new project for this: U3ID → . With the U3ID module I can present a prove of concept and maybe something which can move partially to core in future.

I will try to test the current patch against the the dual route concept ASAP on patch /user/{user|u3id_user} if there is a conflict which think it will be. Maybe there are other custom solutions out there based on additional routes which can be affected by the PathProcessor solution of the current patch.

@murz Thanks for the input.

Before I start with coding want to add some additional comments after thinking about two routes which allows several thinks like the described identical scheme which is now possible with symfony.
Using two route definitions for each involved entity makes it possible to realize many thinks like different access and also different routes. We can also introduce switches to enable uuid Routes of core only if somebody wants. And if somebody want the additional uuid route just as a redirect or with a path pattern like /uuid/user/{uuid}" this can be solved separately in additional code/contrib/custom code etc. So it's possible to solve seo concerns with robots.txt is possible.
In my personal opinion, it's currently a big disadvantage of Drupal that it's not possible to avoid serial IDs especially for users. At any other place I can avoid this easier e.g with not using node and other core entities. The reason why I want to avoid this that I think this is very important for situations when you run a web application where others should not see how many content entities are generated e.g. users, shop carts, issue tickets, mails etc. This gives competitor organizations and persons too much information not everyone likes to share. This is maybe a reason why companies and other organizations didn't choose Drupal.
On the the other side brings a uuid only strategy lots of possibilities to export, archive, re-import or import elsewhere of content without dealing with complex redirection data.
Both areas are my current motivation. Beside users I have already solved everything with custom entities and the wonderful module entity_reference_uuid. But it would be fine to have something more in core like an official uuid param converter. I know Drupal\jsonapi\ParamConverter and maybe start to use this at first.

I try to improve in direction of second route as described above.

I'm currently working on a small symfony only project and discovered that it's possible to define multiple routes on an identical path and tested that Drupal 10.3 is compatible with this. For example this documetation:
https://symfony.com/doc/current/routing.html#parameters-validation

I tested the last patch and was wondering why it's working so I found this in the patch code:

/**
+   * {@inheritdoc}
+   */
+  public function processInbound($path, Request $request) {
+    $matches = [];
+    if (preg_match('/^\/([a-z_]+)\/(' . Uuid::VALID_PATTERN . ')$/i', $path, $matches)) {
+      $entity_type_id = $matches[1];
+      $uuid = $matches[2];
+      if ($this->entityTypeManager->hasDefinition($entity_type_id)) {
+        $storage = $this->entityTypeManager->getStorage($entity_type_id);
+        $entity_type = $this->entityTypeManager->getDefinition($entity_type_id);
+        if ($entity_type->hasLinkTemplate('canonical') && $entities = $storage->loadByProperties(['uuid' => $uuid])) {
+          /** @var \Drupal\Core\Entity\EntityInterface $entity */
+          $entity = reset($entities);
+          $path = '/' . ltrim($entity->toUrl()->getInternalPath(), '/');
+        }
+      }
+    }
+    return $path;
+  }

It's interesting that it's working but with this solution we loose the benefit of routing information and debugging etc. I like the idea to just disable integer routes in custom code to only use. If just use an entity_uuid param converter it is possible to use the same controllers for all entity paths e.g. "/user/{user}/edit" with a route 'user.uuid_edit'

I also want to make it possible to avoid user (int) ids in password reset paths where currently {uid} is used. But this maybe something for contrib.

Thanks @vsujeetkumar for pushing this forward/keeping patch compatible.

I removed Tasks from issue which are not on focus of this issue:

• [ ]
• [ ]

Ich habe schon ein paar Strings bestätigt und ein paar korrigiert. Diesbezüglich Wichtiger Punkt: die Konsistenz bezüglich des Namens "Usercentrics" sollte, wenn nicht als macheine name z.B. bei den Permission Erklärungen groß geschribene und vor allem nicht übersetzt werden. Ich nehme an, das stammt wieder aus einem Übersetzungstool. Vllt. macht es Sinn das gleich zu erwähnen. Ich hätte nämlich beinah zwei übersetzte Modu-Namen übersehen, weil es tatsächlich Sinn ergab, aber trotzdem falscher Sinn war :-)

I didn't found the time to test and code but I want to thank everyone involved to solve this.

@quadrexdev I added you as a Maintainer. Welcome to the team.

@quadrexdev Thanks for contacting me directly. I already started to review your request. I already found you on slack. Maybe let's chat the next days. And feel free to use my contact form again when this issue moves out of my focus.

Because the impact is a complete corrupted solr cloud setup it can only help to work with two cloud setup not only different collections.

I finally found the configuration which caused the problem which was based on copying drupal config from one project to another but there was no error on import. SO maybe there is a bug in core or this module.

I only disabled it as workaround and will analyze it when I find some time to. And I will try to create some anonymized config and try to get something which can be used to reproduce this error in a vanilla setup.

Yes, it's true. With the "data-" prefix we get a little bit of more functional data to manage and serve. But it's so minimal that if you want to safe some data there are so many possibilities without getting invalid: Maybe w shorter IDs and classes. e.g. "m-item" instead of "menu-item" etc. Or we could move default public files folder from "/sites/default/files" to "/files" so all links to css etc. would be shorter. And as far as I understand it's not needed to add <meta name="Generator" content="Drupal 10 (https://www.drupal.org)"> to any page.

I started with a a serach prelace of " hx-" with " data-hx-" but didn't touched the two JS files. One reason is that I'm not so familiar with JS which is the reason why really like HTMX.

C-Logemann → created an issue.

C-Logemann → created an issue.

I work on a contrib module "signal" which will also provide a "bridge" between Browser UI and CLI to solve several similar problems/ CLI tasks. There will be a Drush command to "ask" Drupal for tasks, work on the ask an return a report which can be viewed in Browser UI. To keep things light every signal type will be an entity bundle. But I think the automatic update possibility is so important that I will help to configure this as easy as possible e.g. with additional config recipe and/or code if needed.

C-Logemann → created an issue.

Adding something to "oauth2_server.api.php" and a test was already planned. And I will think about the response situation.

setServerData() is currently triggered via cron. This could be an interface to run cron via http request. But in CI situations cron isn't always wanted depending on the system needs.

Currently setServerData() is just returning null on cli usage (see also 🐛 Get server uid function return unexpected type null Active . This is avoids corrects tests but even if we just open it would get wrong values of the file owner and they would be store in state api.
Even if the current code will not mess up with the state API storage and cli can get correct serverdata.- This only would be available after a successful check via GUI. Beside the basic auth problematic (see related issue) this cann not work on a fresh test system e.g. in CI-Workflow.

C-Logemann → created an issue.

C-Logemann → created an issue.

@smustgrave The null comes from a a cli check with empty return on setServerData().

As pointed out on duplicate issue I suggest to return a posix compatible "-1" so we don't need to extend the type. See MR on 🐛 [error] TypeError: Drupal\security_review\SecurityReview::getServerUid(): Return value must be of type int, null returned Closed: duplicate .

@smustgrave, just saw the other issue 🐛 Get server uid function return unexpected type null Active . Let's discuss there.

C-Logemann → created an issue.

Because "SecurityReviewData->findWritableFiles" is already checking the fileowner I think it would be a good idea to move this code to another function which could return two the values writable and possibly writeable because of ownership. For backward compatiblity we can keep the old function as wrapper.

The related issue is more important because it directly tests the possibilty to change the ability to change permissions. The file owner check should maybe be separate because there could be server strategies to avoid changes of permissions like chattr and the ownership of a file cannot be used for changing permissions. And if this is the case it would be helpful to deactivate this check.

@smustgrave OK, we need a test which creates an unsave situation to check if the file permission tests is still working correctly? Or is it only to make sure the test will not cause problems?

On my old concept I was only thinking about checking if webserver is the owner of the code. This can also be a good test additionally to the already working search on writeable folder. But this should be handle in different issues.

3.x work is now addressed in this issue: 🐛 file check is problematic "green" when not test with chmod Needs work

Just found my old issue about this: ✨ "Safe file system permissions" should test the ownership of files and directories Closed: outdated

On my test system (D 10.2, nginx, fpm) I changed the file ownership to secured user and the chmod part was just ignored.