🇫🇷France @jvieille

Not that easy.
1) use hook_og_permission() to copy the core roles permissions that you need to grant in OG context.
example for VBO actions:

function yourmodule_og_permission() {
	$permissions = array();
	foreach (actions_permissions_permission() as $name => $details) {
		$permissions[$name] = array(
			'title' => $details['title'],
			'description' => isset($details['description']) ? $details['description'] : '',
			'default role' => array(OG_ADMINISTRATOR_ROLE),
			'module' => 'actions_permissions',
		);
	}

2) create a function that grants access in the context of the current og group
example if you only handle nodes

function yourmodule_og_user_access($string){
	$og_access = FALSE;
	if($context = og_context()){
		$group_type = 'node';
		$gid = $context['gid'];
		$og_access = og_user_access($group_type, $gid, $string, $account = NULL, $skip_alter = FALSE, $ignore_admin = FALSE);
	}
	return $og_access;
} 

3) Hack the original permissions module to add og access beside user_access()
Just look-up for user_access() and add og access hen appropriate.

Example for VBO actions in public function get_selected_operations() in views_bulk_operations_handler_field_operations.inc

$skip_permission_check = $operation->getAdminOption('skip_permission_check', FALSE);
+$operation_a = (array)$operation;
+$prefix = chr(0).'*'.chr(0);
+$string =  $operation_a[$prefix.'operationInfo']['label'];
+$og_access = yourmodule_og_user_access($string);
-if (!$operation->access($user) && !$skip_permission_check) {
+if (!$operation->access($user) and !$og_access && !$skip_permission_check) {
          continue;
        }
        $selected[$operation_id] = $operation;

This of course change from one module to another

Found it : hook_og_permission()

jvieille → created an issue.

I thought that UUID would be mandatory for effectively using Feeds to import / update content.
I am surprised it does not even support it.

It is php code in a views header

What is the purpose of this patch ?
I had to tweak the module tu include exposed_input in the key, is this related ?

Thanks

jvieille → created an issue.

jvieille → created an issue.

Thanks for the recommendation, but Drupal >D7 is way to difficult to handle for non-geeks...
We are using it as an efficient prototyping environment.

But the available actions work, the thing is that as soon as I put more than one VBO field, only the actions of the first show up.
I need the ability to process (same kind of) actions on different entities in the row according the chosen field (only one at a time).
The workaround is to create one display per field to process

jvieille → created an issue.

Summary of my experiment of ACE implementation in Drupal to apply ACE to a text field:
- Problem with Media Ckeditor, preventing triggering ACE in edit mode : I had to disable all CKeditor relate modules and back, resaving Ckeditor config.
- Syntax (and theme) is set at 4 places :
1) at admin/config/content/formats/ace_editor, Filter setting section
2) at admin/config/content/ace-editor
3) at admin/structure/types/manage/XXX/display
4) at the native ACE bottom bar available in edit mode

Syntax highlight works in view mode using the setting (3) : a given field always uses the same syntax, whatever is changed in edit mode
Syntax highlight works in edit mode using HTML only. No way to change that : the ACE native setting bar has no effect. This setting is ignored in view mode.

I found a solution regarding CKeditor embedded images
The module "Image form Word" creates and links a file when pasting an image - not only from Word!
https://www.drupal.org/project/image_from_word/issues/3384105 💬 Module name is misleading : it does much more - Thanks! Active

Remains the irrelevance of the specific Rules action.

jvieille → created an issue.

Images are coded by ckeditor this way
(the Base64 string)

The same image in Outlook by pasting the original ckeditor html in the message:

Same process in Gmail

Th problem with linking instead of embedding images doesn't work, and images are private

jvieille → created an issue. See original summary → .

I have the same issue
https://www.drupal.org/project/ace_editor/issues/3374828#comment-15151809 🐛 Does this module really work? Closed: duplicate
Have you found something to fix that?

Duplicate of https://www.drupal.org/project/ace_editor/issues/1425558 →

jvieille → created an issue.

This changes mixes up filters when aliases are longer than 60 (which happened to me!).
Reverted this change for the best.

What was the original issue?

I confirm this module does not work at all, even with patch #9
The same views display used in multiple groups shows the same content in all groups once the cache is set.
The module Views og cache behaves correctly

jvieille → created an issue.

I found the problem.
I am using memcache that I suspected to be the culprit. However, disabling Memcache did not solve the issue.
I then realized that disabling Memcache does not actually disable it.

