Why is this feature important to you? How would it benefit the community?

Community Need

The community requires the ability to allow specific individuals and groups building rights within a parcel without requiring that a user be added to the group the land is associated with, nor limiting public access.

Use Cases

Use Case 1: In an educational setting, schools may have certain areas locked off to building however need to provide limited rights to a single individual for the purposes of demonstration or presentation to a public group.

Use Case 2: At a conference, the conference venue is managed by a core builders group, however presenters only require limited rights to rez their presentations and do not require access to be able to make changes to the entire venue.

Use Case 3: Community spaces, such as the Rockcliffe University Sandbox, need to be shared among multiple groups with build rights (e.g. Cag University Students, CD Educational Group, Dr. G’s Research Group, Triton College Chemistry Students, etc.). However the space also needs to be publicly accessible for demonstrations and exhibits.

Core Issue

Currently there is no way to enable public access and community building with individuals or groups outside of the group the parcel is assigned to other than to enable it for everyone. This means that if a parcel needs to be built on and the build access restricted, the only way to do this is through inviting all members to the same group. 

While this is a workable solution for small groups of individuals, it doesn’t work for large groups (e.g. Virtual Worlds Best Practices in Education Conference) where it becomes extremely difficult to get presenters all invited timely to the group they need to be in to rez their presentations or demonstrations. This requires hundreds of hours of cat herding.

In the case of a sandbox, educational classroom, or maker space where multiple groups are sharing access, the only mechanism available is to restrict access to the region or parcel and make building available only to those that have access. This limits the ability to make those space public, while enabling building rights.

For educational organizations, it may not be allowed for instructors to share their student information with other organizations. For example, NOVA University, which uses classroom space at Rockcliffe, can’t require students to become part of the Rockcliffe Student group as this would be considered a privacy violation.

Further, for many long-time residents there is a cultural bias within Second Life that when you get invited into a group, that such invitation is more or less permanent until they choose to leave. This results in psychological injury to people even when they know in advance that such membership was only supposed to be temporary.

In addition, the invitation system to a group is both convoluted and doesn’t work the majority of the time. At VWBPE, we are constantly having to wait until both the inviter and invitee are online at the same time, and in immediate contact with each other, in order to ensure that an invitation to the builders group is received and accepted. On the rare occasions that the invitation actually appears in someone’s notification dialog (which happens less than 50% of the time), clicking on accept doesn’t necessarily add them to the group (which also happens more than 50% of the time). This is further compounded by the fact that group invitations which do show up and are potentially effective are also time limited.

Impact

The impact is that residents are spending an inordinate amount of time fighting with the application to do something as simple as allow a user to rez their presentation or demonstration on land they don’t own, but for which a member of the group can, and should be allowed to provide permissions.

For educational users whose student base is unfamiliar with the application, this is a major source of negative perceptions about the usability of the platform and its capabilities when group invites don’t work. Or worse, appear to work (i.e. be accepted) only to discover that they haven’t been added to the group. Note that this also includes the requirement that someone needs to relog in order to see whether the permissions took effect or not.

For educational institutions, who need to collaborate with other groups in Second Life, this limits the functionality and may result in privacy violations.

For conference organizers, the lack of the ability to better control who has build rights is one of the major sources of labour of effort in both management and communications

How would you like the feature to work?

Functional Requirements

A token system is one potential method of addressing the community need

New Group Profile Features

Group Profile > Roles and Members > Tokens
Group Profile > Roles and Members > Token Members
Group Profile > Roles and Members > Abilities > Parcel Tokens
Group Profile > Roles and Members > Abilities > Parcel Tokens > Create Token
Group Profile > Roles and Members > Abilities > Parcel Tokens > Revoke Token
Group Profile > Roles and Members > Abilities > Parcel Tokens > Delete Token
Group Profile > Roles and Members > Abilities > Parcel Tokens > Assign Token to Individual
Group Profile > Roles and Members > Abilities > Parcel Tokens > Assign Token to Group

