Account created on 21 January 2018, about 7 years ago
#

Merge Requests

More

Recent comments

Could you explain how I might create a test for a problem with the tests and where to do so? I'm wondering how any changes to the test files are committed if they all require tests of tests.

Yep, I can add a description to the method. I don't think we are currently testing that the User's "pass" field is unavailable on any get request so it's been implemented on the UserTest.

If we need a test for a test I'm not sure how to implement that seeing as it would require an entity that has exactly what the User entity has, a field that is modifiable but not viewable. Please let me know how best to proceed.

I rebased on 11.x and kept the existing functions from 11.x wherever a conflict existed. I'll see about undoing the automated formatting according to our spec.

Just curious:

Is this formatting not matching the spec?

Do we prefer to do material changes and formatting changes separately?

Yep apologies, I marked it ready for review while still working on updates. I opted to move the view protected field checking to its own method as we would want to test in various places, namely after a successful get, post, and patch. I then applied this method after the expected successful requests

Ok thanks I'll take a look at your review

@smustgrave Is it possible to resolve the pipeline errors without fixing coding standards? Do we just ignore them in some cases?

@bbrala, Ya modifying the field access would be one of the ways to protect a field from view. I guess the naming of the issue is misleading. I'll update the name to "Support Testing View Protected Fields". This update is to provide the same sort of patch protected testing that's used on the User entity, and maybe others, to view protected fields.

I think it's ready for review actually. My issue is with the test cases themselves. My issue is that I'd like to build on core test cases to match functionality built on core, but as it stands the core test cases make assumptions like hard-coding the key for the owner field among others. I'd like to not have to maintain an entirely separate test case just to fix this.

Is there more that needs to be done to move this forward?

I'm working on the code changes. These are done and ready for review.

Sorry, I didn't know that. I'm working on the code changes. These are done and ready for review. I also see that I shouldn't assign to myself, unassigning.

Thanks for the advice. I don't often contribute to core. I'm working on some more test cases and running into other issues of this sort. I'll be creating other tickets for these as well. Thanks again and please let me know if that works.

Hi, can I get some feedback on the development for this feature?

I think this is useful feature for whenever you need access to the inline entity before saving the parent entity. This is the case whenever the parent entity has some dependent value on the inline entity aside from the relationship to the inline entity.

Additionally, providing this option moves more towards a decoupled approached of performing one atomic operation.

I added a property to the JobResult for success and failure which will allow you to break from current processing. You can separately set the queue to suspended.

I added a property to the Queue called 'suspended'. You can conditionally set this to suspended depending on your use-case. I think it's better to keep it separate from the Job result.

I agree with kecsot, the solution provided in https://www.drupal.org/project/copyright_footer/issues/3056190 More flexible rendering / text format Needs work is much better than what is proposed here.

Production build 0.71.5 2024