gizra/og

https://www.drupal.org/project/og

og's Issues

Removed field og_group_ref but content type still shows as Group Content

I have removed og_group_ref but content still shows as Group Content. It shows checked on the content type's edit tab > Organic Groups (Group Content is remains checked). Also when I go to Configuration > Organic Groups > OG Permissions overview all of the fields for this content type show up here (I have OG Field Access enabled). This is problematic.

I have cleared cache multiple times. Is there a DB field I can just set to disassociate this?

I am using 7.x-2.7

Status

Hi,

Could you add a section to the README or maybe keep this issue updated with what the status is for d8? Can we use it yet? Can we help you out in any way? I looked at the d.o page for og but there's no mention of D8 either.

Regards,

Alexander

Development roadmap for OG 8.x

Following on from a brief exchange with @amitaibu on Twitter.

Rational

Porting over a module such as OG to Drupal 8 is a large, time consuming task. The current guesstimate is around 100 developer days of work.

Proposal

I'd like to propose that we come up with a development roadmap to bring the code to a stable 8.x-1.0 release.

I feel it would be beneficial to break the development of OG down into bite-sized milestones as it would likely encourage companies to sponsor at least some of the milestones in order to have the module stable for when Drupal 8 is released.

Ideas

Rather than a fully featured Drupal 8 port of the Drupal 7 version, could a minimal viable product be a better target for the initial 8.x-1.0 release? Subsequent minor versions could then add these additional features (such as integration with other modules, etc)?

This could help get a minimal functioning version to the community earlier and spur on other developers / companies to add some of the missing features they need.

Next Steps

1. Draft an initial roadmap - this will require someone with a good knowledge of the OG architecture.
2. Assign a very approximate number of developer days needed to complete each of the milestones.
3. Find sponsors and developers willing to offer time / money.

Thoughts?

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'og_membership.field_og_ref_target_id' in 'on clause'

Details here: https://www.drupal.org/node/1890370
Patch here: https://www.drupal.org/files/issues/add-gid-to-relationship-field-1890370-34.patch

Code guideline

OG have a lot of og_ function that can move into the controller as static methods. For example OG::IsGroup() OG:IsGroupContent(). This also should effect the access part of OG(not og_access).

Any other thoughts?

Provide snippet to check the API on OG8

@RoySegall

Node context negotiation fails

Problem / Motivation

Issue #28 and commit 66d3b72 causes Node context negotiation to fail due to comparison between menu router path (pattern) and path instance:

        if (strpos(current_path(), $path) === 0) {

For nodes this result in comparison between e.g. node/1107 and node/%.

Proposed resolution

One of:

1. Revert
2. As explained in #28, the call to menu_get_item() may result in a new/nested call to og_context() due to menu router item object loading and translation. But one cannot compare a menu item path with a live path due to the above comparison failure, so you have to retrieve the menu router item from the current live path somehow. One solution is to implement a truncated version of menu_get_item() that halts processing the router item before item translation and object loading. It's only used to compare string. Leave it to the negotiation implementations to further check access control.

Option to hide 'pending' membership status

For non-self-signup groups, the 'pending' membership status is not needed and confuses users.
Currently there is no clean way to remove.

Proposed resolution

a) A configuration option per group
b) Simple magick that checks that no group role has the right to join

My gut feeling is b) (with an olter hook) should be fine.

node:og-group-ref:0:url:relative token stopped working

It seems this token has stopped working. node:og-group-ref:0:url still exists, but it doesn't take into account a manually-set alias.

As an example, we have a "Human Resources" group that is located at mysite.com/hr

Before using the token above would generate URLs like mysite.com/hr/mypage - which is the desired effect.

Now the same token is generating mysite.com/human-resources/mypage

Essentially, its not respecting the URL alias of the parent node.

Test seems false negative for og_field_access

This is related to the Drupal.org issue 1950894. I have proposed patch that I believe should pass without issues but surprisingly I got stuck by an unusual Test case. The test is granting the user permission to edit the field, and stating that shouldn't be able to edit the field.

The patch I'd like to review is:
https://www.drupal.org/files/issues/og_user_access_entity-1950894-38.patch

Test case to review:
https://qa.drupal.org/pifr/test/1046753

The later patch was for thought to further check if user needs to have another permission but that other patch (with more code) is failing too.

Migrate warnings

Please commit https://www.drupal.org/node/2151015

OgMembership::save() does not update entity audience field

To set context, I have a module that generates a node from an incoming email and associates it with a group based on the email address that it came in on. The flow looks something like this:

