#158 Implement 'My Stream' page (inbox for incoming notifications for logged in user)
Closed: Fixed 2 years ago Opened 3 years ago by duffy.

This page should be the first thing you see when you log in. It's different than your profile. There's information on your profile that doesn't necessarily have interest for you personally. See issue #84 for a discussion comparing the two.

profile-vs-stream_stream-1.png


Some discussion about this ticket happened at 13 Jul 2016 hubs-devel meeting.

This is almost entirely implemented at the moment, but we need changes in FMN to get the data that will populate the streams (basically: publish the generated notifications on fedmsg). @jcline is on it.

Metadata Update from @abompard:
- Issue set to the milestone: Production

2 years ago

Metadata Update from @abompard:
- Issue assigned to abompard (was: atelic)

2 years ago

OK, back to the (technical) drawing board on this one, because I misunderstood what the Streams page was supposed to show and how it would look.

Since that page must hold widgets, we must find a database schema that will allow this while keeping a difference between a users's public hub and that user's private stream page.

I have considered the following options:

  1. Namespace the hub name (stream hubs will be called stream-<username>):

    • It seems clunky
    • It does not anticipate other hub types (like regional hubs)
  2. Make a separate table for the widget-holder object:

    • the user table will reference this new table for stream hubs, there will be a "user hub" and a "group hub" tables that will reference it also.
    • this basically boils down to using DB tables for the hub_type field. It seems a bit wasteful, and will require new DB tables for new hub types.
    • it will make the API more complex too
  3. Rewrite the hubs table to use a numeric ID for the primary key, and have a unique index on the (name, hub_type) couple:

    • + it's more future-proof as it will accommodate for new hub types
    • + there's no duplication of information (as opposed to the namespacing)
    • - we'll need to change a lot of calls to Hub.query.get()
    • - we may need to change the URL scheme: /u/<user>, /t/<team> (and /r/<region> in the future) but maybe we can avoid this at first and add redirects later if necessary. This can be discussed.
    • - we'll need to change the API URL schemes
    • - it requires a rebuild of the database because all the foreign keys to Hub will break
    • - there are a lot of places where the hub name is considered sufficient to identify a hub, and it will need to be updated (for example the messages in the triage/worker backend)

I think I'll go with option 3, it seems the best. I'll do the URL changes too, we can introduce redirects later if we really want to.

Login to comment on this ticket.

Metadata
Attachments 1