andy inman → created an issue.
Just a note that we have expect to be releasing a module which will do this, or at least meet the same objective, I think. It's already "finished" and working for a specific client. It just needs a bit more work to generalise and polish, before publishing.
It takes a different (and more flexible) approach to what's discussed here, but if I'm understanding correctly what the need is in this ticket, then I think it will meet it.
andy inman → created an issue.
Retested with the latest (1.0.0-beta5), all ok now.
* It's no longer possible to paste a previously copied paragraph into a translation.
* Plegar means collapase, not paste - my mistake - that button is meant to be there.
* The yellow triangle warning shown for a collapsed paragraph means "You have unsaved changes on this Paragraph item" - seems wrong, as no changes were made, but it's not related to this module - still shown if the module is uninstalled.
andy inman → created an issue.
Ok, I've now found in the README:
Automated Testing Kit has a configuration page located at /admin/config/development/automated_testing_kit/edit (stub for now).
So that explains the error. Suggestion: remove the Drupal menu item completely - better than having it trigger an error page IMHO.
andy inman → created an issue.
@ yorchperaza
> seems like not is compatible with layout_paragraphs
Correct - I spoke/wrote too soon. But they're in the process of adding that as a submodule.
Now it exists: https://www.drupal.org/project/paragraphs_clipboard →
I'm hitting what seems to be the same issue, but when using the Responsive Grid rather than table format. Tried patch #65, no change. Should I log this is a separate issue?
A big negative for Lando: security weakness, because it makes your entire home directory accessible (read/write) to anything running in the Lando container.
https://github.com/lando/lando/issues/2635#issuecomment-860211387
This behaviour seems to have maybe changed in some recent version, for Linux: on my Ubuntu 22.04 machine, I see an empty /user directory, when testing:
<code>
lando ssh
ls -al /user
</code>
But under MacOS, the documented behaviour is present.
Patch #6 worked for me - the warning "Missing proxy class 'Drupal\book_tree_menu\ProxyClass\oscBookManager' for lazy service 'book.manager'" was previously appearing after every drush cr, it's gone after applying the patch.
Reporting another successful result with current dev-4.x and Drupal 10.1.2.
One detail: about configuration of entityID, we previously had:
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => NULL,
It seems the NULL/undefined option is no longer supported - to achieve the same result, I needed to change that to:
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => "https://{$_SERVER['HTTP_HOST']}:443/simplesaml/module.php/saml/sp/metadata.php/default-sp",
Looks like there's a failing test, likely needs updating to match new logic
Confirmed - access tests were checking edit-own and delete-own permission based on revision uid rather than entity uid. I've changed that. I've also added a couple of tests cases to check update and delete when user has the edit/delete-own permission but is not the owner.
Before marking as RTBC, I think it's worth at least considering the possibility that somebody out there may have an access control strategy that would be broken by these changes. That seems very unlikely to me, but I suppose it's not impossible. In the worst case, people could get edit/delete access to micro-content that they're not supposed to be able to change. There's no simple solution - I'm just suggesting a pause for thought - maybe wait for a bit more input from others.
Looks like there's a failing test, likely needs updating to match new logic
Confirmed - access tests were checking edit-own and delete-own permission based on revision uid rather than entity uid. I've changed that. I've also added a couple of tests cases to check update and delete when user has the edit/delete-own permission but is not the owner.
Before marking as RTBC, I think it's worth at least considering the possibility that somebody out there may have an access control strategy that would be broken by these changes. That seems very unlikely to me, but I suppose it's not impossible. In the worst case, people could get edit/delete access to micro-content that they're not supposed to be able to change. There's no simple solution - I'm just suggesting a pause for thought - maybe wait for a bit more import from others.
I have learned: don't right-click the Open MR button hoping to check the URL - that will trigger the button action.
Andy Inman → created an issue.
We're also seeing this error with Authorization - Group 8.x-1.0 when trying to add a group.
Possibly related modules installed:
- Drupal Roles Authorization 8.x-1.0-beta6
- LDAP Authorization Provider 8.x-4.3
- Group (group) 8.x-1.5
I need to investigate further, and will post more info when I have it.