Parcel Tokens

A new section in the groups abilities listing that would establish the bitwise permissions associated with managing tokens.

Create Token

Bitwise operator that would indicate a group member is able to create a new token or copy an existing token. This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.

Revoke Token

Bitwise operator that would indicate a group member is able to revoke a single token from token members. This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.

Delete Token

Bitwise operator that would indicate a group member is able to revoke a group of tokens from token members based on the Originating Token UUID and delete the originating token from the token list.

This ability should include a warning dialog that it should be with care (similar to assign member to any role).

This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.

Assign Token to Individual

Bitwise operator that would indicate a group member is able to assign a token to an individual. This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.

Assign Token to Group

Bitwise operator that would indicate a group member is able to assign a token to a group. This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.

Tokens

This new section would be represented in its own tab within Roles & Members and define a token for non-group members that establish limited abilities on land owned by a group. This section would only establish the permissions table (template) on which individual tokens (token instances) would be derived.

Such bitwise abilities to be limited to

• Rez objects and set objects to Group (default, implicit)

• Change Music and Media Settings

• Edit Terrain

• Allow ‘Set Home to Here’ on group land

• Deed Objects to Group

  Plus additional features (not-bitwise)

• Originating Token UUID (system generated)

• Token Name (user assigned)

• Group Associated with the Token (system assigned)

• Group UUID Associated with the Token (system assigned)

• Expiration Type (Constant, GROUP_TOKEN_EXP, 0 = Time Driven, 1 = Date Driven)

• Expiration (dd:hh:mm) [Zero = no expiration]

• Expiration (yyyy/mm/dd) [Zero = no expiration]

  Function Buttons

New Token - Would provide a dialog that would permit the setting of the token parameters. Required Parameters, all

Copy Token - Would provide a dialog that would permit the copying of a token. Required Parameters, New Token Name

Revoke Token - Would expire all tokens based on the Originating Token UUID assigned to any individual user or group.

Delete Token - Would expire all tokens based on the Originating Token UUID assigned to any individual user or group and then remove the token from the token list.

Token Members

This new section would be represented in its own tab within Roles & Members and define the list of members for whom a token has been issued. Similar to how members work, if a group member has the ability to assign a token to an individual or group then the following should occur

Token Invitation

1. Token Invitation Dialog Opens

2. Option of Open Resident Chooser or Open Group Chooser (buttons are grey’d out if not permitted to use)

3. 1. This allows the selection of one or more users added to a list box
   2. For reduction of complexity the invitation should be limited to either all individuals or all groups, but not both

4. Choose Token to assign to them (drop down based on previously defined token templates)

5. Assign Token or Cancel button

   Token Assignment

   If Assign is clicked a new dialog box should open that allows for additional parameters to be set for the assigned token. The template show will be based on the token template previously created and pre-filling in the default values based on that template

   So for example if the GROUP_TOKEN_EXP = 0 and the default is set to 00:01:00 (1 hour) then the user will have the option to either keep the default or change it to a different amount of time.

   Similar if the GROUP_TOKEN_EXP = and the default is set to 2021/12/31 then the user will have the option to either keep the default or change it to a different date. (expiration should be assumed to be 23:59)

   Buttons on this dialog should include Assign or Cancel.

   If Assigned is clicked then for each individual / group in the invitation list, the application should

• Token Name (copied from selected token template)

• Token UUID = update with new UUID per each item in the list

• Token Status (TOKEN_ACTIVE = 1, TOKEN_REVOKED = 0)

• Originating Token UUID (copied from selected token template)

• Group Name = Group Associated with the Token (copied from selected token template)

• Group UUID = Group UUID Associated with the Token (copied from selected token template)

• Start_Timestamp = Set to now()

