I have 2 user types, "instructor" and "studio"
I want the "studio" to be able to put "instructors" onto a schedule, but only with the approved relationship of "studio -> instructor"
So basically, I want "studios" to request a relationship with an "instructor" and both should be able to review and cancel that relationship at any time. This works well in User Relationships, however the wording is strange in some places.

Basic names

  • I've given the relationship a name of 'scheduler'
  • I've branded it as 'instructors scheduled at this studio'
  • The "one-way reverse" is "studio that can place me on a schedule"

Messages involved

I've marked each with a comment (e.g. [perfect]) about how the labeling works out in practice.

Requester "studio" user messages:

  1. Become Trevor Instructor's scheduler [perfect]
  2. Are you sure you want to send a new scheduler request to Trevor Instructor? [perfect]
  3. Your scheduler request has been sent to Trevor Instructor [perfect].
  4. You have sent a new scheduler request to this user. [perfect]
  5. "My relationships" tables "Relationships" column: "scheduler" [awkward]
  6. "My relationships" page tab for this kind of relationship: "Instructors scheduled at this studio" [perfect]

Receiver "instructor" user messages:

  1. Are you sure you want to approve the scheduler relationship request from Trevor Studio? [perfect]
  2. Trevor Studio's scheduler request has been approved. [perfect]
  3. "My relationships" page tab for this kind of relationship: "Instructors scheduled at this studio" [wrong]
  4. Relationships labeled: "studio that can place me on a schedule" [perfect]
  5. "My relationships" tables "Relationships" column: "studio that can place me on a schedule" [perfect]

Problems

1) The page tab on the "instructor" user type (receiver of request) is mis-labeled

I have this above as item #3 under 'Receiver "instructor" user messages'

problem

The "Captialized name" for the One-way reversed branding I have configured is "Studio that can place me on a schedule"
But, the page tab here is using the "Capitalized name" set in the primary Branding.
This works on the "studio" page perfectly, but on the "instructor" page it's backwards. This is the most striking of issues and seems like a true bug. In all other instances, the "instructor" sees the "One-way reversed branding"

solution

Replace the page tab title on the "Receiver/instructor" user with the "One-way reversed branding Capitalized name"

2) The Branding name should be different than the relationship name

I have this above as item #5 under 'Requester "studio" user messages'

problem

This one is a bit more complex, involves a need for slightly more drastic modifications and requires a hell of a lot of explanation...
Because the relationship name "scheduler" is presented to both users, it separates itself from the concept of a one-way relationship. See #1 - #5 in "Requester/studio" above and #1 and #2 in "Receiver/instructor" above for examples of where "relationship name" is presented to both users. If this were a one-way term, it would be presented one way to the "Requester/studio" and another way to the "Receiver/instructor."

solution

To solve this, You can't simply replace the "relationship name" with the "One-way reverse branding name" on the "reciever/instructor" messages because these messages wouldn't make sense:

  1. Are you sure you want to approve the studio that can place me on a schedule relationship request from Trevor Studio?
  2. Trevor Studio's studio that can place me on a schedule request has been approved.

These 2 messages require a name for the relationship as the relational pertains to itself and describes itself as a relationship. There are other places, like #3 - #5 above where the relationship needs be described as a relationship that pertains to me and describes my involvement in the relationship. The difference in this case is: a) The relationship is a "scheduling relationship" while b) the relationship to me is a "studio that can schedule me"
The possessives in the titles allow for a much better user understanding of the relationship. These possessives are not possible in the current framework.

Solution summary

  1. Allow the current required "Name" field to describe the "relationship"
  2. Create a new "name" field under "Branding" that describes "the relationship as it pertains to a user viewing the relationship"
  3. Alter code to segregate usage of old name and new name
  4. Provide better help text on each field
  5. Provide examples of messages in help text of each field

Patch coming soon... I'll try to illustrate this with some screenshots.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tmsimont’s picture

Issue summary: View changes

broke up long text with some nice headers

tmsimont’s picture

Issue summary: View changes

typo

tmsimont’s picture

screens attached that illustrate changes in upcoming patch

tmsimont’s picture

Status: Active » Needs review
FileSize
9.84 KB

patch attached...

thoughts?

illustration of changes in UI part 1
illustration of changes in UI part 2

Berdir’s picture

I'm actually surprised how well the whole thing seems to work out of the box. Given that I never really tested it in a real system, that's not that bad :)

Adding a descriptive name and better descriptions sounds nice, thanks for working on this project!

tmsimont’s picture

Thank you for actively maintaining it!

Attached is a version that won't introduce whitespace errors

tmsimont’s picture

and here's one that uses the branded terms on the user pages. interdiff included

Berdir’s picture

Thank you for actively maintaining it!

Given my my activity on this project, this is rather ironic ;)

+++ b/user_relationships_ui/user_relationships_ui.moduleundefined
@@ -98,14 +98,16 @@ function user_relationships_ui_actions_between($viewer, $viewed, $action_types =
+        $this_user_str  = $viewer->uid == $relationship->requestee_id ? 'requester' : 'requestee';
+        $name = user_relationships_type_get_name($relationship, FALSE, $relationship->is_oneway && $this_user_str == 'requester', FALSE, !($relationship->is_oneway && $this_user_str == 'requester'));

Looks like you have two spaces before the =

Code looks good, maybe someone can do a manual test? The automated tests are currently disabled because the i18n integration is broken.

Berdir’s picture

Issue summary: View changes

removed confusing tags that were accidently copy/pasted