During the port, we discovered that there is no way to see the relationships of other users except when you use the blocks or custom views.

We should think how we should properly deal with that in the future. Not yet sure if this is 7.x-1.x or 7.x-2.x. Maybe some improvements to 7.x-1.x but the cool stuff needs to wait.

A simple thing would be a new view other relationships permission, that allows to give read-only access to relationships of other users in a controlled way.

One cool thing would be a field access module which would give users for example control over which fields on their user account are visible to whom (All/Friends/...).

Comments

Yeah, I love your idea of a field access module. That would be very, very cool. Is that too ambitious for 7.x-1.x? Any reason to wait until relationships are actually entities? Perhaps fields on relationship entities could have access control also?

But definitely a new permission would be a good first step. Do you think it's just a "View all relationships" permission, or do you think also a few more granular permissions like "View relationships of friends" for each relationship type?

--Ben

That is most certainly 7.x-2.x stuff. Remember that this needs completely new UI's, one to configure which entities and which fields on those entities can be controlled, and then one where users can configure it. That will require quite some time to figure out how to do implement that.

View all relationships would be enough for a start I guess. We need to define what these users will actually be allowed to see, how it is displayed and of course we need quite some API changes. Adding relationship type specific permissions above that would be rather easy.

Okay, sounds good. For "View all relationships" permission, we've definitely got the blocks to show and also the relationship pages for the user. Should there be a link to the relationship page of that user from the user profile page?

And probably both the "Pending" tab and the "elaborations" field should be hidden (unless we create a separate permission for that)?

This is related to another issue, but I also think we should get rid of the tabs for each relationship type and just have a "Current" tab and a "Pending" tab. The "View all relationships" permission would just grant access to the "Current" tab (where relationship types could be filtered via a dropdown menu similar to Userpoints).

Thoughts?

--Ben

The tabs vs. select isn't really affected by this, let's discuss this in the other issue :)

Agreed on the other stuff.

Soooo would a field access module replace modules such as cck_private_fields?
Because that'd be awesome (I don't believe any of those field privacy modules are currently in the works for a D7 port).

Whilst all the other planned improvements are great, this is the one I am most excited about (even if it is likely going to be one of the later ones).

Hey Berdir,

I've been thinking about module permissions and one other thought occurred to me...

What do you think about dividing up the "Maintain own relationships" permission and "View own relationships" permission into separate permissions for each relationship type? The reason I ask is that my use case will have a lot of different relationship types (some that are visible to the user, some that are hidden for administrative purposes and tracking interaction between certain users).

What do you think? It seemed to apply to the general issue topic, but I can of course make a separate issue if needed.

--Ben

Makes sense, that's exactly what is happening in #1099406: Convert role permissions settings into permissions for the "have relationships" permission.

So, we would end up with just relationship specific permissions + administer (no point in splitting that up). This would be the permissions we would end up with I think:

Base module:
- Have (receive) relationships
- Request relationships

UI:
- View own relationships
- View all relationships
- Maintain own relationships

Privatemsg:
- Write private messages to relationships

- More?

Agreed that we should keep this as kind of a meta-issue for the whole permissions/visiblity thing to discuss new ideas and track progress, but once we agreed on doing something with patches and stuff, create a separate issue. We already have an issue for have/request and privatemsg, so you can create a new one for the UI permissions...

Thanks for summarizing all of the permissions... very helpful. And all of the permissions you listed make sense.

Just one thought: Do you think the "Maintain own relationships" permission is too broad? Should this be divided into separate smaller permission?

The reason I ask is that doesn't "Maintain own relationships" kind of overlap with "Request relationships" (which is a specific "maintenance" task). Also, would there be instances where "Approve/decline relationships" should be separate from "Remove relationship"? For instance, may be you have a type that you want a user to be able to accept, but you want a historical record that the relationship was accepted (it's a one-time thing that can't be revoked) and so you don't want the user to be able to remove it?

What do you think?

--Ben

Good point, so what do you suggest? Split maintain up into what? Approve/decline and delete?

Also, the elaborations has no separate permisisons currently, do we want some permissions for that too?

Yeah, my suggestion would be these two permissions (instead of "Maintain own relationships"):

1. "Approve or decline relationship request"
2. "Remove own relationships"

And yes, some permissions for elaborations would probably be good. What do you suggest?

--Ben

Agreed that we should keep this as kind of a meta-issue for the whole permissions/visiblity thing to discuss new ideas and track progress, but once we agreed on doing something with patches and stuff, create a separate issue. We already have an issue for have/request and privatemsg, so you can create a new one for the UI permissions...

Just expressing an interest in this. I haven't quite figured out exactly how I want to structure the security, but do like the idea of having an option to allow a specific field to only be visible by a site admin. But my primary uses would probably be for visibility of Profile fields and some node types.

A rough example might be a To-do list entry that should only be visible to members of the same team/group.

Status:Active» Postponed

I'm voting to postpone this until 7.x-2.x. I think a rewrite would be a better time to tackle something this large.