I added post update hook to update job statuses to "finished". The criteria for the update - a job must have all job items accepted.
Added a merge request , and also posting the updated patch in case anyone needs it.
+1 to the above comment
FYI, the patch in #39 has lot more stuff than needed.
Attaching the new path which works with v1.5.0
@chris dart - what are other changes required and have you had a chance to create a ticket?
Scanning the module with rector reveals only one change needed, your comment is a bit confusing.
+1, considering just the version change in the info file.
The filters were added into https://www.drupal.org/project/helpfulness/issues/3518878 🐛 The report page crashes at 50k records Active
I have changed the ticket from the bug report to feature request. MR7 now contains full refactoring including filters. MR6 contains only report refactoring for performance.
I refactored the report page a bit:
- Added automated Pagination and Sort/Order support via PagerSelectExtender and TableSortExtender
- Added limit to display 25 records per page,
- refactored and cleaned up the code a bit.
This is ready for review and testing.
I am going to create another ticket for adding filtering support.
I am working on refactoring of the report page. It is a bit sub-optimal from the coding and usability perspective:
- Instead of looping trough results to convert each of them into an array, PDO::FETCH_ASSOC could be used to get results as arrays in the first place.
- from the usability perspective, unlikely anyone is interested too see hundreds results on a single page
- it needs a pager paging
- it needs filters - no way to only see results you need
- the results are split into two tables, where it should be one table with filters
- etc.
It is easier to refactor and get a good UI.
The project page needs updates:
- Looks like the API and Plugin information has to be dropped, as the module doesn't seem to provide any API and doesn't define custom plugin types,
- README.md should be updated for the same reasons.
This issue seems to be outdated: the module is already at 8.x-1.2
Should this be closed or refactored as the 2.x roadmap?
Closing as cannot longer reproduce on a clean D10 install. Other factors not directly related to the Scanner module might have played role.
Ok. This is a year old ticket, it was originally created against version 8.x-1.0-rc7 of the module. Back at time the issue was present.
Apparently version 2.x works as expected. 8.x-1.0 works as expected as well.
It could have been a combination of a few factors, but I can't replicate it now, at least not on a clean D10 setup.
Probably makes sense to close?
How are you triggering this issue?
Simply by searching the content. The output HTML is corrupt.
Ok. That should be simple.
I am not sure what the projects's technical plan is so don't know what the next step would be - keep supporting GeneratedURLs or drop the support?..
Firefox, Chrome, Edge... I believe it happens on desktop (or rather at the desktop zise) during initialization, after which the sidebar trigger is failing. It works on mobile (again screen size, not a device) and if you hide the taskbar on mobile screen size, it will be not possible to show it back on desktop screen size.
Not sure if this helps, but for me is throws an error in console and refuses to update related variable in the local browser storage:
Error:
`Uncaught TypeError: can't access property "innerHTML", sidebarTrigger.nextSibling is null
And the local storage variable that is not getting updates as the result of the above is Drupal.gin.sidebarExpanded.desktop
I added Merge request !11248, which is a rebase of the MR5758 on top of the 11.x branch. Fixed a few pipeline issues, but few other pipeline issues remain as I am not sure where the tests are failing or the tests need to be adjusted.
Also, I do not understand the changes entirely, so would be great if @ksenzee or @jurgenhaas could review the changes.
I am going to apply this changes against 10.4.x since this is where I need them. 10.4.x path is coming soon (should I have success)
euk → changed the visibility of the branch 3168966_cke-inline-media_rebased to hidden.
euk → changed the visibility of the branch 3168966_cke-inline-media_10.2.x to hidden.
euk → changed the visibility of the branch 3168966_cke-inline-media_10.2.x to active.
euk → changed the visibility of the branch 3168966_cke-inline-media_10.2.x to active.
euk → created an issue. See original summary → .
I want to add that Solr's default results limit is 10 items -- in my scenario, where I have Solr search and filter by taxonomy term - out of 600 nodes with about 20 terms used I only get 10 terms for the first 10 nodes returned.
Minor fix to the 1.3.x. patch.
A few more updates to the 10.3.x patch.
Adding updated patch for 10.3.x
While D10.3.x. merge fails (specifically - unit test, though it shows 100% success rate), here is the patch for D10.3.x - should work with 10.3.6 and up, till 10.3.10 at least.
euk → changed the visibility of the branch 606824-allow-admins-to to hidden.
@ramprassad, you bit me to it =) Though I am currently working on creating a D10 patch, and there are a few differences anyway. I looked at your PR and left a couple of comments. I also have a few suggestions:
- I do not recommend storing a default UID for this new cancellation method in the configs: developers then have to maintain this config, while most of the time admins probably want to reassign content to different users (based on my experience with medium to large sites), therefore making this default setting irrelevant and annoying.
- Added to the above - if the account matching the default UID has been disabled/deleted - you would have to update the config and also might have to deal with consequences of assigning content to deleted/disabled users.
- When reassigning content, you should account for editorial permissions - is the new user able to edit content? The simplest way to check that the content belonging to the account being deleted can be edited by the new users is to compare roles and make necessary adjustment to the account suggestions in the entity autocomplete.
- Same as above should be also considered for multiple accounts being deleted in bulk - here you'd want the new user have all the roles the deleted users had, or let the admins know what the consequences are if there are some mismatches.
- There should be a hook/event allowing to alter user selection - some modules like Workbench Access have their own content permissions model and need to be able to intervene.
I am including the above into my D10 patch. Hopefully will have it by EOD.
There is a module that attempts to solve this - https://www.drupal.org/project/user_delete_reassign → , but it was not updated for a long time, has a few bugs reported and doesn't work for me with the view bulk op out of the box. Another considerations to be made - this should work with Workbench Access and similar modules. For that there should be a hook/event and validation system which would allow to alter username suggestions or validate new owner content access rights.
+1 for this feature. Going to look at it.
Apologies! Use this file instead.
Here is the re-roll, however I haven't had a chance to test it yet
Looking at the code I wonder - why does ariaCheck() need a click event listener? It actually looks like it calls back this.closeMenu(), which calls ariaCheck() again creating an infinite loop?
Btw, ariaCheck() needs to be documented.
Same issue with BEF v6.0.6.
This will be always an issue if BEF is going to keep changing their create() and __construct() signatures all the time. Additionally, VeflTrait has a very obscure dependency on the Vefl service, which doesn't really exist in Vefl trait, but rather is expected to be added in the "treated" class.
The way to decouple from this is to provide Vefl service along with the trait, as a getter for example. There are a few traits in the core that use this approach, so we can call this an acceptable practice.
Another confusing thing is when an inherited member from a base class is overridden by a member inserted by a Trait, but this is a different story.
I am adding another merge request to help with the service dependency.
The DynamicMethodResolutionTrait trait performs mapping of form IDs to internal methods. Internal methods naming should be in the form of "formAlterFormId". E.g. for a form with ID "node_form" the matching method would need to be called "formAlterNodeForm". Specific form ID has a precedence over the base form ID, thus still allowing for targeted form alters. If there is a need to use a generic form alter callback that would cover all the form IDs supported by plugin the 'genericFormAlter' can be used.
An old ticked, but it is still relevant, and just recently caused me an issue. I spent a good chunk of time today figuring out what in the world has happened to a merge of a few filter.format.* config files. Turns out weights were merged somewhat incorrectly. Not sure what happened there, but while comparing those config files for ordering I found that it is really hard to see how the ordering has changed with just a diff tool. You really have to spawn a site, import configs and compare ordering of filters visually through the UI. With the weight values and without visual augmentation - go figure what is the order.
I am not sure why are we so hung up on using weights?
Assuming a machine name is used for keys and the config maps are sorted by config keys - why not implement a binary tree with the reference to left and right (top and bottom) children by their machine name. This seems to solve the ordering and doesn't require storing a numeric position which apparently changes constantly and is the root of all troubles.
- There is always a root at the top - has left, first child, pointer empty,
- Leaf items will always have their right, next child, pointer empty,
- The rest is self explanatory
Benefits:
- Each item is clearly marked where in the tree it is located.
- Splitting or inserting an item anywhere in the tree will only alter the adjacent items, not the whole tree
- Reordering items in the UI and saving the configs will not alter the structure, if the final ordering is kept the same
At least for flat structures like filter formats, fields without field groups etc - this should be really simple.
Merged into 1.x
Just tested it with paragraphs - the patch works.
The patch in #71 🐛 BaseFieldOverride fails to take into account ContentEntityInterface::bundleFieldDefinitions() when invoking onFieldDefinitionUpdate() Needs work still fails. This time with the following error:
Error: Call to a member function getSettings() on null in /var/www/web/core/lib/Drupal/Core/Field/FieldConfigBase.php on line 376 #0 /var/www/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(289): Drupal\Core\Field\FieldConfigBase->getSettings()
This happens on config import, and seems to be related to translations somehow (probably not the cause but one of the triggers for this issue), as the only update affecting the current build was enabling translation...
euk → created an issue.
Here is a patch that worked for me.
euk → created an issue.
Adding a patch with the correction from the previous comment
Not entirely sure where the problem stems from, but the latest patch has these lines (line#303 in the file after patching):
+ // Replace the **CORRELATED** placeholder with the outer field name.
+ if ($val === '**CORRELATED**') {
+ $quoted[$key] = $this->definition['outer field'];
+ }
It appears that the outer field definition is just a plain table name with column, and not a properly aliased reference. This essentially results in an error such as the column is not found. Example (see the line I singled out):
SELECT "section_association"."id" AS "id",
"users_field_data_section_association__user_id"."uid" AS "users_field_data_section_association__user_id_uid",
"node_field_data_users_field_data"."nid" AS "node_field_data_users_field_data_nid"
FROM section_association "section_association"
LEFT JOIN section_association__user_id "section_association__user_id"
ON section_association.id = section_association__user_id.entity_id AND section_association__user_id.deleted = '0'
INNER JOIN users_field_data "users_field_data_section_association__user_id" ON section_association__user_id.user_id_target_id = users_field_data_section_association__user_id.uid
INNER JOIN node_field_data "node_field_data_users_field_data" ON (SELECT "node_field_data_reps"."nid" AS "nid_reps"
FROM
node_field_data "node_field_data_reps"
LEFT JOIN users_field_data "users_field_data_node_field_data_reps" ON "node_field_data_reps".uid = "users_field_data_node_field_data_reps".uid
WHERE ("users_field_data_node_field_data_reps".uid = users_field_data.uid)
# ^^^, should be "node_field_data_users_field_data"."uid"
ORDER BY "node_field_data_reps"."changed" DESC
LIMIT 1 OFFSET 0) = node_field_data_users_field_data.nid
WHERE ("section_association"."access_scheme" IN ('section'))
AND ("users_field_data_section_association__user_id"."uid"
> '1')
In the code, replacing $quoted[$key] = $this->definition['outer field']; with $quoted[$key] = $this->relationship . "." . $this->definition['relationship field']; solves the issue.
Frankly I don't know if that is the proper way of generating the correct aliased reference, and am not sure if there are any implications to this approach. But it solves my issue.
It's been a while since I looked at that, but if we are to pull a thumbnail image - why not from the originally referenced media? with some option to choose what image style to use...
Don't want to bug anyone, but it would be good to get this reviewed at some point before the issue is closed due to inactivity...
Don't want to bug anyone, but a fix this simple should be reviewed at some point before the issue is closed due to inactivity...
I do feel like this page becomes too long to read - it appears to list almost all possible places one could add a library to. Shouldn't it be an explanation of the API only with maybe few examples? And particulars like how to attach a library to a form or a view or any other possible element - should be sort of self-explanatory: find the render element and attach the library conforming the API. In the end - developers should already be familiar with render arrays, where they come from, how to use them, etc.