Group: better membership requests list page

[coldtrick]

When viewing the membership requests for a group some things aren't very logical.

getting the entities from the database aren't limited to type => user, but in the listing every object is checked if it is a user???

In 1.7 limit => 9999
In trunk no limit => thus only 10 entities. Could be confusing: When a group owner accepts one request there still could be 10 users left.

I think it would be best to get the entities with the following criteria:
type => user
relationship => membership_request
relationship_guid => group_guid
inverse_relationship => true
limit => false

this would allow the view to not check for ElggUser

[brettp]

Confirmed the funky logic. This looks like old code. Interested in writing a patch for this?

[cash]

adding elgg_list_relationships() would solve this nicely and bring relationships in line with entities and annotation.

[coldtrick]

@cash:
+1 for the function, however since there are some actions required on the user this would not work entirely. As the listing of the users can't be influenced.

[cash]

I don't see a reason it wouldn't work. The listing would be ordered by date the date of the request and the view for the relationship would be the current view for approving requests.

[coldtrick]

@cash:
i didn't realize their is a view for a relationship. Is this the same as for annotations?? If so +many many more ;)

[cash]

Yes, I'm saying add a view for relationships. It could be relationship/<relationship name> or it could be relationship/<type>/<relationship name>/<type> where the types of the subject and object of the relationship are used.

[coldtrick]

Replying to cash:

Yes, I'm saying add a view for relationships. It could be relationship/<relationship name> or it could be relationship/<type>/<relationship name>/<type> where the types of the subject and object of the relationship are used.

I think the best would be relationship/<relationship name>. If someone wants a different output by (sub)type they can build it in the view.
Also this would be inline with annotations and type/subtype views

[cash]

Here is what we need to do:

1. In 1.8.x grab all requests (or add pagination) and fix odd logic
2. In 1.9.0 add elgg_list_relationships() and use that

[cash]

Refs #3296 displaying all group membership requests on one page

Changeset: 2f59afd29170066cb0d8ae19aa76ef2b7cb0b7db

[cash]

Add paging once we have elgg_list_relationships()

[cash]

Refs #3296 displaying all group membership requests on one page

Changeset: 2f59afd29170066cb0d8ae19aa76ef2b7cb0b7db