• End_Timestamp = either now() + expiration time, or use the expiration date

  Tokens would then be automatically assign to each individual user or group in the invitation list (no permission acknowledgement required by the receiving party)

  Token Cross Reference

  A cross reference table would be required to link avatars to tokens they have access to. So for example if a token were given from one group to another group, then each avatar in the receiving group would have the token added to their token access table.

  The number of tokens a user or group might have could theoretically be unlimited however I would suggest limiting the number of tokens a group could have active (i.e. assign) at any one time to 10 for group tokens and 50 for individual tokens as part of a pilot until the performance impacts could be properly assessed.

  Group Changes

  Based on the scenario above, a new user added or removed from a group that has a valid token allocated to it, the application would also need to have that token added or removed from their token cross reference entries.

  Rez and Building Rights

  When checking access and build rights there would need to be an additional check for any tokens in the avatar’s cross reference index. If a valid token is found and the user is not part of the group membership, then those permissions would override any land group restrictions.

  Cron Jobs

  Near-Realtime

  There are two potential methods to approach expiry of tokens.

  The first would be to run a cron type job at the time of use and if the current time is greater than the End_Timestamp, revoke the token and remove the entry from the token cross reference.

  The second is to include in the garbage collection routines that I believe are already running on a near-realtime schedule and include the expiry check as part of one of those routines.

  Daily

  It might be an option to allow revoked / expired tokens to remain visible to the user for a period of 2 days. In which case, a nightly job could be run to remove old tokens from group and user profiles if they have been revoked and are more than 48 hours old.

  Limitations

  This will not work for land allocated to a single individual. Must be group owned.

  Assumptions

  If someone requires access to notices and group chat or other features, such as contributing to an experience, they should become part of that group rather than relying upon a token as a substitute for group membership.

   

