🇩🇪Germany @jan kellermann

Thank you for issue, feedback and testing.

I merged this MR.

Works for me!

Thank you very much for contributing!

I just the changed the form field description (you cannot "uncheck" a text input field).

But I would prefer an option to hide "Powered by" message because on multilangual sites you have to delete for every language.

See https://www.drupal.org/project/klaro_js/issues/3508237 🐛 Bugfix for #536: Check for optOut state while contextual rendering Active

jan kellermann → created an issue.

This is fixed in https://github.com/klaro-org/klaro-js/issues/536

We are considering to update drupal/klaro-js.

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

This is standard behavior of klaro. We will add an option to remove this message. See #3491582

There is an answer: https://github.com/klaro-org/klaro-js/issues/526

• You can remove the "Powered by Klaro" message from the UI.
• You must keep the BSD-3 license text and attribution in the source code.
• Providing recognition elsewhere (e.g., documentation, config page) is a good practice but not legally required in the UI.

So we can add an option under styling.

Wow, good work!

But why the module owners do not use the Drupal-way of placing their javascripts? Then you could just some values for "Attachments" and you are ready.

Maybe you can ask them to work with Drupal standard. Else you can open a MR with your code as sub module which can be enabled if dfp is used.

Thank you again for your work with this module.

It is not possible to give a order of purposes for Klaro! JS. The order cannot be guaranteed by a different sequence of services, as a service can have several purposes.

We have to add the order of purposes to DrupalSettings and order the purposes by javascript.

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

Bump. Updated fork, ready to review. Would be great to have this issue reviewed and merged for next release.

Bump. Updated fork, ready to review. Would be great to have this issue reviewed and merged for next release.

Merged. Thank you for testing and feedback.

Thank you for feedback and testing.

I have added the information to the readme file.

I don't expect any security implications if we don't check whether the module is installed. If someone has access to the code and can manipulate field values, they can also inject code elsewhere. We just do the rendering and let the Klaro helper check the result.

So I set the state to RTBC.

Thank you for testing and feedback!
I merged the MR and will release soon a new version.

I added applyConsents() while initialization.

Please review and feedback.

I added a link to the consent manager in contextual dialog.

Please review and feedback.

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

jan kellermann → created an issue.

Thank you for your feedback.

We were not aware of this error message.

I have created a merge request that always displays the title, but hides it visually by default (it can be displayed optionally). So it should work as a label for the dialog.

I changed category and priority.

Please test and provide feedback. Thank you very much!

The same topic is discussed in #2925718. But it seems, that D11 has solved the problem if session_write_interval is set correctly.

Thank you very much for this issue and the MR.

The parameter data-tcf-enabled should not be hard-coded, there is a setting fot this paramater and will be added optionally in line 106ff.

In most cases the consent dialog should be in browser's language, so this should be implemented as an adjustable option.

Added prefix (and trait) to queues. Tested:

redis-cli KEYS *update_fetch_tasks:counter
1) "drupal:queue:update_fetch_tasks:counter"

redis-cli FLUSHALL

redis-cli KEYS *update_fetch_tasks:counter
1) "iFq2Dg:drupal:queue:update_fetch_tasks:counter"

Please review and feedback.

jan kellermann → changed the visibility of the branch 8.x-1.x to hidden.

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

FYI: I am not currently depending on the patch, because getProvidersForOperationType() does not test whether the OperationType has been registered before.

I can simply add any identifiers in my provider's getSupportedOperationTypes().

See AiProviderPluginManager::getProvidersForOperationType().

Thanks for the feedback (I didn't expect a deliberate removal either :) ).
I have hidden the MR!414 and set the ticket to RTBC.

jan kellermann → changed the visibility of the branch 3499361-ckeditor-does-not to hidden.

Behat/Mink is predefined in Drupals PHPunit-Config. For local testing you need a chromium. We are running this via docker, see here → .
See also this pipeline (line 68ff)
See also this commit.

Therefore, I created a new fork and MR!417 that only fixes the bug and does not make any other changes in code or function.

Feel free to test and give feedback. Thanks a lot.

MR solves the problem for me. Unfortunately, MR still makes changes to the code that are not directly related, for example removing the 3rd parameter when calling the chat() function. Therefore I cannot give an RTBC.

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

@marcus_johansson I got stuck in communication here, sorry.

Yes, AnythingLLM is a RAG out of the box and so no actions are needed in the module. So it would be good if the array was queried beforehand.

I added this commit ("You may need..." instead of "You will need...").

I have updated the fork.

For me the patch works. Because I am not working with actions I did not set RTBC.

> Could you provide any insights into why you wanted a new operation type?

AnythingLLM provides ONE endpoint for embedding AND storing embedded data in vector database. AnythingLLM is an abstraction layer also (you can choose which LLM for embedding and which VDB for storing the data). This means we cannot separate embedding and saving in the vector database.

@akulsaxena: Thank you for feedback. I added operationtype to cspell because the hook name "operation_type" would be misleading.

@marcus_johansson: Thank you again for feedback and the strategic thinking. We need this for search-api because AnythingLLM directly provides an endpoint for the indexing (embedding incl. vdb).

I added the invoke call.

Please review and feedback.

Thank you!

jan kellermann → created an issue.

For testing you can use the /user/password page without further config (only enable antibot) and I uploaded webform.webform.test_3406484.yml → which you may import and use for multi-page webform tests.

In general the scope of this issue moved. The webform-bug seems to be fixed without this issue.

Interesting is comment #5 🐛 Antibot blocks multistep webform submission if user fails to move mouse pointer Active where several new a11y problems are mentioned that call into question the functioning of the module in general for accessibility reasons.

The MR!23 tries to solve this problems and attempts to balance accessibility and spam protection.

@danrod: Thank you for testing. The patch antibot-issue-3406484-2.patch you used is almot 13 months old. Please test with current issue fork.

I changed the test to fill in the form data via JS instead of using Mink because Mink simulates the keystroke events.

Test added.

Default tests ran successfully.

Default Test-only failed as expected:

There was 1 failure:
1) Drupal\Tests\user\FunctionalJavascript\UserRegisterFormTest::testRegistrationFormStorage
Written not strictly necessary Drupal.visitor.name to localStorage without consent.
Failed asserting that false is true.

