Bug #5320

can't add commons users to private paper

Added by erin glass over 5 years ago. Updated over 5 years ago.

Priority name:
Category name:
Social Paper
Target version:
Start date:
Due date:
% Done:


Estimated time:


Hi all. Eileen Clancy is trying to use Social Paper for her class with Cheryl Smith. Unfortunately, she was unable to share her private paper with more than one user. Some of the users she tried were: tkelly and ctrowbridge. Any idea what the issue might be?

If you have questions for her, she can be contacted at:

Thank you!



#1 Updated by Boone Gorges over 5 years ago

  • Status changed from New to Reporter Feedback

It's a bit difficult to guess what might be going on without more specific details about (a) what the user is doing, (b) what the user expects to see, and (c) what the user actually sees.

But, playing around a bit, my guess is that tkelly and ctrowbridge are neither friends with the user nor in any of the same groups as the user. Thus it's possible, if my guess is correct, that they're not appearing in the autosuggest field on the Readers page. The quickest workaround is to invite them to be friends.

I struggled with the best behavior for the Reader autosuggest box when first building it. Using AJAX exclusively makes it exceedingly slow. But preloading using smart defaults results in weird UI issues when the desired user is not included in the preloaded defaults. Select2 did not, at the time, make it very easy to both preload and also use AJAX as the fallback when no preloaded results are matched. Looking around now, it appears that some progress has been made: I've left an additional note at the existing Github issue so that I remember to look more closely at this in the future: :

#2 Updated by Matt Gold over 5 years ago

The use case here is that we have someone teaching a class on the Commons using only a blog rather than a blog and a group.

Aside from the workarounds for this particular user, there are some workflow and usability issues for people teaching classes on the Commons:
1. do instructors understand the ramifications of not using a group and using a blog only for their courses? Since this course, from my understanding, intended to use Social Paper from the beginning, it should have been using a group
2. do users generally understand that they need to be in the same group with users they want to add or friends with users in order to add them to a paper?
3. do those two conditions (people have to to be in a group with or friends with a user before adding them to a paper) actually make sense from a usability perspective?

My answers to these questions are:
1. No. We need to be sure that the materials we produce to guide instructors are clear about this (Kelly -- FYI)
2. No. We need to address this is SP instructions and documentation (Scott, Boone)
3. No. We should consider whether it would be feasible to allow users to add any user from the network to share a paper. I imagine that would affect the usability of SP itself -- ie, that one would have to pre-load all member names to that javascript element, which (as we've seen with my account, since I have a lot of friends) could significantly slow page loads.
3a. This brings up another question -- are there ways of getting around this -- ie., a link/button someone could click that says "Add any member of the network" or something that would trigger a load of all member names on click so that it wouldn't have to be part of the automatic page loading of SP

I've cc'ed Luke, Kelly, Sam, Steve, and Scott. And obviously, I'm interested in Boone's thoughts.

#3 Updated by Boone Gorges over 5 years ago

If the inability to add users that are not friends/group-co-members is a showstopper, then we should just change it instead of introducing a bunch of documentation that describes workarounds.

ie, that one would have to pre-load all member names to that javascript element, which (as we've seen with my account, since I have a lot of friends) could significantly slow page loads.

The simplest alternative, given the technical hurdles, is to skip the preloading and do all Readers querying via AJAX. This will mean a sluggish but fully functional UX for Readers. If Erin and Matt deem this specific issue to be critical, then I will make the change, and we can worry about speed later on. (This issue strikes me as relatively minor, so I don't want to sink more hours into discovery than have already spent in order to find the "perfect" solution.)

#4 Updated by erin glass over 5 years ago

Thanks, Boone and Matt. I like the usability questions this brought up as I was surprised myself to find that Cheryl Smith had created a course blog and not a course group. I agree with Matt that we can refine our instructions based on use cases like these.

I don't think the inability to add users that are not friends is a showstopper, but we should change the documentation if that is indeed the case. I also like Matt's idea outlined in 3a but if it takes tons of development time, perhaps it would be best to just change the documentation.

#5 Updated by Boone Gorges over 5 years ago

  • Status changed from Reporter Feedback to Assigned
  • Target version set to 1.10

Thanks, Erin. I'll just change the way the loader works for 2.0 (it's a relatively minor change) and we can discuss whether the performance hit is problematic.

#6 Updated by Boone Gorges over 5 years ago

  • Status changed from Assigned to Testing Required

I've rewritten the way the Readers autocomplete box field works, so that it does a full-directory search via AJAX rather than pre-loading users into the browser. It's slower, but it's now comprehensive. Ready to test on

Implemented as a REST API endpoint, to make it a bit faster than an admin-ajax.php call

#7 Updated by Samantha Raddatz over 5 years ago

Tested! I'm loving the 'searching...' text that comes up to allow for immediate feedback and that it allows the user to search by full name OR user name (samantha raddatz or samradd).

It worked well for me after searching a few different things. I did notice a weird search result that's just a long list of names -- see attached screen shot. Other than that, I approve!!!

#8 Updated by Boone Gorges over 5 years ago

  • Status changed from Testing Required to Resolved

Thanks, Sam! The long list of names is some junk data on cdev, so please disregard. Marking as resolved.

Also available in: Atom PDF