Difference between revisions of "Features/Join Limits"
m (FGrose moved page Features/JoinLimits to Features/Join Limits: deCamelCase) |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | <noinclude> | + | <noinclude>[[Category:Feature Page Incomplete]] |
| − | [[Category:Feature Page Incomplete]] | + | [[Category:FeatureLanded|Join Limits]] |
| − | [[Category: | + | [[Category:Features requested by OLPC AU]]</noinclude> |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Summary == | == Summary == | ||
| Line 20: | Line 15: | ||
* Last updated: (5 November 2013) | * Last updated: (5 November 2013) | ||
* Percentage of completion: 0% | * Percentage of completion: 0% | ||
| − | |||
== Detailed Description == | == Detailed Description == | ||
| Line 28: | Line 22: | ||
If and only if the maximum_participant field is set is it used to set the limit of joiners. | If and only if the maximum_participant field is set is it used to set the limit of joiners. | ||
| + | |||
| + | Also see [[Features/Can share]]. The difference here is that I am proposing to leverage the maximum_participants setting as opposed to creating a new field in activity.info. Also, this is not just a binary share/no share. | ||
== Benefit to Sugar == | == Benefit to Sugar == | ||
| Line 60: | Line 56: | ||
== Comments and Discussion == | == Comments and Discussion == | ||
| + | * http://lists.sugarlabs.org/archive/sugar-devel/2013-November/045586.html | ||
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] | * See [[{{TALKPAGENAME}}|discussion tab for this feature]] | ||
---- | ---- | ||
| − | |||
Latest revision as of 14:38, 20 April 2015
Summary
Honor limits to the number of buddies who can join a shared activity.
Owner
- Name: Walter Bender
- Email: <walter AT sl.o>
Current status
- Targeted release: (1.02)
- Last updated: (5 November 2013)
- Percentage of completion: 0%
Detailed Description
Honor maximum_participants limit
At the request of OLPC AU, we'd like to honor the maximum_participants limit. Right now that limit is only used to determine whether or not an activity can be shared, but not the number of users who can join. This feature would inform users trying to join an activity that has already reached its maximum that the maximum number of sharers has been reached.
If and only if the maximum_participant field is set is it used to set the limit of joiners.
Also see Features/Can share. The difference here is that I am proposing to leverage the maximum_participants setting as opposed to creating a new field in activity.info. Also, this is not just a binary share/no share.
Benefit to Sugar
There are limits to the useful number of people who can join an activity. Some 2-player games, for example, are not able to restrict a third player from joining.
Scope
Not sure of all the code that is impacted. Depending upon how maximum_participants is exposed in the toolkit, it may be necessary to modify activity.py. Otherwise, most of the changes will happen in jarabe/view.
How To Test
Maximum instances:
- Find an activity with maximum_participants set to > 1.
- Try to join more than maximum_participants and observe an alert
User Experience
The direct impact on the user will be that they are alerted when maximum activities has been exceeded.
Dependencies
No new dependencies
Contingency Plan
None.
Documentation
Release Notes
Comments and Discussion
- http://lists.sugarlabs.org/archive/sugar-devel/2013-November/045586.html
- See discussion tab for this feature