Your cart is currently empty!
Import Groups (not users)
—
by
Greetings!
I find the combination of Groups and Groups Restrict Categories(procured today) a great win for our project. Many thanks.
We have a use case that is not solved by the add-on Groups Import/Export – we are a non-profit and we have several geographies that need to have their own ring fence (Groups). These are several hundreds in number and manually creating each is proving cumbersome.
Is there an alternate way you would recommend we attempt an import? We have a hierarchical group structure (Nation–>State–>City–>Ward) that is mapped to our NGO activities, i.e, we have a spreadsheet ready but even WordPress Importer or other import Plugins do NOT recognize the Groups (CPT) and hence we can not proceed.
Appreciate an early response, if possible, please.
Many thanks in advance.
Vy.
Posted in Groups
Comments
5 responses to “Import Groups (not users)”
Hey Vy,
I think so too. You can do a quick test on your site using three different posts and two users with the appropriate restrictions added using Groups plugin only.
Kind regards,
George
Hi Vy,
You’re welcome.
Perhaps I used a wrong expression here, when I refer to group parts this can be chunks of groups. The purpose is to import the groups, so each user record can have several groups. For example a dummy user that belongs to 100 groups. However, the groups alone won’t be enough because somehow you also need to map them to users. If your users exist in the installation, then you can update them with the supported option. If they don’t exist, then you can also import them. In any case though the import file should be properly structured for that purpose. More information on the import file are described in the documentation for Groups Import Export addon.
As for the hierarchy, I think that this is not necessary to add your groups hierarchically. A post, page or custom post type that is restricted to a group, is only accessible by its group members. Any other user has no access to it. Also, for posts that should be accessible by more than one groups, then you should use a third group to restrict it. The city content that should be accessible by different ward groups, should be restricted by another group. These different ward groups members should also be members of this third group.
For example
Blue Ward members have access to content restricted to Blue Ward group.
Red Ward members have access to content restricted to Red Ward group.
Blue Ward and Red Ward members should have access to New York city content.
For this to be possible, New York city content should be restricted to New York group.
Blue Ward members should also be members of New York Group.
Red Ward members should also be members of New York Group.
(the names used are for demonstration purposes only and you can use any name that fits)
Hope that my example covers the basics of your structure, but if further details are involved, please make sure to follow-up.
Kind regards,
George
Hello George,
Thank you for the suggestion. Your example is more simple and if it works as you have explained, it would serve our purpose.
With regards
Vy.
Greetings, George,
Great to get a detailed response from you. I shall take your suggestions to our team and we will probably take today to conclude on the path forward. “Dummy” users – will it mean we will have to delete them later on? I mean, in our use case, we have literally tens of hundreds of groups – and this will mean equal parts of “dummy” users i.e., one “dummy” user per group? This approach, while solving the problem, will introduce a new workload of having to delete the dummy users post the import? We will have to evaluate.
To your query on why “hierarchical” groups: we wish to have separation of access rights meaningfully at the smallest geographical unit for our org. In our case, “wards” – members of one should be kept out of accessing content from a peer ward. However, should they belong to the same city under which the ward is classified, then we wish to grant them access to “city” content. That’s the way the content architecture has been designed. However, a member of another city, should be restrained from accessing this city’s content. Finally, a national-level content is common to all our members and all have access. Should we open up in another country, then we intend to follow a similar hierarchy, but that’s ages away 🙂 Hopefully, we are not doing anything “sub-optimal” with this hierarchical grouping?
BTW, the TREE view in your plugin is a treat for the backend team – to get a visual view (and reduce errors) of groups created – since we have so many. Again, a nice touch by your devs!
I have a related query to the Groups Restricted Cat plugin – I shall ask it there.
With regards
Vy.
Hi Vy,
Welcome to our support forum and many thanks for your kind feedback. We highly appreciate it when users find our tools useful.
In general and even though importing only groups is not the main intention of Groups Import Export plugin, this is still possible.
The import process mainly includes the userdata and the groups that this user will be a member of. Also, there is an option to create those groups that don’t exist when importing.
Basically what you can do is split your groups list in parts and then create an import file. This import file can have one or more dummy users where each one should become a member in one of these group list parts you have previously created. The groups that don’t exist will be created and you will eventually import a few dummy users and all your groups. The structure of a compatible import file is described in the documentation for Groups Import Export plugin.
Also, you mention that your groups are hierarchically organised. Can you please share with us the purpose of this hierarchy? What is the reason why you have your groups set this way?
Kind regards,
George