What was missing in my setting.php this line:
$conf['memcache_key_prefix'] = 'something_unique';

jvieille → created an issue.

This did not work for me.
Here is my code:

function views_filters_selective_search_fields($haystack, &$return){
   foreach ($haystack as $k => $v) {
	 if(!isset($pk)){
		static $pk = '';
	}
	if(!isset($pv)){
		static $pv = '';
	}
    if (is_array($v)) {
		$pv = $v;
		$pk = $k; 
        views_filters_selective_search_fields($v, $return);
    } else {
        if($v === 'select'){
			$options = $pv['#options'];
			if(empty($options)){
				//$return[] = array($pk => $pv);
				$return[] = $pk;
			}
        }
      }
   }
}
function views_filters_selective_removeRecursive($haystack,$needle){
    if(is_array($haystack)) {
		if(isset($haystack[$needle])){
			unset($haystack[$needle]);
		}
        foreach ($haystack as $k=>$value) {
            $haystack[$k] = views_filters_selective_removeRecursive($value,$needle);
        }
    }
    return $haystack;
}



/**
 * Implements hook_form_views_exposed_form_alter().
 */
function views_filters_selective_form_views_exposed_form_alter(&$form, &$form_state, $form_id) {
 	views_filters_selective_search_fields($form, $return);
	$empty_filters = $return;
	if(is_array($empty_filters)){
		$new = $form;
		foreach ($empty_filters as $v){
			watchdog("v", print_r($v, true));
			$new = views_filters_selective_removeRecursive($new,$v);
		}
		$form = $new;
	}
}function views_filters_selective_search_fields($haystack, &$return){
   foreach ($haystack as $k => $v) {
	 if(!isset($pk)){
		static $pk = '';
	}
	if(!isset($pv)){
		static $pv = '';
	}
    if (is_array($v)) {
		$pv = $v;
		$pk = $k; 
        views_filters_selective_search_fields($v, $return);
    } else {
        if($v === 'select'){
			$options = $pv['#options'];
			if(empty($options)){
				//$return[] = array($pk => $pv);
				$return[] = $pk;
			}
        }
      }
   }
}
function views_filters_selective_removeRecursive($haystack,$needle){
    if(is_array($haystack)) {
		if(isset($haystack[$needle])){
			unset($haystack[$needle]);
		}
        foreach ($haystack as $k=>$value) {
            $haystack[$k] = views_filters_selective_removeRecursive($value,$needle);
        }
    }
    return $haystack;
}



/**
 * Implements hook_form_views_exposed_form_alter().
 */
function views_filters_selective_form_views_exposed_form_alter(&$form, &$form_state, $form_id) {
 	views_filters_selective_search_fields($form, $return);
	$empty_filters = $return;
	if(is_array($empty_filters)){
		$new = $form;
		foreach ($empty_filters as $v){
			watchdog("v", print_r($v, true));
			$new = views_filters_selective_removeRecursive($new,$v);
		}
		$form = $new;
	}
}

jvieille → created an issue.

Solved with the help of ChatGPT:

In Drupal 7 I added a checkbox field to the comment form in order to optionally send a notification when publishing a new comment using the Rules module. Unfortunately, my new field does not appear in the Rules data selector to condition the rule. Can you help please?
ChatGPT
In Drupal 7, the Rules module provides a powerful way to automate actions based on specific events. However, there are certain cases where custom fields may not be readily available in the Rules data selector. If you've added a checkbox field to the comment form and it's not appearing in the Rules data selector, you can follow these steps to make it accessible:

Install the Entity API module: The Entity API module provides additional integration between Drupal core and contributed modules, making it easier to work with entities and their fields. Make sure you have the Entity API module installed and enabled on your Drupal 7 site.

Configure the field settings: Go to the "Manage fields" settings for your comment entity type. In Drupal 7, comment fields are managed through the "Manage fields" tab on the "Structure" page. Check the field settings for your checkbox field and ensure that it's enabled for comments and has the appropriate display settings.

Update the comment entity type: In some cases, the comment entity type may not be properly updated to include the newly added field. To update the comment entity type, navigate to the "Structure" page and click on "Comment types." Edit the comment type you're using and save it without making any changes. This action will trigger the entity type update process.

Clear Drupal caches: After making changes to fields and entity types, it's important to clear Drupal caches to ensure that the changes take effect. Go to the "Performance" page (admin/config/development/performance) and click on the "Clear all caches" button.

