Opened 3 years ago
Closed 3 years ago
#1530 closed Defect (wontfix)
Groups show irrelevant items
| Reported by: | webcubes | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Elgg 1.7 |
| Component: | Core | Version: | 1.7 |
| Severity: | minor | Keywords: | groups, entities, elgg_list_entities |
| Cc: | brettp | Difficulty: |
Description
We usually have requirements where we need to create clone of the groups plugin and enhance the features on this. We do it by copying the groups plugin, say 'community' and modifying the files in the new community plugin. We change all references to groups to community. We also change the language files as well.
But, we keep the entity type as 'groups' and we differentiate it by adding a subtype value called 'community'.
It works fine from the community view. Since we pass 'community' as the subtype to all queries, it fetches only the communities and behaves correctly.
But, when we go to the groups view and browse or search groups, it fetches all group entities irrespective on the subtype we use. So, the groups view will have groups, communities etc.
It will be a good idea to pass entity type="group" and subtype="group" in the group calls, so we can manage it. Currently, we pass ""(empty string) as the subtype value from the group pages.
Change History (6)
comment:1 Changed 3 years ago by thomas
comment:2 Changed 3 years ago by cash
This is that 1% use case I mentioned in #1499. I think it is reasonable that anyone who does this has to extend the search plugin to get the functionality that they want.
comment:3 Changed 3 years ago by webcubes
But,
it asks us to extend the groups searches. I makes more sense to me if adding more subtypes does not get listed with the groups pages.
Otherwise, what does the subtype for groups count?
comment:4 Changed 3 years ago by cash
@webcubes - you have to realize that the flip side is that people have plugins that create users with subtypes and the desired behavior is for all users to show when doing a search. Same with groups with subtypes.
There is no way to do both by default so we have to pick one.
comment:5 Changed 3 years ago by webcubes
@Cash,
I agree that people need all users lsted when they search for users. But, often people wish to have categorized list of users, say Free, Paid etc, not a comprehensive list.
So, I would recommend to use something similar to,
list_entities (type="group", subtype="group")
list_entities (type="group", subtype="xyz")
list_entities (type="user", subtype="user")
list_entities (type="user", subtype="xyz");
and we can have the function definition can be as
list_entities($type, $subtype=""){}. So, if some one need a comprehensive list of all groups or users, we can call the list_entities() with $subtype="".
I wish to get your feedback. Its my pleasure to communicate with you guys, the elgg experts.
comment:6 Changed 3 years ago by brettp
- Resolution set to wontfix
- Status changed from new to closed
This is something that can't be resolved to the satisfaction of everyone. I'm going to keep search as it is right now--pulling in all users and groups regardless of subtypes. If it becomes a problem for many users later on, we'll need to re-evaluate it.
@webcubes -- Look at the search plugin's README.txt file and the groups hook in search_hooks.php. What you'll need to do is unregister the group hook (use the new unregister_plugin_hook()) and register your own that doesn't ignore subtype. Also, make sure you register your new group type/subtype with register_entity_type() so it will be explicitly searched.

This belongs to #1499