{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2021-07-09T13:42:08.015-0500',
  'How would you like the feature to work?': 'Functional Requirements\r\nA token system is one potential method of addressing the community need\r\n\r\nNew Group Profile Features\r\n\r\nGroup Profile > Roles and Members > Tokens\r\nGroup Profile > Roles and Members > Token Members\r\nGroup Profile > Roles and Members > Abilities > Parcel Tokens\r\nGroup Profile > Roles and Members > Abilities > Parcel Tokens > Create Token\r\nGroup Profile > Roles and Members > Abilities > Parcel Tokens > Revoke Token\r\nGroup Profile > Roles and Members > Abilities > Parcel Tokens > Delete Token\r\nGroup Profile > Roles and Members > Abilities > Parcel Tokens > Assign Token to Individual\r\nGroup Profile > Roles and Members > Abilities > Parcel Tokens > Assign Token to Group\r\n\r\nParcel Tokens\r\nA new section in the groups abilities listing that would establish the bitwise permissions associated with managing tokens.\r\nCreate Token\r\nBitwise operator that would indicate a group member is able to create a new token or copy an existing token. This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.\r\n\r\nRevoke Token\r\nBitwise operator that would indicate a group member is able to revoke a single token from token members. This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.\r\nDelete Token\r\nBitwise operator that would indicate a group member is able to revoke a group of tokens from token members based on the Originating Token UUID and delete the originating token from the token list. \r\n\r\nThis ability should include a warning dialog that it should be with care (similar to assign member to any role). \r\n\r\nThis ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.\r\nAssign Token to Individual\r\nBitwise operator that would indicate a group member is able to assign a token to an individual. This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.\r\nAssign Token to Group\r\nBitwise operator that would indicate a group member is able to assign a token to a group. This ability would be defaulted to Yes for Owners and Officers, and No for all other roles unless set.\r\nTokens\r\nThis new section would be represented in its own tab within Roles & Members and define a token for non-group members that establish limited abilities on land owned by a group. This section would only establish the permissions table (template) on which individual tokens (token instances) would be derived. \r\n\r\nSuch bitwise abilities to be limited to\r\nRez objects and set objects to Group (default, implicit)\r\nChange Music and Media Settings\r\nEdit Terrain\r\nAllow ‘Set Home to Here’ on group land\r\nDeed Objects to Group\r\n\r\nPlus additional features (not-bitwise)\r\nOriginating Token UUID (system generated)\r\nToken Name (user assigned)\r\nGroup Associated with the Token (system assigned)\r\nGroup UUID Associated with the Token (system assigned)\r\nExpiration Type (Constant, GROUP_TOKEN_EXP, 0 = Time Driven, 1 = Date Driven)\r\nExpiration (dd:hh:mm) [Zero = no expiration]\r\nExpiration (yyyy/mm/dd) [Zero = no expiration]\r\nFunction Buttons\r\n\r\nNew Token - Would provide a dialog that would permit the setting of the token parameters. Required Parameters, all\r\n\r\nCopy Token - Would provide a dialog that would permit the copying of a token. Required Parameters, New Token Name\r\n\r\nRevoke Token - Would allow for the removal of a token from an individual user or group. \r\n\r\nDelete Token - Would expire all tokens based on the Originating Token UUID assigned to any individual user or group and then remove the token from the token list. \r\nToken Members\r\nThis new section would be represented in its own tab within Roles & Members and define the list of members for whom a token has been issued. Similar to how members work, if a group member has the ability to assign a token to an individual or group then the following should occur\r\nToken Invitation\r\n\r\nToken Invitation Dialog Opens\r\nOption of Open Resident Chooser or Open Group Chooser (buttons are grey’d out if not permitted to use)\r\nThis allows the selection of one or more users added to a list box\r\nFor reduction of complexity the invitation should be limited to either all individuals or all groups, but not both\r\nChoose Token to assign to them (drop down based on previously defined token templates)\r\nAssign Token or Cancel button\r\n\r\nToken Assignment\r\nIf Assign is clicked a new dialog box should open that allows for additional parameters to be set for the assigned token. The template show will be based on the token template previously created and pre-filling in the default values based on that template\r\n\r\nSo for example if the GROUP_TOKEN_EXP = 0 and the default is set to 00:01:00 (1 hour) then the user will have the option to either keep the default or change it to a different amount of time.\r\n\r\nSimilar if the GROUP_TOKEN_EXP = and the default is set to 2021/12/31 then the user will have the option to either keep the default or change it to a different date. (expiration should be assumed to be 23:59)\r\n\r\nButtons on this dialog should include Assign or Cancel.\r\n\r\nIf Assigned is clicked then for each individual / group in the invitation list, the application should \r\n\r\nToken Name (copied from selected token template)\r\nToken UUID = update with new UUID per each item in the list\r\nOriginating Token UUID (copied from selected token template)\r\nGroup Name = Group Associated with the Token  (copied from selected token template)\r\nGroup UUID = Group UUID Associated with the Token  (copied from selected token template)\r\nStart_Timestamp = Set to now()\r\nEnd_Timestamp = either now() + expiration time, or use the expiration date\r\n\r\nTokens would then be automatically assign to each individual user or group in the invitation list (no permission acknowledgement required by the receiving party) \r\nToken Cross Reference\r\nA cross reference table would be required to link avatars to tokens they have access to. So for example if a token were given from one group to another group, then each avatar in the receiving group would have the token added to their token access table.\r\n\r\nThe number of tokens a user or group might have could theoretically be unlimited however I would suggest limiting the number of tokens a group could have active (i.e. assign) at any one time to 10 for group tokens and 50 for individual tokens as part of a pilot until the performance impacts could be properly assessed.\r\nGroup Changes\r\nBased on the scenario above, a new user added or removed from a group that has a valid token allocated to it, the application would also need to have that token added or removed from their token cross reference entries.\r\nRez and Building Rights\r\nWhen checking access and build rights there would need to be an additional check for any tokens in the avatar’s cross reference index. If a valid token is found and the user is not part of the group membership, then those permissions would override any land group restrictions. \r\n\r\nLimitations\r\nThis will not work for land allocated to a single individual. Must be group owned.\r\n\r\nAssumptions\r\nIf someone requires access to notices and group chat or other features, such as contributing to an experience, they should become part of that group rather than relying upon a token as a substitute for group membership.\r\n',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'Why is the feature important\r\nCommunity Need\r\nThe community requires the ability to allow specific individuals and groups building rights within a parcel without requiring that a user be added to the group the land is associated with, nor limiting public access.\r\nUse Cases\r\nUse Case 1: In an educational setting, schools may have certain areas locked off to building however need to provide limited rights to a single individual for the purposes of demonstration or presentation to a public group. \r\n\r\nUse Case 2: At a conference, the conference venue is managed by a core builders group, however presenters only require limited rights to rez their presentations and do not require access to be able to make changes to the entire venue.\r\n\r\nUse Case 3: Community spaces, such as the Rockcliffe University Sandbox, needs to be shared among multiple groups with build rights (e.g. Cag University Students, CD Educational Group, Dr. G’s Research Group, Triton College Chemistry Students, etc.). However the space also needs to be publicly accessible for demonstrations and exhibits. \r\nCore Issue\r\nCurrently there is no way to enable public access and community building with individuals or groups outside of the group the parcel is assigned to other than to enable it for everyone. This means that if a parcel needs to be built on and the access restricted, the only way to do this is through inviting all members to the same group. \r\n\r\nWhile this is a workable solution for small groups of individuals, it doesn’t work for large groups (e.g. Virtual Worlds Best Practices in Education Conference) where it becomes extremely difficult to get presenters all invited timely to the group they need to be in to rez their presentations or demonstrations. This requires hundreds of hours of cat herding.\r\n\r\nIn the case of a sandbox, educational classroom, or maker space where multiple groups are sharing access, the only mechanism available is to restrict access to the region or parcel and make building available only to those that have access. This limits the ability to make those space public, while enabling building rights.\r\n\r\nFor educational organizations, it may not be allowed for instructors to share their student information with other organizations. For example, NOVA University, which uses classroom space at Rockcliffe, can’t require students to become part of the Rockcliffe Student group as this would be considered a privacy violation.\r\n\r\nFurther, for many long-time residents there is a cultural bias within Second Life that when you get invited into a group, that such invitation is more or less permanent until they choose to leave. This results in psychological injury to people even when they know in advance that such membership was only supposed to be temporary. \r\n\r\nIn addition, the invitation system to a group is both convoluted and doesn’t work the majority of the time. At VWBPE, we are constantly having to wait until both the inviter and invitee are online at the same time, and in immediate contact with each other, in order to ensure that an invitation to the builders group is received and accepted. On the rare occasions that the invitation actually appears in someone’s notification dialog (which happens less than 50% of the time), clicking on accept doesn’t necessarily add them to the group (which also happens more than 50% of the time). This is further compounded by the fact that group invitations which do show up and are potentially effective are also time limited.\r\nImpact \r\nThe impact is that residents are spending an inordinate amount of time fighting with the application to do something as simple as allow a user to rez their presentation or demonstration on land they don’t own, but for which a member of the group can, and should be allowed to provide permissions.\r\n\r\nFor educational users whose student base is unfamiliar with the application, this is a major source of negative perceptions about the usability of the platform and its capabilities when group invites don’t work. Or worse, appear to work (i.e. be accepted) only to discover that they haven’t been added to the group. Note that this also includes the requirement that someone needs to relog in order to see whether the permissions took effect or not. \r\n\r\nFor educational institutions, who need to collaborate with other groups in Second Life, this limits the functionality and may result in privacy violations. \r\n\r\nFor conference organizers, the lack of the ability to better control who has build rights is one of the major sources of labour of effort in both management and communications\r\n',
}