Check the Rules data selector: Once you've completed the above steps, go back to your Rule and check the data selector again. The checkbox field should now be available for selection in the data selector.

By following these steps, you should be able to make your custom checkbox field accessible in the Rules data selector and condition your rule accordingly.

User
I don't find an entry "Comment types" in the Structure menu or page
ChatGPT
I apologize for the confusion. In Drupal 7, the Comment types configuration is not available as a separate menu entry in the Structure menu. Instead, comment types are managed through the content type configuration. Here's how you can update the comment entity type to include the newly added field:

Go to the "Structure" page: Navigate to the "Structure" menu in the Drupal administrative interface. It should be accessible through the top navigation bar.

Manage content types: On the Structure page, look for the "Content types" link and click on it. This page lists all the content types available on your site.

Edit the desired content type: Locate the content type associated with the comments you want to modify. Typically, it will be the "Article" content type or a custom content type if you have one. Click on the "Manage fields" link next to the content type to edit its fields.

Edit comment field settings: On the "Manage fields" page for the content type, find the field you added to the comment form (the checkbox field). Click on the "Edit" link next to the field to access its settings.

Ensure field is enabled for comments: In the field settings, make sure that the checkbox field is enabled for comments. Look for the "Enabled on" section and ensure that "Comment" is selected.

Save the field settings: After making any necessary adjustments to the field settings, click the "Save" or "Save field settings" button to apply the changes.

Clear Drupal caches: To ensure that the updated field settings take effect, clear the Drupal caches. You can do this by visiting the "Performance" page (admin/config/development/performance) and clicking on the "Clear all caches" button.

After completing these steps, the custom checkbox field should be available for selection in the Rules data selector, allowing you to condition your rule based on its value.

User
I finally made it, thanks for your help. To improve your experience, this is some additional information : I added the field pro grammatically using the form API : the Rules module was never able to discover such a field; you rightly recalled me that comments are fieldable in Drupal 7, this was a (much easier) solution. However, it was somewhat confusing to find the field in inside the list of all node fields.
ChatGPT
Thank you for providing additional information about how you added the field programmatically using the Form API. I'm glad to hear that you were able to resolve the issue by making comments fieldable.

When programmatically adding fields using the Form API in Drupal 7, the field might not be automatically recognized by the Rules module. This is because the Rules module relies on the entity and field information defined in Drupal's Field API.

Since comments in Drupal 7 are fieldable entities, it's possible to add fields to them using the Field API, just like you would with other entities such as nodes. However, as you mentioned, finding the custom field within the list of all node fields can be confusing.

To clarify, when comments are made fieldable, they share the underlying field storage and field management system with nodes and other entities. This means that when you add a field to the comment entity type, it will be displayed within the list of fields associated with all entity types (including nodes) on the "Manage fields" page for the respective content type.

While this approach can be somewhat confusing, it allows for a unified field management system across different entity types. It's important to ensure that the field is properly enabled for comments (as mentioned in the previous response) to ensure it functions correctly within the context of comments.

I appreciate your feedback, and I'll make a note of this particular aspect to enhance the guidance in similar scenarios in the future. If you have any further questions or need additional assistance, please don't hesitate to ask.

jvieille → created an issue.

I am surprise that this issue was never seriously addressed.
My field_collection_item contains 16579 records, with 15562 orphans among them - somewhat 94% garbage
#22 provides useful information to develop a cleanup function.

As I was puzzled by the SQL query, I asked ChatGPT to get me on :

Can you explain this sql query : SELECT item_id
FROM field_collection_item field_collection_item
LEFT JOIN field_data_field_srelation field_data_field_srelation ON field_collection_item.item_id = field_data_field_srelation.field_srelation_value
LEFT JOIN node field_srelation_field_collection_item ON field_data_field_srelation.entity_id = field_srelation_field_collection_item.nid
WHERE (( (field_srelation_field_collection_item.nid IS NULL ) ))
ChatGPT
This SQL query is selecting the item_id column from the field_collection_item table, but with certain conditions specified using LEFT JOIN statements and a WHERE clause. Here's a breakdown of each part of the query:

SELECT item_id: This part of the query specifies which column(s) to select from the table(s) being queried. In this case, we're selecting the item_id column from the field_collection_item table.

FROM field_collection_item field_collection_item: This part of the query specifies the table(s) to query from. In this case, we're querying from the field_collection_item table. The second field_collection_item after the FROM keyword is an alias for the field_collection_item table, which allows us to refer to this table more easily in subsequent parts of the query.

