I required this functionality in a project I was working on, so I added the feature to enable batch processing within the cart form.
This is an intriguing concept that I had never considered before, but it makes sense when considering the potential use cases where it could be beneficial. I don't foresee this being a high-security concern; while there are risks, they appear to be minimal. The module employs a constrained callback naming convention (entity_extra_field_{type}_{bundle}_callback), which significantly reduces the attack surface compared to arbitrary code execution.
I would consider adding this to the project; however, it may not be appropriate to include it within the core module. Instead, we could create a separate module, entity_extra_fields_advanced, to handle more edge cases and provide developers with additional tools. Thoughts?
@avpaderno
This is a very frustrating process to get security clearance to create a project as stable. If it weren't for my employer asking this, I wouldn't be contributing to the Drupal community at this point. There are so many communities out there that have a well-thought-out process on how users can contribute their code. I wasn't getting answers on the Entity Field 2.x as that project was hijacked from me and security cleared as added by a user that wasn't the original maintainer of the project. If I close Entity Field 2.x, will you review this one instead? Please work with me here!
Yes, that's something I will be working towards here shortly. Just got GitLab integration so we have a full testing framework set up to ensure we're shipping stable code.
Thanks, Phil, for this patch. I now introduced ESLinting in this module, so I had to make some refinements to your MR, but it's been included in the 2.x release.
@anybody
I need to understand the steps necessary to obtain my personal permissions. Since I initially wrote the module and it is currently being developed by the Drupal community, I can work on updating the project page. Is that the only outstanding issue until I can be provided security clearance?
I would like to reopen this ticket to enable the security advisory for the Entity Extra Field Drupal module. I have made the necessary changes based on what was defined above. The module now has a fully implemented test suite to ensure that the Drupal module code remains in line with Drupal coding standards as we continue to maintain and add new features.
https://git.drupalcode.org/project/entity_extra_field/-/pipelines
The Drupal community has begun compiling a comparison base to determine where entity extra fields fit, in order to understand when you might want to use the entity extra field module over other solutions.
https://www.drupal.org/project/entity_extra_field/issues/3198145 📌 Elaborate how this project distinguish from others Active
I have updated the comparison documentation that outlines various capabilities and explains why someone might prefer the entity extra field module over others.
https://www.drupal.org/docs/extending-drupal/contributed-modules/compari... →
Add core features/capabilities for the Entity Extra Field.
This issue has been fixed and included in the 2.1.x-dev release. It will be committed to a new stable release in the coming days.
@maurizio.ganovelli
This was my inclination as well when I reviewed the code. I've created a patch for anyone who wants to try this solution.
I was able to resolve this by implementing the solution defined in the change log.
https://www.drupal.org/node/3458551 →
You are correct; it should be a lowercase "t", but in the Intercept codebase, it's an uppercase "T"
@attheshow
That's correct; if you use the field UI to add a field to the User entity that allows more than one value to be added, clicking "add another item" will cause an error. You should be able to test that pretty easily.
That does sound like a neat feature to connect directly to the database; we don't have any use cases for that at the moment. If you write a new connection type plugin that supports it, I would be okay with merging that into the project.
This is just a custom version that has many customizations.
That's correct, we're using this on another site which makes a lot of customizations. They've introduced event templates, and those templates use the same event content type, just with a template boolean. We don't want dates to be stored with the template.
Sorry, the above patch was missing code and will not work. This patch addresses that.
I refactored the JavaScript code to support select, checkbox, and radio elements. It's working for me within a paragraphs architecture.
droath → created an issue.
Upon further reflection on this issue, there are two potential solutions for using Entity Extra Fields to render Views. A developer can implement this using either the Views or the Block plugin within the Entity Extra Field module. I currently do not recommend supporting views being rendered in the block plugin when we have a Views plugin available. I've added some additional code to the Views Plugin within the Entity Extra Field module to address this issue. Please let me know if this addresses the issue you're personally experiencing.
@hoegrammer
That's interesting; we committed a patch that was supposed to address that exact issue, as most people were experiencing the problem where the configuration naming was set up incorrectly, which was introduced in a previous patch that was committed some time ago.
Can you confirm that after the upgrade you run `drush updb`?
Sorry this has taken so long to get merged in; much appreciated.
I wasn't able to get the MR to apply. Are you able to reroll?
I finally decided to confront this issue myself and began investigating what was happening, while also trying to recall my thoughts during the initial development process. Based on the current architecture of the Drupal condition API, it seems that core conditions are at least managing negation within the evaluation method of the condition plugin. I believe this was the standard that most developers were using within contrib. has well.
With that in mind, it makes more sense to wait for guidance from Drupal core. If they decide that condition plugins shouldn't handle their own negation, then we can patch the code accordingly. However, until a decision is made, I think the best approach would be to use the Drupal core patch https://www.drupal.org/project/drupal/issues/2535896 🐛 ConditionManager::evaluate() should not negate results itself Needs work to address this issue. Checking the `$condition->isNegated()` method and negating the value ourselves could introduce more bugs, as there is no clear way to determine whether the condition evaluation method has implemented the negation within the evaluation or not.
@anybody, this change appears to be a duplication of https://www.drupal.org/project/entity_extra_field/issues/3440365 🐛 Unable to edit existing extra field or render any public site pages Active . Can you confirm?
Closing, as it appears to be a duplicate of #3440365.
I'm currently in the process of getting the module approved by the Security Advisory. If anyone who uses this module has some time and would like to review the application, it would help push this process through faster. That would be much appreciated.
https://www.drupal.org/project/projectapplications/issues/3468193 →
I've updated the default branch in GitLab.
@Grevil! Much appreciated, I've been waiting to implement this feature for a while! :)
@Anybody Yes, once those issues are resolved and marked as reviewed by the community, I'll merge this into the dev release.
Much appreciated, I couldn't agree more with this change.