Change Details

When replacing User::addWatch and friends with calls to the corresponding methods on WatchedItemStore, the `viewmywatchlist` and `editmywatchlist` permissions have to be checked. We don't want all callers to duplicate that logic, but we don't really want WatchedItemStore to worry about user permissions too much either. We could however implement a simplified access check, given the following assumptions: * Users can only access their own watchlist * Users may want to restrict access further when acting through OAuth * Some operations may want to bypass this restriction (e.g. edits via oauth should still automatically add items to the watchlist if this behavior is enabled in the user's preferences) This can be implemented by having a $readRestriction and a $writeRestriction field in WatchedItemStore. Each restriction field can have three kinds of values: * null: no restrictions apply * true: restricted, access will fail. * a UserIdentity: only this user's watchlist items can be accessed, attempts to access other user's watchlist items will fail. Checked access will be done via new methods, using names like addWatchChecked or some such (maybe these should not be in WatchedItemStoreInterface). The restriction levels can be set via the constructor, or a setter in WatchedeItemStore (not WatchedItemStoreInterface).

When replacing User::addWatch and friends with calls to the corresponding methods on WatchedItemStore, the `viewmywatchlist` and `editmywatchlist` permissions have to be checked. We don't want all callers to duplicate that logic, but we don't really want WatchedItemStore to worry about user permissions too much either. We could however implement a simplified access check, given the following assumptions: * Users can only access their own watchlist * Users may want to restrict access further when acting through OAuth * Some operations may want to bypass this restriction (e.g. edits via oauth should still automatically add items to the watchlist if this behavior is enabled in the user's preferences) This can be implemented by having a $readRestriction and a $writeRestriction field in WatchedItemStore. Each restriction field can have three kinds of values: * null: no restrictions apply * true: restricted, access will fail. * a UserIdentity: only this user's watchlist items can be accessed, attempts to access other user's watchlist items will fail. Checked access will be done via new methods, using names like addWatchChecked or some such (maybe these should not be in WatchedItemStoreInterface). The restriction levels can be set via the constructor, or a setter in WatchedeItemStore (not WatchedItemStoreInterface). It would have to be set by wiring, when the WatchedeItemStore is constructed, based on information from the current request's session. NOTE: this is blocked on a decision about how service behavior can vary based on the current user's session, see T218555 and T231930.

When replacing User::addWatch and friends with calls to the corresponding methods on WatchedItemStore, the `viewmywatchlist` and `editmywatchlist` permissions have to be checked. We don't want all callers to duplicate that logic, but we don't really want WatchedItemStore to worry about user permissions too much either. We could however implement a simplified access check, given the following assumptions: * Users can only access their own watchlist * Users may want to restrict access further when acting through OAuth * Some operations may want to bypass this restriction (e.g. edits via oauth should still automatically add items to the watchlist if this behavior is enabled in the user's preferences) This can be implemented by having a $readRestriction and a $writeRestriction field in WatchedItemStore. Each restriction field can have three kinds of values: * null: no restrictions apply * true: restricted, access will fail. * a UserIdentity: only this user's watchlist items can be accessed, attempts to access other user's watchlist items will fail. Checked access will be done via new methods, using names like addWatchChecked or some such (maybe these should not be in WatchedItemStoreInterface). The restriction levels can be set via the constructor, or a setter in WatchedeItemStore (not WatchedItemStoreInterface). It would have to be set by wiring, when the WatchedeItemStore is constructed, based on information from the current request's session. NOTE: this is blocked on a decision about how service behavior can vary based on the current user's session, see T218555 and T231930.