🇮🇳India @nikunjkotecha

This looks great but probably a final solution, to begin with let's implement hook_alter in below files before we actually log so developers can add code to sanitise fields they want and in a way they want (full / partial / etc.) ?

• log_entity_operations_entity/src/Logger/EntityOperationEntityLogger.php
• src/Logger/DrupalLogger.php

If you agree we can keep this ticket as is and add the smaller scope in another ticket. This ticket would be really handy for people not doing any code or very little code, however projects interested in logs are mostly developer friendly projects :)

This is more like image_widget_crop is not having proper format of data, I am happy to add the code but it should be marked as contrib module support (or category support)

Do you agree? If no, please share Drupal CORE example.

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

Please check https://www.drupal.org/project/log_entity_operations/issues/3520493#comm... 📌 Offering to co-maintain Log Entity Operations Active

Thanks, Omar, for offering to co-maintain — I’d be happy to share access!

Before moving forward, I’d love to get your thoughts on what you feel is currently missing to consider the module stable. Feel free to ping me on Slack at #d6fjtkkhb, and I’ll add you to the channel we've set up for this project.

As for the current "beta" status — the main reason is the broad scope of the module. Since it can log virtually anything, there’s a potential risk of capturing sensitive data like credit card or personal user info, depending on how it’s implemented. While this isn't something we can fully control, it's still a consideration from a security standpoint.

That said, I think there's a great opportunity here: we could look into adding redaction support for common use cases — like Drupal Core, Commerce, and other widely used modules. That would be a big step toward stability. Until then, a stable release might give the impression that security is handled out of the box, when in reality it's currently still the responsibility of the development team.

Looking forward to collaborating on this!

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

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

can we please have an MR for this?

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

Thanks everyone for hard work, based on last few comments I can say it is already tested in multiple projects so merging it.

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

Apologies for the delay

https://www.drupal.org/project/search_api_algolia/releases/3.1.0 →

Issue was created as bug, changed to feature request now. Thanks everyone for the work.

Thanks, MR merged, will release new version soon.

Thanks everyone for the great work, can someone please help review and approve the MR https://git.drupalcode.org/project/clientside_validation/-/merge_request... ?

I have lost touch with Drupal projects so not really sure MR is exactly as per requirement or we need something else?

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

Thanks everyone

Thanks for the updates Dhruv, can you please check code formatting issues?

I am sure he won't mind, as I said before it was me only who asked him as he was the developer for the module in the project.

We didn't manage to push anything as our requirements were highly custom and we were not able to find a way to make something contributable.

I don't have his number handy and I don't see him Drupal slack. I sent message to him in LinkedIn. IMO he has not responded since past 14+ days already so we are good to move forward.

Hi Alberto,

Apologies for quick reaction (not an excuse but it was early morning and I was just happy to let someone contribute).

This was created by Avinash on my request, we both were working together at the time on the project. I am happy to try and connect with him to respond but I am sure he will have no problems as we both are no longer associated to the project and going to work on this.

About taking over the namespace - is there something I or Avinash will have to do or that will be taken care of by you / moderator team?

Maintainer added

https://www.drupal.org/node/3108446/maintainers →

Thanks for reaching out and contributing to Drupal.

Not sure why I didn’t get message from contact form before, I will check that separately.

Please go ahead and transfer the namespace, I will make them project maintainers and later if they want can remove us.

Please fix conflicts

Please raise MR against 4.0.x (last development branch)

Feedback on MR

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

There is feedback on MR

@Rohit, please raise MR :)

@Joe can you please create MR? Check https://www.drupal.org/project/clientside_validation/issues/3504340 🐛 Client side jquery validation module settings page broken Active for example

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

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

MR merged

Considering workaround is possible in 9.x and 9.x is no longer supported I am inclined towards not doing any fix for this.

Wrong project in previous comment
Considering workaround is possible in 9.x as explained in https://www.drupal.org/project/search_api_algolia/issues/3381297 🐛 Algolia Library Version Active and 9.x is no longer supported I am inclined towards not doing any fix for this.

Need an MR to review and merge.

@alex9000

I recommend to move to latest version and/or provide steps to reproduce with configurations (you can redact secret info)

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

@vasyok please share more details

Can we please have full steps to reproduce so we can review the patch and confirm the fix?

Details required
* Content type
* Taxonomy / reference fields
* Views, what field is the filter applied on

Also, how is this different from https://www.drupal.org/project/search_api_algolia/issues/3352807 🐛 Views "IN" filters not working Needs review ?

Can we please have full steps to reproduce so we can review the patch and confirm the fix?

Details required
* Content type
* Taxonomy / reference fields
* Views, what field is the filter applied on
...

Also, how is this different from https://www.drupal.org/project/search_api_algolia/issues/3223351 ✨ Handle 'IN' operator Needs review ?

Closing in favour of https://www.drupal.org/project/search_api_algolia/issues/3256840 ✨ Item splitter processor to avoid record size limit Postponed: needs info

Closing in favour of https://www.drupal.org/project/search_api_algolia/issues/3256840 ✨ Item splitter processor to avoid record size limit Postponed: needs info

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

Thanks Jan.

privacy by design / privacy be default

I belive this is enough to say we should have a config. However it should be applied only if required. Meaning, by default there should not be any limit but only if a configuration is enabled it would set the expiration time, only if it is not already set (even if it is set to 15 days and configuration is 10 days it should stay 15 days).

In the PR I would expect
* New configuration in the module to allow setting this expiration, default value 0
* Config form to set the value in hours
* Override the cache set function and set the default value for $expire to null
* if it is NULL, set the default if available in config, if not available set it still to Cache::PERMANENT
* Call parent function

This is very high level, feel free to modify based on issues you encounter while implementing. Only thing is the function in the class should only set expire if it is NULL and it should not copy/paste code, call parent instead

Lastly, please update tests.

Please raise MR against 4.0.x and also check Error handler has changed error

Hi Jan,

Setting expiration time of cache is available out of the box, any reason we should not use that?

This module only provides way to cache data, it doesn't decide whether the data is product for commerce or customer information. In my opion it is upto the dev team to use it as per the requirements and make sure any compliance is maintained.

Drupal CORE uses garbageCollection to removed expired entries which is not overridden. Meaning, if the custom code ensures cache expiration time is set to 14 days instead of -1 it will be removed automatically.

Merged into 4.0.x, will create new release for it

too many changes, little hard to review

I will try and validate the code changes in my project

To be honest it makes sense to add the check but I am just wondering how was the data indexed?

Is there an exception even when indexing data?

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

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

@mediabounds @segi

Apologies for the delay.

Can you please rebase your changes with latest, test once and confirm?

I will merge in max 2 working days after you update.

This got merged into another (more recent ) ticket, apologies for this. I should have started looking from old to new.

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

Fixed in https://www.drupal.org/project/pcb/issues/3451251 📌 Automated Drupal 11 compatibility fixes for pcb Needs review

Please check if https://www.drupal.org/project/search_api_algolia/issues/3437458 ✨ Add ability to "Partially update" items instead of overriding. Fixed fixes the issue.

If need more support please add more details, steps, use case to understand and try to develop.