🇷🇴Romania @claudiu.cristea

I'm looking to this

Can I get credit for that?

That's weird because I remember I have checked you (otherwise it would not be added to commit message)

Changed the branch to 4.x as we're always targeting the highest dev branch. Set to be backported

I have missed that. Closing as duplicate of 🐛 Random falling pipeline Active

> it happens on 3.0.x too

Yes, but normally we target the highest dev branch then we backport. I've set to be backported.

Merged in 3.0.x and 4.x. Thank you!

claudiu.cristea → created an issue.

Assigning for the 2nd round of review

claudiu.cristea → created an issue.

You can perform full synchronization using Drush.

Please, run drush rdf_sync:synchronize --help to find out how.

PS: We plan to introduce the same by UI, see ✨ Synchronization UI Active

No feedback. Closing

We cannot do anything else here. If you can give us more details, let us know

Anything else we can do here?

Moved patch from #2 to a MR

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

Now I can limit entity print only to a limited group of entity types. No more unneeded extra fields and a huge Git diff on config export. Code looks good. Apart from manual testing, I see it has solid test coverage.

@kovalevm you an pin the module to 3.0.1 or apply the patch from MR against 3.0.3.

There are some changes require in the MR and I'll quickly release 3.0.4 including this change as soon as they're fixed

Some changes are required. Please check the MR

Some changes are required. Please check the MR

Thank you!

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

Now it's possible to write an RdfSyncConnector plugin that would provide the connection to this type of backend.

This change only opens the door to implement Virtuoso authentication (Digest, OAuth, etc). It also introduce the concept of connector as plugins. That means, we can add more connectors (as new plugins) in the future (Fuseky, etc). Or any 3rd-party Drupal module can add their own connector plugins.

For authentication on Virtuoso there should be a new ticket but I don't see when I'll have time to work on that. Having this MR merged, it opens the door for community to implement it.

Could you, please, test also with 3.0.3?

Some of the tickets were approved & merged. 📌 Refactor private_message_thread_member_widget Active is still in progress, it seems

claudiu.cristea → created an issue.

Is this fixed now in 3.0.x?

Thank you all

Fixing credits an hiding patches.

Thank you!

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

Thank you

Thank you for review

Thank you!

Thank you!

Legit

Straight

Thank you!

Postponed to get more feedback from @loze

Marking as postponed, to get some feedback from @sagesolutions or other users

Resolved conflicts.

Also a nice refactoring.

Thanks!

Thanks!

Thanks!

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

Nice refactoring. Thank you.

I've only fixed myself a nit ad the tests are passing, so I think I'm able to RTBC

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

Tested manually with the scenario from #2 without this MR and I could replicate the bug. With the MR the error is gone.

Thank you for reporting & fix.

Reviewing. Tests were adde, label removed

Thank you for reporting and fixing.

Fixed in 📌 Automated Drupal 11 compatibility fixes for rdf_sync Needs review . Closing as duplicate.

No need for future updates

@jonathan1055, #6 works. Thank you!

@jonathan1055, @fjgarlin, than you!

You can probably fix this in multiple ways, either by repeating the customisation in 'next minor', or re-using the services from your 'current' job.

I don't think I understand how repeat the same service definition under OPT_IN_TEST_NEXT_MINOR

claudiu.cristea → created an issue.

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

Also EntityRepository::loadEntityByUuid() can be deprecated in favour of method that only needs the UUID, without the entity type argument

claudiu.cristea → created an issue. See original summary → .

While working on this I've opened 📌 Unify verb: ban/unban -> block/unblock Active as a followup.

Ready for review. Not that in some places, especially in tests, we're still using ::getAccountName() because that belongs to user selector widget and fixing that is not in the scope of this issue.

Indeed, currently the module exports permissions also for is_admin roles. But such roles have always all the permissions, so we should not pollute their configs with unneeded permissions.

Tested the MR and it works.

Thank you!

claudiu.cristea → created an issue. See original summary → .

Also it needs tests

I have changed the base branch of https://git.drupalcode.org/project/private_message/-/merge_requests/112 to 3.0.x. @zaryab_drupal, please move the patch to that MR so we can see the tests are passing

needs work because of PHPStan failure

Thank you

I have merged changes from 3.0.x branch. Now checks in pipeline are strict.

🐛 Fix test pipeline issues Active is merged

Addressed all remarks apart from one for which I've created a followup ( 🐛 Fatal error with email notification if user has no email address Active ).

claudiu.cristea → created an issue.

It seems that the MR is breaking the tests (or even JS functionality?)

@zaryab_drupal, I have just minor remark that would make the MR more simple

We need a test to prove that text from email is not HTML-encoded. Also, please use the MR, with patches there's no test run

Normally, you should achieve this by altering the plugin definition, using hook_field_formatter_info_alter(). But I hope BigIntItem will land in core at some point.

Thank you for contributing.

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

@cmlara, I do agree with “check permission “ over “check roles”. However, there are situations when you need to find out if the user is “god”. I came to this by trying to write an access policy → class and, while I wanted to pass the 2nd argument to CalculatedPermissionsItem constructor (which is “is admin”), I realized that the user account is missing this simple method.

Agree with #33

This is postponed on 🐛 Fix test pipeline issues Active

claudiu.cristea → created an issue.

Tagging

Tagging

Typo

Revived ✨ Add a new function to Drupal Core: user_is_admin Active . I think we need a shorthand to determine whether a user is an admin

Ready