Allow external contexts to determine the client's group scope

[dwhly]

Updated background:

There are perhaps two problems that are related but distinct here. The common thread in both is that we want the client to be scoped to a specific group as determined by some external context.

In one example we want to direct link to a group. In other words, enable a page to be linked to (for instance, via a bouncer link) and determine the group to be focused at the same time.

In another example, we want a document stored within the LMS context (or perhaps in gdrive, or more broadly, any web page linked to in the course materials) to be able to have the H client present and scoped to the right group.

It's possible that for some of these the bouncer link might be used, and for others, not. Even within the LMS example, it's possible that a bouncer link might be required for some of the examples, but not others. Perhaps all of these examples would share some basic common requirement(s) that require(s) development.

--- Previous background ----

In hypothesis/bouncer#48 @robertknight says:

group:{pubid} - No, not yet. I do understand that this would be very useful. It does surface some issues that we'll need to address or have a reasonable idea of what we might do later, such as how to handle the case where the current user is not a member of the group and will we ever support multiple groups. Could you file an issue?

Questions:

What if the current user is not a member of the group

If they follow a hyp.is link that specifies a group they're not a member of, they should be taken to the indicated page, but the target group annotations obviously cannot and presumably should not be shown to them. For now, I don't think they should auto-join the group, though I can imagine that groups which are more open might be able to be configured to allow auto-joining.

In the event that they're not a member, perhaps a card or alert is shown that says "you don't have permission to view annotations in group XXX".

Will we ever support multiple groups (being specified as params)

Possibly-- though I imagine the overwhelming use case here is a single group. For sure multiple groups is not a first requirement. Do we need to determine now?

[ajpeddakotla]

@lyzadanger not sure if you caught this one, so I'm adding it to the LMS board for triage. As per our conversation yesterday, and @dwhly's comment here, this issue describes work that would allow us to use group as a filter param so that we could link to a group via a bouncer link.

The work that Sheetal's doing here, is a first step to this work, and implementing both of these might help address the issue of how to focus the user on the correct group.

[lyzadanger]

We should schedule a call to talk about this functionality. I’m finding myself confused about how bouncer has anything to do with which group to focus in the client within LMS.

…

On Jul 11, 2018, at 6:16 AM, Arti Walker-Peddakotla ***@***.***> wrote: @lyzadanger <https://github.com/lyzadanger> not sure if you caught this one, so I'm adding it to the LMS board for triage. As per our conversation yesterday, and @dwhly <https://github.com/dwhly>'s comment here <hypothesis/product-backlog#680 (comment)>, this issue describes work that would allow us to use group as a filter param so that we could link to a group via a bouncer link. The work that Sheetal's doing [here] (#748 <#748>), is a first step to this work, and implementing both of these might help address the issue of how to focus the user on the correct group. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#488 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2i286J51leHcFEtDH6S5S-V45Le5Gks5uFdCIgaJpZM4OREo6>.

[segdeha]

"Support group: as a filter parameter" is a technical solution to some problem. @dwhly, can you close this and open a card where this is expressed as a problem that needs to be solved, such as "Support direct linking to groups" or something?

[dwhly]

@segdeha I've changed the title of the card to something hopefully more appropriate.

Added:

"There are perhaps two problems that are related but distinct here. The common thread in both is that we want the client to be scoped to a specific group as determined by some external context.

In one example we want to direct link to a group, in other words enable a page to be linked to (for instance, via a bouncer link) and determine the group to be focused at the same time.

In another example, we want a document stored within the LMS context (or perhaps in gdrive, or more broadly, any web page linked to in the course materials) to be able to have the H client present and scoped to the right group.

It's possible that for some of these the bouncer link might be used, and for others, not. Even within the LMS example, it's possible that a bouncer link might be required for some of the examples, but not others. Perhaps all of these examples would share some basic common requirement(s) that require(s) development."

[dwhly]

@lyzadanger & @ajpeddakotla: Happy to join if there's a discussion planned.

The work that Sheetal's doing here, is a first step to this work, and implementing both of these might help address the issue of how to focus the user on the correct group.

I think the work to convert share links to support bouncer is great, and overdue. But it's unrelated and not a prerequisite for being able to scope the client group from an external context. Actually, I might suggest the opposite, which is that if the client is currently scoped to a group, then one might argue that the share link available in the interface should inherit the currently scoped group--- otherwise your share link will not take folks back to the annotations & general discussion that you're currently viewing. This probably needs its own card.

[dwhly]

Potentially consider this as part of the implementation: hypothesis/product-backlog#713

[segdeha]

Thanks for the added context, @dwhly. I wonder if hypothesis/product-backlog#713 doesn't cover it? In any case, I think this is something to be considered/fleshed out a bit down the road. Share links might not have a lot of meaning in the LMS context (think of PDFs that live within Canvas being annotated; it wouldn't make sense to create a link for that that someone would share on the open the web).

[dwhly]

I wonder if hypothesis/product-backlog#713 doesn't cover it?

Nope. These are two distinct issues.

1. Our client needs to be able to be scoped to a group, either by direct linking, or from other external contexts in which we're embedded (LMS, etc).
2. Once our client can be scoped to a group, we should update our share links (using the bouncer upgrade that @sheetaluk just implemented) to include group scope. This is Share link should bring folks to the same view product-backlog#713

In any case, I think this is something to be considered/fleshed out a bit down the road. Share links might not have a lot of meaning in the LMS context (think of PDFs that live within Canvas being annotated; it wouldn't make sense to create a link for that that someone would share on the open the web).

Disagree.

1. This issue (Allow external contexts to determine the client's group scope #488) is (per your appropriate request) no longer (just) about share links. As you requested, this is now about "Supporting external contexts being able to determine the client's group scope" e.g. external contexts such as the LMS. It is exactly about being able to ensure that a "PDF that lives with[in] Canvas" is able to be delivered wrapped by the H client in such a way that the relevant group scope is injected.
2. It does also suggest that one of those external contexts might be the direct link context.

it wouldn't make sense to create a link for that that someone would share on the open the web)

Also Disagree.

Within a course syllabus, teachers often link to materials on the open web. In fact, our ability to carry the course context along w/ the share link to a page on the open web is a powerful advantage. One of the principal complaints that we've gotten from educators thus far is: "I'm sending them to the via link, but then I have to tell them to manually switch the group control to our classroom group".

So, by ensuring that bouncer links can carry group scope, we're trying to fix what has been one of the #1 complaints by teachers thus far. That's why this has been targeted for the edu product upgrade for this go-round.

[dwhly]

it wouldn't make sense to create a link for that that someone would share on the open the web

I'm rereading this now, and realizing that the action may have been unclear.

This is not about allowing someone from outside the LMS to be able to have a share link that allows them to link into a PDF stored in the LMS. Clearly that wouldn't make sense-- for starters, they wouldn't be properly authenticated.

It's about enabling share links used from within the LMS (like in a course syllabus, linking to materials) to link to external resources, like web pages etc, such that they carry the context, group, etc of the course. It also happens that this would solve a broad class of requests that we get from partners beyond education to be able to have share links carry group context.

[ajpeddakotla]

Closing in favor of hypothesis/product-backlog#748