//(email arrives, and triggers drupal)
// Prepare node, populate fields
node_save($node);
foreach ($group_nodes as $gid => $group_node) {
  og_group('node', $gid, array('entity_type' => 'node', 'entity' => $node);
}
// At this point, $node->og_group_ref should be populated, but it is not.

(FYI, this is a modification I'm making to the og_mailinglist module).

In the og_group() source code, it specifically mentions that OgMembership::save() should update the entity in question.

My current solution is this:

    $entity_wrapper = entity_metadata_wrapper($entity_type, $entity);
    $items = $entity_wrapper->{$field_name}->value();
    $items[] = $group;
    $entity_wrapper->{$field_name}->set($items);

In OgMembership::save() after parent::save(). (Sorry, no patch at the moment).

og_access_handle_group_privacy_change() causing EntityMetadataWrapperException when editing group node

It's checking OG_ACCESS_FIELD (group_access) which is not defined on the group node content type. The content type was created running og-7.x-2.7, so this may be a backwards-compatibility problem.

"your groups" and "other groups" within admin OG audience field do not respect cardinality of 1.

Scenario:
My content type contains an OG group reference field with cardinality limited to 1 so that content can only be associated with a single group.
A groups administrator sees a more complex field for OG audience that has two parts: "your groups" and "other groups" (either auto-complete or select).
When an administrator selects a value in one of the two fields but doesn't manually remove the value from the other field and saves the node, the following error is generated:

OgException: OG membership can not be created in entity node and bundle freeform using the field og_group_ref as the field cardinality is set to 1. in OgMembership->save() (line 69 of /sites/all/modules/contrib/og/includes/og.membership.inc).

Ideally, there would be form validation that prevents the node form from being submitted when cardinality is 1 and more than one value for group audience is selected. It would be even better if (with cardinality 1) after selecting a value for "other groups" that "your groups" was set with JS to "none" (and the reverse).

og_users_roles migration is broken

I have tons of this error and ~90% of the items are not migrated:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-10-1' for key 'PRIMARY': INSERT INTO {og_users_roles} (uid, rid, gid, group_type) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => 10 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => node ) (\includes\common.inc:7316)

https://www.drupal.org/node/2151015

https://www.drupal.org/node/2574071

FieldValidationException: error when saving entity og reference fields

Details here: https://www.drupal.org/node/2249261
Patch here: https://www.drupal.org/files/issues/entityreference_fields_do_not_validate-2249261-10.patch

OgMigrateOgur has very many unprocessed items

I fear something goes wrong with this migration, but what does it mean if 90% of the items are UNPROCESSED?

Do not load menu item just before determining context handler to prevent premature access denial due to empty og context.

Issue in og_context.module, function og_context_determine_context().

When determining the context, don't by default load the menu item and just test on current path. Because if during the custom menu access check og_context is called (as can be the case in a views access plugin or ctools access plugin where og_context would be called), then the statically cached initialized context will seem empty.
Solution is not loading the menu item before determining the context, thus preventing a custom access being executed which could in turn execute og_context() to establish a context, resulting in denial of access as the context is initialized alrready, but empty.

Group's content privacy doesn't change when group privacy is changed.

When we change the group access permissions and even if in settings "Update group content privacy" is checked - group content access permissions don't change.

No Query is Run in View When Using Group ID Contextual Filter for User with Multiple Group Memberships

Since 7.37 core update, if you have a view using the "OG Membership: Group ID" Contextual Filter set to provide "the OG groups of the logged in user" as a default when a filter is not provided, and "OG group" validation is enabled along with "Allow multiple values", the query will not run for a user with multiple group memberships when no filter is provided, due to argument validation failing in og_plugin_argument_validate_group.inc.

This is due to the contract of entity_load being more strictly enforced starting in 7.37, in response to this issue, https://www.drupal.org/node/1003788. The condition placed on the $ids parameter is

"An array of entity IDs, or FALSE to load all entities."

The validate_argument function in og_plugin_argument_validate_group.inc calls entity_load_single with the string of concatenated gids that Views supports, ie. "1+2+3". entity_load now tries to validate that this is numeric which fails, so no entities are returned, argument validation fails, and the query does not run.

I will be submitting a pull request with a proposed fix.

of_field_access makes OgMigrateMembership fail

Problem/Motivation

During a migration of OG Memberships from 7.x-1.x to 7.x-2.x, the process tries to determine whether the user has access to all potential group audience fields. That calls the og_field_access_field_access() function which calls og_user_access_entity() which tries to load all the groups related to the given entity. The problem is that most of these groups are not fully migrated yet so their group_type is empty so when OG tries to create an entity_metadata_wrapper('', $gid), an Exception is fired.

Proposed resolution

Use the last og_get_best_group_audience_field() parameter to avoid that field_access test during the migration process.

rules acting on new membership that do user_save() erase the membership

Example - an og_role_grant rule on a new membership that grants a Drupal user role to the account. The user role action saves the account. The og_user_node field value does not include the new membership, so it gets deleted.

non-required group audience field failing validation when group admin edits group node

We have a content type that can be a group and sometimes group content as well. (eg node 123, "My Group", is itself an OG group node, and belongs to the OG group 456, "My SuperGroup") most nodes are only group nodes, and are not members of any other group. the og_group_ref group audience field is not required.

however, group admins - people who are members of the group with the "administrator member" group role - are unable to save changes to the group node, even though they have the OG permissions "Edit group" and "Administer group", because when they don't choose an existing group in the group audience field (either leaving it altogether blank, or selecting "- None -"), they get the error, "You must select one or more groups for this content."

users who have Drupal role based edit permission on the content type do not get this error. giving the group admins explicit OG permissions on the og_group_ref field makes no difference.

there are other issues related to this validation error in the Drupal issue queue, but they all boil down to different problems, from what i can see.

Entity access for groups and group content

OG supply basic permission(og_access extends it). For now the permission is a content entity. But this could be a config entity since we want to export permission for roles.

This a discussion we can do here but will provide solution via code.

Groups as Entities?

I realize this is a late in the game ask/question, but is there any good reason for groups being nodes with specific fields attached, instead of a custom entity type? I would think it would ultimately make them a lot more manageable.

[D8] Create a proper entity reference widget.

@damiankloip I looked in your repo that you started to do some work over there. I'll see if this can be merged in.

Default OG Group link not in menu

After the upgrade from D6 to D7 I no longer have "/og" link named "Groups". Why is this one missing? Can you fix this bug, please?

New users can select arbitrary groups on login

In admin/config/people/accounts/fields/og_user_node, I haven't set it as a mandatory field, and I also haven't set it to display in the account registration. Still, when a new user registers, he can select any group to become a member of.

Possibly related: When I save the above mentioned field settings form, I get the following error: FieldValidationException: Fehler bei der Eingabeüberprüfung des Feldes in OgBehaviorHandler->validate() (Zeile 295 von /home/orpheusv/public_html/sites/all/modules/og/plugins/entityreference/behavior/OgBehaviorHandler.class.php)

This is independent of what I actually edit in the form.

Move back to d.o, please!

You destroy the Drupal community otherwise.

https://www.drupal.org/node/2574209

Incoherent access rights in og_register on User registration form

Using D7.39 and OG7.27
Here's my use case. I am building a system with groups and subgroups using the og_subgroups module. I have a user "ricardo" who is a Member of a Level 1 group, and Admin Member of a Level 2 group.
I want Ricardo to be able to create new users (not just add them to the group but actually register a new user), while at the same time adding them to the Level 2 group of which he is a member (instead of having first to create the user and then add the user to the group).
I have proceeded as follows:

1. Enable the og_register module
2. Add the Group Register field to both Level 1 and Level 2 Group content types
3. Add the Group Membership field to the User Entity. When I did nothing more than this, to my surprise I found that the User registration form displayed a choice of Groups to Anonymous and to Super-admin, but not to Ricardo despite him being Admin member of his group.
4. The only way to get the Group list to show up (without giving Ricardo the OG Admin full rights) was to check the "Allow entity access to control field access" option in the Group Membership field.
   This works, but... the User registration form displays all the groups of which Ricardo is a Member, including the Level 1 group where he does not have permissions to add new users. And if you select the Level 1 group in the list, the new user gets added there without any problems, which is clearly a security issue

Problem in five Star Rating module for anonymous user

Migrate all drupal.org issues into this queue

You said you'd like to maintain the project here, so let's move on and move all issues to get them solved.

EFQ support

OG audience field(AKA og_group_ref) field is empty but the values is kept in the og membership entity. In drupal 7 we had entity field query alter hook that do for us the work. This is a also something we need to import.

ajax submit button breaks entity prepopulate of group admin audience field "other groups"

To recreate:

1. log in as an admin with "administer groups" permission
2. in a group where the logged in user is not a member, create new content using a required group audience field with entity prepopulate via the URL.
3. Despite not being a member, the group appears in the 'default' field as part of the combo audience field for group administrators.
4. Click 'upload' on a file/image field within the group content node form. The default field will still show the prepopulated group in 'your groups'. (If no ajax submit buttons are clicked, saving works.)
5. Attempt to save.
6. Your groups is cleared, and the node form throws the following error: "An illegal choice has been detected. Please contact the site administrator." - from line 1388 in includes/form.inc - because the value of the prepopulated group is no long in the options for 'your groups'.
7. This error is compounded because after the error, it's no longer possible to select the prepopulated group in EITHER 'your groups' or 'other groups'. If selected in 'other groups', the referenced group throws "The referenced group (@type: @id) is invalid." from OgBehaviorHandler.class.php because the prepopulated value is not listed in the results from entityreference_get_selection_handler() any longer.

Note that I tried this with the admin part of the audience field as both an autocomplete and as a select field. I also tested this with the latest dev version of entityreference_prepopulate that contained a patch for a different ajax error. (http://cgit.drupalcode.org/entityreference_prepopulate/commit/?id=41ed253) The error was present in all cases.

OgRole, OgRolePermission, OgUsersRole shouldn't be entities

While I don't think there's a clear definition of when entity vs a "simple" DB record, I believe the above shouldn't be entities.

@RoySegall do you see any problem with this?

/cc @damiankloip

How to prevent group manager from deleting own group

This is a follow up issue.

I am confused regarding amitaibu's comment here. Why do we need auto assign role in this case, are you telling about this module autoassignrole, sorry if I am not understanding something straightforward.

Apart from the confusion, my suggestion is we use the patch here.

P.S. See my comment in drupal's module issue #66

Test import

The test can be import using the drupal module importer that webchick showed in DrupalCon Amsterdam. Since i moved the tests we need to do that on another og file and then move them back to this repo.

After we got the alpha release blocker removed we can develop using the TDD methodology.

Widget to share existing content in group

This is a Feature request

There should be some kind of widget that will appear in node pages. The widget will be like a shortcut to post the node in a group. Currently, you have to go to node edit page and select group where you want to post the content.

The widget will only appear if the user is member of some group.

P.S. I liked the drupal issue queue, you can add tags, etc.

Implement automated test bot for patches in issues queue

As I know Github has no testbot like Drupal.org has. Committing patches without a test run and tests is not good and will cause regressions.

Implement a testbot to make sure no regressions happen and patches are automatically run when posted, but before they will be committed.

Do not hardcode pluggable_node_access field name.

group audience stopped working

Hello,
We are unable to use OG - group audience. It stopped working around the time we installed/enabled the blog modual. When creating a new contnet (document, blog, page. ect. ) the option for group audience shows "none". What could couse this. At one time the blog content type did work and the other did not. At that time I compared the blog content type with the others and all the settings looked the same. We sent a message witht eh System Admin to look at the logs of the server and no errors were wound.
We are gettting the following errors in the Drupal Recent log messages report:
Undefined index: membership_type in og_entity_property_info() (line 236 of /var/www/html/drupal7/sites/all/modules/og/og.module.

Any help would be greatly appreciated,
Thank you,
Abe

OG entity reference fields

Can I ask why something like DER isn't used in OG as a subtitute for the etid/entity_type base fields?

renaming a table on install in hook_schema og_access.install

Why is this table being renamed?

This is causing a PDO exception under some circumstance. I haven't tested a full reproduction, but it seems if og_access is enabled/disabled/enabled/disabled/uninstalled/enabled while field for group access are still attached to the group then this can happen.

It seems like this is for upgrades from d6 to d7, shouldn't this be in an update hook then?

og_role_grant() if role is already granted and user is not member

this provoqu

Integrity constraint violation: 1062 Duplicate entry '694-3-4' for key 'PRIMARY'

suggested fix in og_role_grant :

// Get the existing user roles.
$user_roles = og_get_user_roles($group_type, $gid, $uid, TRUE, FALSE);

thanks

create group content: how to block anonymous user but allow authenticated non-members?

Content type MyType has no Drupal role permissions granted on it at all. It's set up to be used as OG group content. The default (site-wide) OG permission "Create MyType content" is set for non-members and members.

The result is that anonymous users as well as authenticated non-members are able to create MyType nodes if they prepopulate the group audience to a valid group.

I think that this is all theoretically correct behavior. Checking different settings of the OG edit permissions seems to confirm that OG permissions override Drupal role-based permissions.

So my question is, how do I exclude anonymous while still allowing logged-in users? To OG, they're all just non-members.

OG audience filed population

The OG audience field(AKA og_group_ref) is a special field. It's a field that populated like all the other fields. Every time there is a change in the field we need to remove/update/insert og membership entity.

This split into:

• When populating the field programatically.
• When editing an entity from the UI we need to create manually the form elements.

Passing an empty first parameter to a migration constructor is now deprecated - pass through the arguments array passed to the leaf class instead.

Will be shown to me at admin/content/migrate/groups/default/OgMigrateOgur/edit and many other places.

What does this mean and how can this fixed?