giseldo/neodataset huggingface dataset:
[Story] Players and DMs can change token art

## User Story

As a player or DM, I can change token art

## Details

With this feature, a player or DM can change the art for their character.  Ideally, this will add another token art option that will be available to tokens. From there they should be able to change back and forth between all available images.

## Acceptance Criteria

- [ ] TBD

## Data concerns

TBD - Consider ways to make the UX good while limiting the number of additional art resources added to the service in the case of duplicates.

## Security concerns

TBD

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included
- [ ] Deployed to `edge`
- [ ] Announced

<!-- A note on weights
0 is trivial. Does not involve and code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requies a number of moving parts
8 is for a signifcant amount of work but should with perhaps some unkowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 5.0
[Story] Character Library

## User Story

As a player or DM, I can create new characters in my library and upload images for them.

## Details

A character library is a user-specific repository for tokens. Instead of uploading tokens to the map, they are uploaded to the library. And then they are dragged out of the library onto the map. Libraries are specific to players. They can only see what they have added.

## Steps

Backend

- [x] Investigate a file storage system in Google Cloud
- [x] Build a Simple API that allows file uploads
- [x] Build a local version of the file store
- [x] Build a Google Cloud version of the file store
- [x] Build a MongoDB Ownership provider
- [x] Fix the failing test `PostReturnFileDtoTest`
- [ ] Log the API calls
- [x] Delete file API

Frontend

- [x] Create an add character button
- [x] Open a file upload option
- [x] Chosing a file invokes the API in step 2
- [x] On complete, add a net image to the list of characters
- [ ] [optional] Delete image
- [ ] [optional] Drag image to library
- [ ] [optional] drag image to battlemap

Operations

- [x] Create Cloud Storage Bucket (mythic-table-image-store-edge)
- [x] Grant `allUsers` `Storage Object Viewer`
- [x] Create a new Google Service Account (mythic-table-api-edge@mythic-table.iam.gserviceaccount.com)
- [x] Grant this new account `Storage Object Admin`
- [x] Create a Workload Identity for KSA see: https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity

## Acceptance Criteria

- [x] Users can add characters to their library
- [x] Other users cannot see these in their library
- [x] Characters can be dragged from a library to the map
- [x] Other users can see tokens added to the map from the library

## Data concerns

This will need a new collection in MongoDB to manage this. It should not impact any other data collections.

We will need to have some kind of file service that allows users to upload files.

## Security concerns

Deferred

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included
- [ ] Deployed to `edge`
- [ ] Announced

<!-- A note on weights
0 is trivial. Does not involve and code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requies a number of moving parts
8 is for a signifcant amount of work but should with perhaps some unkowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 8.0
[Story] Players and DMs can edit tokens

## User Story

As a player or DM, I can edit a character's position and properties. These changes are reflected in other connected clients.

## Details

Any token attributes can be changed. These changes are reflected in other user's clients. In the simplest form of this, tokens have a text area in which users can add/remove and update text. Tokens may also have a name.

## Steps

### Frontend 

- [x] Create a pop-up window when a character is double-clicked. The window can be closed.
- [x] Add a name field to the window
- [x] Add a text field to the window
- [x] Add save and cancel buttons to the window
- [x] Cancel closes the window
- [x] Save closes the window and applies the changes to the character
- [ ] Wire up frontend to the `UpdateCharacter`

### Backend

