Page MenuHomePhabricator

Cap the number of active newsletters per user
Closed, DeclinedPublic

Description

The number of newsletters a user may create should be capped. If a user is already a publisher of N active newsletters, the user should not be permitted to create additional ones.

I am not sure what would be a good value for N. 25? 100? 1000?

Event Timeline

ori created this task.Apr 2 2016, 2:33 PM

The only interesting question about this is: what about users who are added as publishers to other newsletters by other people? Do we block a user from being added as a publisher when they reach the limit, or do we only block the creation of new newsletters?

Parent5446 removed Parent5446 as the assignee of this task.Apr 2 2016, 2:58 PM

Weird, I don't remember claiming this in Phabricator. Although I can work on it if @01tonythomas wants.

Do we block a user from being added as a publisher when they reach the limit, or do we only block the creation of new newsletters?

Maybe just the creation of new newsletters.

The only interesting question about this is: what about users who are added as publishers to other newsletters by other people? Do we block a user from being added as a publisher when they reach the limit, or do we only block the creation of new newsletters?

I think we should only block the number of newsletter creation per user. Adding as publisher by other user got a different origin.

ori added a comment.EditedApr 2 2016, 4:12 PM

You could simplify things substantially by allowing only one publisher for each newsletter, and making newsletter ownership transferable. This would allow you to get rid of the nl_publishers table entirely (you'd replace it with an additional column in nl_newsletters).

In my opinion, this would be an improvement. People would still be able to share editorial responsibility for a newsletter. Being the owner simply means you have to be the one clicking the button to announce a new issue, but so what?

Wait, capped why? What's the value of an artificial limit?

ori added a comment.Apr 2 2016, 4:32 PM

Wait, capped why? What's the value of an artificial limit?

To reduce the attack surface. If it's not limited you could just create a million of them and ruin the feature for everybody by making Special:Newsletters time out.

To reduce the attack surface. If it's not limited you could just create a million of them and ruin the feature for everybody by making Special:Newsletters time out.

Well, Special:Newsletters should be paginated, so a time-out because of a large number of newsletters would not be an issue.

Now that I'm thinking about it, since creating newsletters is already rate-limited, and ideally the permission should be given out with discretion anyway, is there really a point to a hard limit like this?

ori closed this task as Declined.Apr 2 2016, 4:47 PM

To reduce the attack surface. If it's not limited you could just create a million of them and ruin the feature for everybody by making Special:Newsletters time out.

Well, Special:Newsletters should be paginated, so a time-out because of a large number of newsletters would not be an issue.
Now that I'm thinking about it, since creating newsletters is already rate-limited, and ideally the permission should be given out with discretion anyway, is there really a point to a hard limit like this?

Hm -- right. I forgot about the rate-limiting. In that case, yes, this is probably not necessary.

Qgil added a comment.Apr 3 2016, 7:22 AM

You could simplify things substantially by allowing only one publisher for each newsletter, and making newsletter ownership transferable. This would allow you to get rid of the nl_publishers table entirely (you'd replace it with an additional column in nl_newsletters).

Just fyi / fwiw, we discussed this in the early stages of this project and we agreed that this limit would be too prone to have single publishers vanishing or just taking de facto wiki-vacation, leaving other contributors with a problem that only could be solved by bothering admins. The current setup works better in terms of workflow, imho.