LEFT JOIN field_data_field_srelation field_data_field_srelation ON field_collection_item.item_id = field_data_field_srelation.field_srelation_value: This is a LEFT JOIN statement that specifies how to join the field_collection_item table to the field_data_field_srelation table. The ON keyword specifies the condition that must be met for a row in the field_data_field_srelation table to be joined with a row in the field_collection_item table. In this case, we're joining on the condition that the item_id column in field_collection_item is equal to the field_srelation_value column in field_data_field_srelation.

LEFT JOIN node field_srelation_field_collection_item ON field_data_field_srelation.entity_id = field_srelation_field_collection_item.nid: This is another LEFT JOIN statement that specifies how to join the field_data_field_srelation table to the node table. The ON keyword specifies the condition that must be met for a row in the node table to be joined with a row in the field_data_field_srelation table. In this case, we're joining on the condition that the entity_id column in field_data_field_srelation is equal to the nid column in field_srelation_field_collection_item.

WHERE (( (field_srelation_field_collection_item.nid IS NULL ) )): This part of the query specifies the condition(s) that rows must meet to be included in the query results. In this case, we're only including rows where the nid column in field_srelation_field_collection_item is NULL. This essentially means that we're only selecting rows from the field_collection_item table that do not have a matching row in the node table via the field_data_field_srelation table.

To summarize, this SQL query selects the item_id column from the field_collection_item table, but only for rows that do not have a matching row in the node table via the field_data_field_srelation table.

User
why does this request correctly returns non matching rows via another table, say field_data_field_srelation?
ChatGPT
This query returns non-matching rows via the field_data_field_srelation table because it is using a LEFT JOIN statement to join the field_collection_item table with the field_data_field_srelation table. A LEFT JOIN returns all rows from the left table (field_collection_item) and only the matching rows from the right table (field_data_field_srelation), with NULL values for the columns of the right table where there is no match.

By using a LEFT JOIN rather than an INNER JOIN, this query ensures that all rows from the field_collection_item table are included in the results, even if there is no matching row in the field_data_field_srelation table. This means that the query can return rows from the field_collection_item table that don't have a matching row in the node table via the field_data_field_srelation table, which is what we want in this case.

The WHERE clause of the query specifies that we're only interested in rows where the nid column in field_srelation_field_collection_item is NULL, which essentially means that we're only selecting rows from the field_collection_item table that don't have a matching row in the node table via the field_data_field_srelation table. This allows us to filter out any rows that do have a matching row in the node table, and only return the non-matching rows that we're interested in.

User
Sorry, I mistaken the question, this is the correct one : why does this request correctly returns non matching rows via another table, say field_data_field_brelation?
ChatGPT
The reason this query correctly returns non-matching rows via the field_data_field_brelation table is because it uses a LEFT JOIN to join the field_collection_item table with the field_data_field_brelation table.

A LEFT JOIN returns all rows from the left table (field_collection_item) and only the matching rows from the right table (field_data_field_brelation), with NULL values for the columns of the right table where there is no match.

In this query, the condition for joining the tables is that field_collection_item.item_id is equal to field_data_field_brelation.field_brelation_value. This means that for each row in the field_collection_item table, the query tries to find a matching row in the field_data_field_brelation table based on the value in the field_brelation_value column.

However, since we are using a LEFT JOIN, all rows from the field_collection_item table are included in the results, even if there is no matching row in the field_data_field_brelation table. In cases where there is no matching row in the field_data_field_brelation table, the columns from that table will have NULL values in the result set.

The WHERE clause filters the result set to only include rows where field_srelation_field_collection_item.nid is NULL, which means that there is no matching row in the node table via the field_data_field_brelation table. By doing this, the query only returns the non-matching rows from the field_collection_item table that we're interested in.

In summary, this query correctly returns non-matching rows via the field_data_field_brelation table because it uses a LEFT JOIN to include all rows from the field_collection_item table, and then filters the results to only include the non-matching rows based on the condition in the WHERE clause.

User
But the query only joins field_data_field_srelation, not field_data_field_brelation
ChatGPT
I apologize for my mistake in my previous response. Since the query only involves a join between the field_collection_item table and the field_data_field_srelation table, my previous explanation does not apply.