- [x] Rename `LivePlayHub` `RebroadcastDelta` to `UpdateCharacter` (change the Frontend as well.
- [x] Modify the `CharacterDTO` MongoDB model to be a generic json data object. Ensure MoveCharacter still works.
- [ ] Hook up the `UpdateCharacter` to apply a delta to the character objects without specifically doing a move.
- [x] Create a Data Migration script. Consider something like https://www.npmjs.com/package/migrate-mongo or https://github.com/SRoddis/Mongo.Migration
- [ ] Make a script that will migrate characters to the new format

## Acceptance Criteria

- [ ] Users can move a character
- [ ] Users can edit a character's text field
- [ ] Users can change a character's name

## Data concerns

This will cause problems with all of the characters in campaigns. The addition to the project of the migrate scripts will greatly reduce the risk of making this change.

<!-- A note on weights
0 is trivial. Does not involve and code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requies a number of moving parts
8 is for a signifcant amount of work but should with perhaps some unkowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 8.0
[Story] Players and DMs can delete tokens

## User Story

As a player or DM, I can delete a token from the map 

## Details

Doing this removes the token from everyone's map. We need a selected state for this to work. We need the ability to select and deselect tokens. Their selection state should be VERY visible.

## Steps

1. [ ] Make a selection state for tokens. Only a single token can be selected at a time. Single-clicking off the token unselects it.
1. [ ] Delete token by pressing DELETE
1. [x] Create a LivePlayHub API to remove the character
1. [ ] Wire up client to use the new API. Add the listener in the LivePlayDirector

## Acceptance Criteria

- [ ] The delete key causes the selected token to be deleted
- [ ] Other users can see the token is removed

## Data concerns

This should not impact the existing data

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included
- [ ] Deployed to `edge`
- [ ] Announced

<!-- A note on weights
0 is trivial. Does not involve and code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requies a number of moving parts
8 is for a signifcant amount of work but should with perhaps some unkowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 5.0
[Story] Players and DMs can add tokens

## User Story

As a player or DM, I can add a token of my character or monsters onto the map

## Consessions

Tokens will be taken from a list of prebuilt tokens available in the application for all users. This feature does not include uploading new tokens.

## Details

The simplest form of this problem involves dragging an image from a list of available tokens onto the map and it showing up on everyone else's game scene. From there it can be moved around like other tokens.

## Suggested Steps
FE
1. [x] Hardcode a list of available tokens into the client.
1. [x] Design a Token Library UI that is simply a scrollable list of available tokens.
1. [x] Allow the tokens to be draggable
1. [x] Call BE API on new Token creation
1. [x] Listen for new Tokens announced by BE

BE
1. [x] Create a LivePlayHub API to create a token given a token specifier and a location
1. [x] The API must write the new token into the campaign data
1. [x] The API alerts all other clients of the new Token

## Acceptance Criteria
- [ ] User can access a token UI with all possible tokens
- [ ] User can add a token by dragging it onto the map
- [ ] Other users can see the newly added token
- [ ] The token can be dragged and behaves like other tokens in the game
- [ ] Reloading the campaign will show the new token (Reliant on #49)

## Data concerns

Deferred

## Security concerns

Deferred

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included
- [ ] Deployed to `edge`
- [ ] Announced

<!-- A note on weights
0 is trivial. Does not involve and code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requies a number of moving parts
8 is for a signifcant amount of work but should with perhaps some unkowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 8.0
[Story] Merge Request Pipeline

## User Story

As a developer, I have a pipeline that executes against my changes as I create a merge request. Failures in this pipeline prevent the merge.

## Details

https://gitlab.com/help/ci/merge_request_pipelines/index.md#pipelines-for-merge-requests

## Acceptance Criteria

- [ ] Pipeline is run when Merge Requests are made to protected branches like `master`
- [ ] Pipeline failures prevent the merge

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Documentation updated
- [ ] Announced

Story points: 3.0
[Story] Configure a credential helper for Gitlab pipelines

## User Story

As a developer, I can confirm that the docker passwords are not compromised in our pipelines

## Details

Currently, we're using passwords via Gitlab env vars which shouldn't be an issue but for the fact that they are stored in a plain text file. Not the following warning:
```
 $ docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
 WARNING! Using --password via the CLI is insecure. Use --password-stdin.
 WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
 Configure a credential helper to remove this warning. See
 https://docs.docker.com/engine/reference/commandline/login/#credentials-store
 Login Succeeded
```

## Acceptance Criteria

- [ ] We are using the Docker Credentials store for passwords in the Gitlab pipeline
- [ ] `docker login` in our pipeline scripts no longer generates this warning


## Security concerns

This issue addresses an existing security concern

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included
- [ ] Deployed to `edge`
- [ ] Announced

Story points: 5.0
[Story] Campaign Channels limit player-player interactions to within campaigns

## User Story

As a player, my interactions in one campaign are not seen in another campaign.

## Details

Currently, all messages are transmitted to all logged-in players. State changes should be filtered by campaign, so only players in a given campaign's live session should receive those messages. 

Explicitly out of scope:

* Persisting state changes
* Populating a campaign-specific initial state (covered by #48).

## Security concerns

Any messages received from a client should be validated to confirm they are an Owner or Player in the campaign.

## Acceptance Criteria

- [ ] Players in two campaigns don't see token movement nor dice rolls from the other campaign
- [ ] Players in the same campaigns do see token movement and dice rolls from the other players

## Suggested Steps

(draft, needs more than this! Copied from 48)

1. [x] Modify the LivePlayHub to update the campaign data when a token is moved
2. [x] Create an API to return the chat history
3. [x] Onload fetch the chat history and populate the dice roller log
4. [x] Modify the LivePlayHub to log dice rolls to the chat log

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included
- [ ] Deployed to `edge`
- [ ] Announced

<!-- A note on weights
0 is trivial. Does not involve and code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requies a number of moving parts
8 is for a signifcant amount of work but should with perhaps some unkowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 3.0
Create Gitlab Description Templates

# Goal:
To create an easy to use and consistent guideline/template system for creating issues and merge requests
# Background:
I discovered this feature here: https://docs.gitlab.com/ee/user/project/description_templates.html and I thought it would be useful for us.
# Acceptance Criteria:
* [ ] Issues have a series of available templates
1. * [ ] Bug
1. * [ ] Task
1. * [ ] Story
1. * [ ] Epic
* [ ] Merge Requests have a singe template

Story points: 2.0
Recreate edge.mythictable.com

edge.mythictable.com was our development environment.
We need the following:
*  Hook this up to the gitlab pipelines so we get the latest code from master automatically applied to edge.
*  Consider the master/deploy/kubernetes/50-edge.yaml config for help with this.
*  Wire it up to use the edge.mythictable.com domain name.

Story points: 5.0
Autoresolution Stage 1

From the features page:

Foremost in our feature set is our concept of Auto Resolution. This feature will allow player actions to affect objects over which they may not necessarily have control. The principle is very simple. When a player attempts an action which directly affects an authorized object, that action is sent as a message to our servers. If a Game Master is present, the message is sent to him for approval. When enabled, Auto Resolution will automatically approve the action, and the game state will be updated. Of course, we’re not the first ones to think of this, d20pro has this feature, but our feature will do so much more:

1. Our unique history viewer will allow a Game Master to undo unwanted actions quickly.
2. Auto Resolution can be enabled on a player by player basis. This feature allows you to control which players can have their actions automatically resolved or to stop trouble-making players from affecting everyone’s 
3. Auto Resolution works with player to player actions allowing players to affect each other when the Game Master is not online
4. Our unique feedback system notifies the player when an action has been undone.
5. Our system has a redo option for times when a player has corrected the action. This redo will allow them to preserve their original results.
6. Our system will allow the Game Master to edit the action if something has been forgotten. This feature is useful for situations when a buff was forgotten, or the game has some house rule for which the action has not accounted.

This issue will track the initial discussion, requirements analysis and MVP implementation of this central feature.

The slack channel dedicated for it is: #feature-autoresolution

Story points: 20.0
Proposal: Formally adopt Gitflow workflow

Details of the workflow are presented here:

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

The gist of Gitflow is as follows:

*  The `master` branch is used to track releases.
*  The `develop` branch is used to integrate features.
*  Release branches are used to prepare releases before merging into `master`.
*  Development work actually happens in feature branches, based from `develop`.
*  Hotfix branches based from `master` may be used for quick-fix patches.

If the team is on board with this, I'll add documentation to the docs folder.

Story points: 5.0
[Improvement] Automate SMTP relay IP whitelist

<!-- Title suggestion: [Improvement] Name of improvement -->
<!-- Improvement issues are internal initiatives meant to improve code quality, tests, infrastructure or process -->

# Description

Currently, whenever the keycloak pod is recycled, a new public IP is associated with it.
This causes our SMTP provider to deny emails to be sent by KeyCloak.

We currently fix this by manually fetching the new IP and updating the SMTP provider with it.

## The Problem

This is a manual process, and requires access to our SMTP provider and Kubernetes cluster, which only a few people have.

## Background/Current State

There is a rough shell script to fetch the IP address of the pod

```bash
#!/bin/bash

deploy_name='mythic-key'
pod_list=`kubectl get pods -A --no-headers=true | grep $deploy_name`
ns=`echo $pod_list | cut -d' ' -f1`
pod=`echo $pod_list | awk '{print $2}'`

kubectl exec -n $ns pod/$pod -- curl icanhazip.com -s
```

## Solution

Automate the updating of the SMTP relay service

## Additional Information

## Steps

- [ ] TBD



<!-- A note on weights
0 is trivial. Does not involve code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requires a number of moving parts
8 is for a significant amount of work but should with perhaps some unknowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 2.0
[Improvement] Write Script to add Kickstarter backers to KeyCloak Group

<!-- Title suggestion: [Improvement] Name of improvement -->
<!-- Improvement issues are internal initiatives meant to improve code quality, tests, infrastructure or process -->

# Description

We need to add a lot of people to a KeyCloak who supported us on KickStarter.

## The Problem

This will take a lot of time to do manually.

## Solution

Write a script to do it for us

## Additional Information

## Steps

- [X] Put together script that can access users in keycloak realm
- [x] Make the script able to modify a user's groups
- [X] Have the script read from the backer CSV



<!-- A note on weights
0 is trivial. Does not involve code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requires a number of moving parts
8 is for a significant amount of work but should with perhaps some unknowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 2.0
[Story][Web] Add April '22 Financials

[Story][Web] Add April '22 Financials
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As a user, I can see the financials for the month of April '22

## Details

Any related information

## Steps

- [ ] Add financials files
- [ ] Create Links

## Acceptance Criteria (To be checked off **only** during Review)

- [ ] April '22 financials are accessible
    
<!-- A note on weights
0 is trivial. Does not involve code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requires a number of moving parts
8 is for a significant amount of work but should with perhaps some unknowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 2.0
[Story][Web] Add Monday Form

<!-- Title suggestion: [Story][Web] Add Monday Form -->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As a user, I can submit form to monday.com 

## Details

add:

<iframe src="https://forms.monday.com/forms/embed/83213edb05246501663f8334bd260876?r=use1" width="650" height="500" style="border: 0; box-shadow: 5px 5px 56px 0px rgba(0,0,0,0.25);"></iframe>

on a page titled /quest

## Steps

- [ ] Create new page
- [ ] Add iframe

## Acceptance Criteria (To be checked off **only** during Review)

This should be filled in prior to moving into ~"In Progress", but is not required upon first submitting the ticket.
**This list needs to be reviewed and completed by someone who did not work on the ticket.** Please do not pass Acceptance Criteria on a ticket you contributed code to. Ping #qa in Slack or #mythic-table to let someone know that a ticket is completed and ready for ~Review.


- [ ] Form is visible and functioning on '/quest' page
    
<!-- A note on weights
0 is trivial. Does not involve code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requires a number of moving parts
8 is for a significant amount of work but should with perhaps some unknowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 2.0
[Story][Web] Add March 2022 Newsletter

<!-- Title suggestion: [Story][Web] Add March 2022 Newsletter -->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As a user, I can read March 2022 newsletter on the site

## Details

Any related information

## Steps

- [ ] Add March 2022 newsletter

## Acceptance Criteria (To be checked off **only** during Review)

This should be filled in prior to moving into ~"In Progress", but is not required upon first submitting the ticket.
**This list needs to be reviewed and completed by someone who did not work on the ticket.** Please do not pass Acceptance Criteria on a ticket you contributed code to. Ping #qa in Slack or #mythic-table to let someone know that a ticket is completed and ready for ~Review.

- [ ] March 2022 Newsletter is readable
    
<!-- A note on weights
0 is trivial. Does not involve code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requires a number of moving parts
8 is for a significant amount of work but should with perhaps some unknowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 2.0