Please review.

There are other behaviors in the form.js file besides fillUserInfoFromBrowser.

I have not checked if the forms use other behaviors (e.g. formSingleSubmit), but would recommend to deprecate the attachment later, as contrib modules or custom code could use behaviors from this file.

Thank you for fixing. The MR is already for 11.x.

Die stabile Version 3.0 ist veröffentlicht! Ich habe eben die letzten Terms übersetzt.

Danke für Eure Unterstützung und Euren Zuspruch auf dem Weg zu dieser Version.

We just released Klaro! 3.0.0 stable release → .

Thank you all for this journey the last weeks - it was awesome!

Please review and feedback.

Change record added: https://www.drupal.org/node/3498836 →

I created the new child issue #3498834 🐛 Dont use core's prepopulate function for core forms (Privacy) Active with issue description according to template.

I also created a new change record. The old change record → from this issue can be deleted.

I hope that this will speed up the process.

I set priority to normal because depecration is not as important as getting the core compliant with data protection laws.

jan kellermann → changed the visibility of the branch 3498834-dont-use-cores to hidden.

jan kellermann → changed the visibility of the branch 2409107-11x-only-disable-for-core to hidden.

jan kellermann → created an issue.

Tested in company and set RTBC.

Thank you for MR! We remove the whole library because it is not used.

The bug occurs in the context module due to the missing assignment of IDs. This is solved in issue #3277701.

Therefore, I think this issue can be closed as a wontfix.

Issue fork Updated to 5.x - maintainers should change merge target to 5.x

Tested and RTBC.

Thank you for the patch.

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

I was also not able to reproduce this issue on the 5.x branch when using field_group 3.6 and Drupal 10.3.

Please give more information to reproduce.

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

D7 is EOL. I tested on D11 with current 2.x branch and could not reproduce on Safari on iOS18.

If this problem occurs further, we should create a patch for 2.x.

Antibot is more effective after this change than before, but can still be bypassed. If I have understood correctly, Antibot is bypassed by saving and transferring the key. This means that we need more variance in the key.

Suggestion:

Generate the antibot key using the form_token (does webform actually use form_token? I couldn't find one, in this case use the form_build_id). However, this would mean that the antibot key is generated and transmitted per form and no longer per page (but IMHO this does not require any major adjustment, there should also be no differences in caching, because the cache duration is analogous to form_token or form_build_id). Was there a reason why a separate key was generated back then?

Remark:

In issue #3406484, a condition was added as to whether an event isTrusted, which may also improve the quality.

The solution of allowing clicks and querying the isTrusted attribute can significantly reduce the effectiveness of the module. We have therefore created a new merge request that adds an adjustable time component (default 5 seconds) to the click event.

Please review / feedback.

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

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

Merged and fixed.

Set to RTBC after final discussing on slack.
Just resolving last stylelint issues and then merge.

Thank you all for feedback and testing. We couldn't have done it without your support!

How do you think OSM is loaded? The Leaflet module is already supported. We have to interrupt the integration, so we need information about the integration

And which URLs should we integrate? Many countries have their own URLs that can be integrated via iframe, for example. See also this list: https://wiki.openstreetmap.org/wiki/Using_OpenStreetMap#Maps

Merged.

Thank you for feedback.
RTBC

I would suggest 180 days.

In Drupal-CMS Recipe the expiration is set to 30 days.

Danke nochmal! Die v1 kommt hoffentlich in den nächsten 7 Tagen, einige neue Translations kommen dann noch, aber ich mache Euch Vorschläge :)

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

Many thanks for the comprehensive and accurate feedback again. It is a great pleasure to work with you!

title and description

Changed in code and README now. ("also" is correct because there is a standard-style with drupal colors and additional three styles for the known themes).

Olivero

notice: (windows high contrast)

> the notice dialog has no focus outline

Fixed.

consent (windows high contrast mode)

> the toggles dont have a focus outline.

On windows they have a 2px dotted white outline (I removed now the transition of 0,4 seconds).

Claro:

consent (windows high contrast mode)

> the close button is not autofocused like without the WHCM

On windows the outline is visible.

Gin:

windows high contrast mode

I force now the outline for links.

Also done:

• Removed transition from slider buttons.
• Added reverse icon for high contrast mode.

Thanks for the suggestion to chat directly and clarify what needs to be done before the merge.

Ihen I'll postpone this issue and we'll wait as suggested for specific descriptions of the requirements from @schwankde.

As there has been no feedback for 2 months, I set the priority to normal.

Merged. Thank all for feedback and testing. Close this issue.

@junaidpv tested in #3496849.

Thank you for feedback. The I merge #3495565.

Already fixed in 3.5.1 - see #3466125

Could not reproduce.

• I installed a new D10.4 and required drupal/geolocation:^3.14.
• I enabled geolocation_leaflet (drush automatically installed all further modules.)
• I added a new geo field to content type basic page with display Geolocation Formatter - Map without any further options.
• I created a new node with a geolocation.
• I viewed this node as anonymous user with and without JS aggregation and also with multiple drush cr.

Can you provide more information? Maybe a screenshot of network tab in your browsers DevTools?