The reason the query correctly returns non-matching rows is due to the use of a LEFT JOIN. Specifically, the LEFT JOIN is used to join the field_collection_item table with the field_data_field_srelation table, which includes all rows from the field_collection_item table regardless of whether there is a match in the field_data_field_srelation table or not.

In the query, the condition for joining the tables is that field_collection_item.item_id is equal to field_data_field_srelation.field_srelation_value. This means that for each row in the field_collection_item table, the query tries to find a matching row in the field_data_field_srelation table based on the value in the field_srelation_value column.

However, since we are using a LEFT JOIN, all rows from the field_collection_item table are included in the results, even if there is no matching row in the field_data_field_srelation table. In cases where there is no matching row in the field_data_field_srelation table, the columns from that table will have NULL values in the result set.

The WHERE clause filters the result set to only include rows where field_srelation_field_collection_item.nid is NULL, which means that there is no matching row in the node table via the field_data_field_srelation table. By doing this, the query only returns the non-matching rows from the field_collection_item table that we're interested in.

In summary, the query correctly returns non-matching rows via the field_data_field_srelation table because it uses a LEFT JOIN to include all rows from the field_collection_item table, and then filters the results to only include the non-matching rows based on the condition in the WHERE clause.

User
OK, I reformulate: why this query is supposed to returns all non-matching rows in field_collection_item in the node table via an intermediate table. there are 5 of these tables, and I get all non matching rows whatever intermediate table is involved. This is the query with field_data_field_srelation, which gives the same result with in the node table via the field_data_field_brelation:
ChatGPT
Based on the query you provided earlier, it looks like the purpose of the query is to find rows in the field_collection_item table that do not have a corresponding entry in the node table via an intermediate table (field_data_field_srelation or field_data_field_brelation).

The query achieves this by using a LEFT JOIN to join the field_collection_item table with the intermediate table, and then another LEFT JOIN to join the intermediate table with the node table. The WHERE clause then filters the results to only include rows where there is no matching entry in the node table.

The reason this query returns all non-matching rows in the field_collection_item table, regardless of which intermediate table is involved, is because of the use of LEFT JOIN statements.

A LEFT JOIN returns all rows from the left table (field_collection_item in this case) and only the matching rows from the right table (field_data_field_srelation or field_data_field_brelation), with NULL values for the columns of the right table where there is no match.

So when you use a LEFT JOIN to join the field_collection_item table with any of the intermediate tables (field_data_field_srelation, field_data_field_brelation, etc.), all rows from the field_collection_item table are included in the result set, even if there is no matching row in the intermediate table.

Then, when you use another LEFT JOIN to join the intermediate table with the node table, all rows from the intermediate table are included in the result set, even if there is no matching row in the node table.

Finally, the WHERE clause filters the results to only include rows where field_srelation_field_collection_item.nid (or the equivalent column from the other intermediate tables) is NULL, which means that there is no matching row in the node table.

Therefore, the query returns all non-matching rows in the field_collection_item table, regardless of which intermediate table is involved, because of the use of LEFT JOIN statements and the WHERE clause that filters the results to only include non-matching rows.

User
Can this request wrongly report matching rows through another intermediate table ?
ChatGPT
It is possible for the query to incorrectly report matching rows through another intermediate table if there are duplicates or inconsistencies in the data.

For example, if there are two or more entries in the intermediate table (field_data_field_srelation or field_data_field_brelation) with the same field_srelation_value or field_brelation_value value, but with different entity_id values, the query could potentially match to the wrong entry in the node table, or match to multiple entries in the node table, resulting in incorrect results.

Similarly, if there are inconsistencies or errors in the data, such as missing or incorrect values in the intermediate table or the node table, the query could potentially match to the wrong entry in the node table or miss a valid match altogether, resulting in incorrect results.

Therefore, it is important to carefully examine the data and the relationships between the tables to ensure that the query is providing accurate results. It may also be helpful to perform additional checks or validations to confirm the accuracy of the results.

jvieille → created an issue.

I have the same question/need

jvieille → created an issue.

jvieille → created an issue.

I understand that there is still an ongoing issue that prevents VBO to properly handle individual fields within a field collection field.
One way is to base the views from the host entity rather than the field collection table. However, this does not permit to edit a single field, the whole field collection is regenerated, which is basically useless.

https://www.drupal.org/project/field_collection/issues/1571622#comment-1... → says basically that and mentions https://www.drupal.org/project/field_collection/issues/2658882 → , which was solved since but not avail.

jvieille → created an issue.