Migrate links into graph-store about landscape HOT 7 CLOSED

Thanks M

from landscape.

@tacryt-socryp now on graph updates, UI; @belisarius222 on tombstoning and unarchiving functionality.

from landscape.

Hello @matildepark — I saw recently that the "Archival" interface/design task was closed in lieu of us referencing this issue we're speaking in. If I have designs for Archival-related interfaces, should they just go in here?

from landscape.

from landscape.

Cool, good to know — will be updating this ticket soon.

from landscape.

There are a few interfaces that are involved in archiving, and I basically wanted to enumerate them here. If I appear to be missing anything, please suggest.

In the group settings page, available only to group Admins, I'd imagine we'd want to place a setting option at the bottom of the settings stack, effectively replacing the "Delete Group" option. I've run a very loose pass of copy on this option, and it's A Lot, but the copy should totally explain the implications of Archiving a group:

—

On the receiving end of of a group's archival, a member of a group should probably be tuned in to the status of the group and their inability to communicate within it or update it. Here's a proposal in which we attach a very obvious banner to the top of the group in order to signal its archived state

Also: For those if you discussing how we might render the state of a group from the POV of someone who's been banned from the group, the idea is to use this interface for situations like that as well

—

The last interface I'd like to make note of here is an interface that would be applied to each channel within an archived group. For those of you who have seen the latest group designs, this shouldn't be new. It's basically signaling the state of the channel using its header and footer elements and an additional "status banner":

Note the copy in the interfaces themselves — they point to the state of the greater structure of a group.

—

I think for this issue/PR in general, we might not need to incorporate all of these designs, but it's a good idea to see the total environment we'll needing to be signaling an "archived state" within.

from landscape.

• the UI, hooks, view-threads, store, scry into the store are integrated and work (release/link)
• there are more tasks:
  • invites (trivial)
  • joining a graph (somewhat complicated)
  • differentiating the resources that are using graph
    • metadata-store was created to display the Channels feed in groups application, so we can display title, desc, ‘type’ (app) without joining it to get that data
    • one of the fields in metadata-store is app-name, distinguishing whether to show as publish notebook, link collection, chatroom, but also which application on FE to redirect to when joining that application
    • with the graph application, we need to set the app name as ‘graph’ because when we are joining a new graph application, or creating a new graph, we do not necessarily know what app name to provide it with and we need to more or less denote that it is something interacting with a graph-store
      • @belisarius222: why don't we know that?
      • @tacryt-socryp : resource scry works on 3 indices: app name, app resource name, group resource name; we use the app-based query which requires us to know which app it’s using ahead of time
      • we need to differentiate graph-based resources on front-end, though, because we need to be able to redirect to the correct page

from landscape.