User relationship integration
| Project: | User Import |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | feature request |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
This module http://drupal.org/project/user_relationships is the most popular of it's type. I would really like to be able to assign importees to an arbitrary relationship. I can then use this relationship to reveal certain content to the importer only. I don't think OG can do this, not without introducing over complex processes.
I'm trying to make an address book. With this module a user can import, create and invite users however if I include address details and telephone numbers there needs to be a method by which third parties cannot view this information. I can make the content private but there is no tag associated with the import to be able to call into a view based on an agreed relationship.
I'm trying to make this work http://drupal.org/node/545820, which will mean for those contacts I import I will be able to see their imported data in their profile fields and therefore call that information into an address book.
User import without the importer being able to define a tag or relationship with their importees closes a lot of doors I feel. Actually I would like ability to bypass the pending stage and set all retionships as approved, there is little reason to notify importee either about the relationship, it is enough for them to deal with either accepting the invite or not accepting the invite. If after understanding the system they don't want to continue the relationship they can cancel the relationship.
Pending processes are only neccessary for new relationships that occur at the site.

#1
I just had a look at this module and it seems to be for admins only. I would like my users to be able to import contacts. I can give them permission but then I'd need to alter the form so that they can import only. Ideally if role has permission a new menu item is created which allows import only and has url /import-contacts. I think admin ought to control arbitrary relationship because no doubt an import will include several different types of relationship. There is no need to distinguish individual relationships, there is only a need for one tag which will build a bridge between importer and their importees.
#2
User Import has APIs to integrate with other modules, so you (or the developer you hire) should be able to cleanly add User Relationship options to the import form and the import process.
Allowing non-admin users is part of the goal of the User Import Organic Groups module, at the moment it's targeted at OG group maintainers. The idea is to have pre-configured 'locked-down' import templates created by admins, that can then be used by non-admin users. Still needs some work to get that functionality ready for release though.
#3
Hm well OG is not suitable for social network type systems. It's good for allowing a few individuals to control sections of sites but not for user to user interactions. I'm not sure I'd be able to make this, I'll have a look but am doubtful.
What happens if an importer reuploads a csv after an importee has updated their profile. The system would have to recognise each and every row in the csv and decide if each row is not already a user even after a user has updated their details. It would need to store the original import settings for each user and run a comparison against new importees. Perhaps if email and username match an existing (original) importee record, don't create user. Otherwise there will be an excessive number of dead user accounts.
This is certainly a key feature for a social network, the only solution currently is to invite users one by one and then ask them to form a relationship. In fact it's not a solution at all, most users will do it once or twice and then get fed up with the process and give up. A feature as I've suggested would act like an atomic chain reaction rather than a slow and tedious word of mouth/never really get off the ground system.
#4
http://drupal.org/node/548054