Closed hburgund closed 7 years ago
Another possible solution has come to mind. Rather than creating a new BlockedContent
model, perhaps we could make use of the already existing Vote
model as that was built with extensibility in mind. The purpose of votes is for users to register their "opinion" about a specific asset, so if that "opinion" was block
, maybe that solves our issue?
The Vote
model has the following fields currently:
type
- currently like
flag
or rate
asset_id
- ForeignKey to Asset
modelsession_id
- ForeignKey to Session
modelvalue
asset_id
and session_id
overlap with the proposed BlockedContent
model and the latter can yield blocker
, though I would argue that it is probably easier to just add a voter
field rather than having to traverse models all the time. If we instituted two new vote.type
values - block_asset
and block_user
, that might be enough to handle our needs.
I like using what we already have rather than adding an entirely new model, and I do think that this use case is aligned with the definition of "voting". BUT I don't want to shoehorn functionality into a place where it shouldn't be just to save adding a new model if ultimately it would make things more complicated.
@eosrei @jslootbeek any opinions?
vote.type
options - block_asset
block_user
vote.voter
field - ForeignKey to auth_user
model (settings.AUTH_USER_MODEL
)GET
and POST
api responsesvoter
into new field
Per Apple's "new" requirements, we need to be able to let users specify content they want blocked i.e. never added to their stream. There are two types of content:
asset_id
asset.id
->asset.session_id
->session.device_id
->userprofile.user_id
->auth_user.id
]In other words, users can block a specific piece of content or they can block all content by a certain user.
Proposed Solution
We want to keep the ability for anonymous use, which should be possible. I envision creating a
models.BlockedContent
model that stores information on what content has been blocked and then playlist filtering must take this into account when it generates playlists. Perhaps we can use the banned assets feature as an example, though that is on a session-by-session basis, not an overall ban.models.BlockedContent
could have the following fields:id
blocker
- the user doing the blockingblocked_asset_id
- ForeignKey toAsset
modelblocked_username
- ForeignKey toUser
model (not sure ifrw_userprofile
orauth_user
is better here)session_id
- just for good measure to track thingsIt seems better to me to store all blocks in one model rather than storing asset blocks in one and user blocks in another. Perhaps if a record contains a
blocked_username
with noblocked_asset_id
then the assumption is that all content produced by that user is blocked.With this data in place, every time a new session is created, the session user is known, so this model can be polled for all blocked content and then that blocked content can be stored in a temporary "session blocked list" of some sort that is cross-referenced each time the list of available assets is created or updated. Blocked users would be converted into a series of blocked assets to create the blocked list so that the list is simply asset_ids.
API UPDATES
POST /api/2/blockedcontent/
- params [user
asset_id
block_type
session_id
] (block_type
would be"asset"
or"user"
to indicate a single asset block or all assets by user of submittedasset_id
)GET /api/2/blockedcontent/?user=<username>
- retrieves all blocked content for specific userNaming
I'm not sure "block" is the best terminology here, but it may be. "ban" could be better to avoid all the other meanings, technical and not, of "block". We already use "ban" for time/proximity banned assets; not sure if consistency there would be good or confusing.