Closed (fixed)
Project:
User Relationships
Version:
6.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
29 Feb 2008 at 00:35 UTC
Updated:
21 Aug 2009 at 08:28 UTC
Jump to comment: Most recent file
Comments
Comment #1
4drian commentedI definitely second this - I have exactly the same situation as above. I also have relations such as "lead" which I'd rather certain users did not know the existence of.
Comment #2
Vuds commentedI'm needing to have that too. It doesn't have to be two-way for me, but I think that if you'd implement that, you'll do the complete thing.
Comment #3
webchickI agree that this would be useful.
Implementation-wise, we're probably looking at a new user_relationships_types_roles table, adding a list of checkboxes for roles on the relationship setup screen, and doing a join on that new table when pulling up a list of available relationships for a user to select from.
Comment #4
Super Druper commentedSame request here. This would be a great feature to see implemented in future releases of the module. Seems like there's some interest for this feature, hopefully the momentum will build up to make it happen.
Comment #5
ryanscott commentedme too - need employee/employer along w friend/fan and supporter (one way) all in the same site depending on role.
Comment #6
stopbox commentedYes please, this feature would be fantastic.
Comment #7
alex.k commentedImplemented and committed. It's part of core functionality, no need to enable another module. The UI is pretty simple, it's a set of checkboxes on the relationship type setup form, like webchick suggested. Default is to allow everyone access, so that existing installs are not interrupted. Be sure to run update.php when you download the latest -dev release.
Any issues, please reopen or create a new one.
Comment #8
jaydub commentedHey alex I just picked up this change when checking out the fix to the SERIAL issue. Was thinking that the hook_update_N call for the new user_relationship_type_roles table should be user_relationships_api_update_6101 and not _6200.
There's not 6.2 branch yet and an update function of 6200 implies an update to 6.2 branch. At least that's what I seem to recall being the update_N numbering system...
Comment #9
alex.k commentedOops, you are right. Did not look in the docs http://api.drupal.org/api/function/hook_update_N/6 before writing... Renamed the function and committed. Users who have run the incorrect 6200 update will need to execute this SQL statement:
UPDATE system SET schema_version='6101' WHERE filename LIKE '%user_relationships_api.module%'
Comment #10
alex.k commentedRegarding fixing the update function numbering, see #386370: After running update.php, got this? Normal? (UR) for what happens if you do not run the SQL statement. Basically it tried to rerun earlier updates, which fail but do not break anything.
Comment #12
perceptum commentedHas this been ported to 5.x at all?
Bryan
Comment #13
alex.k commentedNo, I would accept patches for 5.x but have no plans to port it.