Note that I am currently getting,
Problem 1
- Root composer.json requires npm-asset/drupal-rjsf--editor, it could not be found in any version, there may be a typo in the package name.
Looks like this already got fixed in https://git.drupalcode.org/project/jsonapi_extras/-/merge_requests/55/diffs
Upon further investigation, this seems to result in a circular reference. Someone who has a better grasp on the code should take a look.
On further consideration, I guess I can use field_permissions to restrict access to just the fields I don't want to share, and that gets rid of the immediate problem of disclosing info that should not be disclosed. But that has to be done on a per-role basis rather than a per-user basis, whereas I had been hoping, through the configuration of this module, to restrict access to a single user. So I'm marking this as "works as designed," but I am still left wondering, why provide the option to restrict the channel to a single user when the feed with the actual information in it is not restricted?
Sorry, just saw your comment, @joachim. I understand your argument that this is out of scope for entity_share. My argument is that since A) there is no module that restricts jsonapi feeds by user and B) this module allows restricting channels by user, therefore it makes more sense to offer to restrict jsonapi by user within this interface, because just restricting access to the channel doesn't accomplish anything useful. :)
I've got a working fix here, but what would you suggest instead?
I'm having some trouble getting the new phpunit tests to pass, but I think this is ready for review.
I am seeing these errors on a transaction that was ultimately successful - status and payment are OK. Just a slew of errors in the log for some reason.
benstallings → made their first commit to this issue’s fork.
benstallings → created an issue.
benstallings → created an issue. See original summary → .
benstallings → created an issue. See original summary → .
@meickol @sander wemagine Could you please review and test again now that I've rebased?
benstallings → made their first commit to this issue’s fork.
The problem I seem to be having with applying the patch from MR!8 is that the 3.x dev branch it builds on does not seem to be accessible with composer. Regardless of how I require it, I keep getting the 3.0.0 release, which is behind dev. Any tips?
#18 is out of date - that change is already in MR!8. See https://git.drupalcode.org/project/delete_all/-/merge_requests/8/diffs
@rcodina it looks like the current dev branch supports D11, so the status here should be Fixed. But yes, a release would be great!
I'm confused - MR !76 is showing 0 changes.
benstallings → made their first commit to this issue’s fork.
OK, if you're able to provide a patch or push to the MR, please do! thank you!
Taking @berdir's advice to heart, I've opened https://www.drupal.org/project/ultimate_cron/issues/3547668 📌 use short array syntax Active
OK so a lot of the phpcs complaints turn out to pertain to code that was included in the release but that is not actually functional yet. I wonder if it would be better to move that code into a branch and not include it in the release at all until it is functional.
benstallings → made their first commit to this issue’s fork.
Sure, but I'm puzzled that the test results at https://git.drupalcode.org/issue/saml_sp-3547318/-/pipelines/601659 don't show additional phpcs issues. What warnings and errors are you seeing?