giseldo/neodataset huggingface dataset:
[Story] Revise Campaign Management Screen

## User Story

As a player, I see only the relevant campaigns that I am apart of on the campaign management screen. It is easy for me to create a new campaign and I can find out how to join existing games easily. I can also upload an image to as as a display image for campaigns.

## Details

Currently, we're displaying all campaigns.  This will not do when we release First Playable. This is the first experience more players will have with this product. We should allow them to test it out very easily.

## Steps

- [x] On campaign features page a "choose file" and "upload" buttons should be added to "Create New Campaign" section in order to select a banner image, upload it, and associate it to the campaign which has been created.

- [x] Users should have a main Campaign page where he/she can see the created campaigns, and interact with them.

- [x] Once a campaign is created it should have a button like "info" to display all the information about it, such as campaign creation date, last time played, description, invite link, delete campaign, and play button.

- [x] Clicking on "Delete" button should remove a campaign from the main view campaing page, and clicking on "Edit" button should update campaign's content such as description, banner, and etc.

- [x] Campaign Description textarea on "Create New Campaign" page should have enough "cols", "rows" and length in order to convey necessary information for the campaign.

- [x] Menu creation on header next to the logo.

- [x] Start Date and Last Played must be implemented on campaign's description field.

- [x] Campaign's images should not be stretched or skewed.


## Acceptance Criteria

- [x] User can upload image as a banner for their campaign. It should be displayed in the campaign list page without distortion (Uploaded banner should be displayed in campaigns list page without distortion.)
- [x] User can create a campaign description which scan be viewed entirely in the campaign info card. (campaigns description should fit in textarea field in campaigns list page)
- [x] User can display additional information not shown in the campaign card on an Info Card. (info button should display all the campaign's information on the right side of the page and having scroll down feature.)
- [x] User can enjoy a campaign manager which matches the light-theme standards. (Light-theme (Needs clarification @mfaulise))
- [x] User can see the date the campaign was created on and the last date the campaign was played. (Display campaigns' creation and 'last played' dates correctly.)
- [x] User can delete the campaign through targeted clicking/2 step deletion verification and have it removed from the campaign list page (Clicking "Delete" in the Info pop-up removes the campaign from the list page. )
- [x] User can access the Campaign Editor through the Info Card. (Clicking "Edit" in the Info pop-up brings the user back to the Campaign editor screen.)

Story points: 5.0
[Story] Change the primary branch from 'master' to 'main'

## User Story

As a developer, I refer to `main` as the default branch for Mythic Table

## Problem to solve

This story follows the reasoning of the following Gitlab issue: https://gitlab.com/gitlab-org/gitlab/-/issues/222204

The default branch of this repository is current master. We should move to a different default branch name for Mythic Table for two reasons:

1. master is not easily understood by people new to Git, and is not a ubiquitous term in technology (master is more easily associated with primary/secondary configurations)
1. master has multiple meanings in English, including master/slave. Although Git does not use master/slave terminology, such terminology was common until recently. Use of master/slave terminology has been removed in recent versions of many major software projects because it is not technically descriptive, precise, and avoids needlessly referencing the awful history and impact of human/slavery which continues to be felt by people all over the world.

## Steps

- [x] change pipeline to use main instead of master for deployment
- [x] create main branch from master
- [x] make main the default branch
- [x] update release processes to use main branch
- [x] update Developer documentation
- [ ] ... probably many other steps
- [x] remove master branch

<!-- 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: 2.0
Repair edge environment

<!-- Title suggestion: [Story] Name of story -->
## User Story

As a player/user/DM/developer, I can ... 

## Details

Any related information

## Acceptance Criteria

- [ ] Use case ...
- [ ] Use case ...
- [ ] Use case ...

## Data concerns

Deferred

## Security concerns

Deferred

## Stages

- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included

<!-- 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: 2.0
[Story] Enable Development without the Auth Service

<!-- Title suggestion: [Story] Name of story -->

## User Story

As a developer, I can bring up MT in the dev env without needing to use the auth service.

## Details

The additional step of authenticating while developing is tedious and adds friction to the process. The auth service is in a completely separate project at this point, so development of it should be somewhat separate.

## Acceptance Criteria

- [ ] Spin up a functioning MT FE and BE without needing to auth the test the features.
- [ ] Turning auth on/off is set by the environment name: development, edge, etc.

## Security concerns

We cannot let this land in production at any point so thorough code review and testing should be done.

## 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 requires a number of moving parts
8 is for a significant 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
[Story] Organize Structure of Vue Project

<!-- Title suggestion: [Story] Name of story -->

## User Story

As a developer, I can know where to find the files I'm looking for and where to put the files I've created.

## Details

With so many cooks in the kitchen, the counters have gotten messy! Let's plan out a directory structure that makes sense for the app, and implement it to keep our workspace clean, for ourselves and for future developers. My first draft of a suggestion looks like this:

```
/debug
/gameplay -- for things that only happen in the gameplay view
  /model
  /view
  /controller
/views
/components
/auth
/router
/store
```

I realize that there are some parts I'm missing (where do the rulesets live? character sheets can be edited outside of gameplay). But people smarter than me can figure that out. We could consider a README in the root of each directory explaining what does (and doesn't) belong in this directory.

## Acceptance Criteria

- [ ] Developers have a clearer idea of what goes where.
- [ ] There is accompanying documentation to support this is an easy to find location.

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Deployed to `edge`

Story points: 3.0
[Story] Create onboarding issue template


## User Story

As a new developer on the Mythic Table project, I have an onboarding issue assigned to me that walks me through everything I need to know to get up and running.

## Details

By creating a template for onboarding issues, the mythic team can help newcomers to feel comfortable by walking through some frequent developer activities and learn about the good practices and patterns used in Mythic Table development.
This template provide a way to make sure the new developer is ready to start contributing in development, this is accomplished by creating a list of activies that they need to complete.

## Acceptance Criteria

New developers are assigned to an issue with an onboarding template that should let them...

- [x] ... know how to find the Mythic Table Website;
- [x] ... find the MT's social medias;
- [x] ... know how to communitate through Slack and Discord;
- [x] ... know all the available channels from Slack;
- [x] ... know how to find the Mythic Table Documentation;
- [x] ... know how versioning with Git works;
- [x] ... know how to create branches and merge requests with the changes;
- [x] ... know how to review/approve merge requests;
- [x] ... know how to use the boards to organize issues, bugs and activies;
- [x] ... and get up to date with the current Mythic's milestones and objectivies.

<!-- 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: 1.0
[Story] Set up staging environment

<!-- Title suggestion: [Story] Name of story -->

## User Story

As a developer, I can use built-in Vue debugger tools on the staging site.

## Details

edge.mythictable.com is currently running in production mode - the default "npm run build" exports the app with that mode. We want edge.mythictable.com to run in a new **staging** mode, to be created. It will act like development mode but use the authentication variables that are set in production mode.

## Acceptance Criteria

- [ ] We can use the Vue debugger browser extension tools on edge.mythictable.com
- [ ] Authentication for edge.mythictable.com still works as it does now

## 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: 2.0
[Story] Modify default campaign data to enable trouble-hunter stream

## User Story

As a player in trouble-hunters, I can use https://edge.mythictable.com/ to play our game

## Details

Currently, the default campaign is a single map with a couple of static tokens. We will need to change the map and add tokens for each character and a couple of enemies.

We will also need to hook up the movement syncing between clients.

We will also need to add the user name to the dice rolling results.

## Acceptance Criteria

- [x] All player characters have tokens
- [x] There are a couple of monsters tokens (Use colored tokens for now)
- [x] The map reflects the map needed for Trouble Hunters
- [x] Movement on one client is reflected on all clients
- [x] When a die is rolled, the username of the roller is shown

## Stages

- [x] Planned accepted
- [x] Code Complete
- [x] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included
- [ ] Deployed to `edge`
- [ ] Announced

Story points: 3.0
[Story] Finalize CSS architecture

## User Story

As a front-end developer, I want to reuse some styles across multiple components/layouts, while others will be specific to a particular component.

## Details

We currently have shared styles in src/assets/main.scss (in the Campaign Management branch, soon to be merged to master) and component-specific styles (e.g. layouts) in the individual components.

We should create a minimal wiki space for our CSS Architecture to document this breakdown. We can expand it in the future as our architecture evolves.

## Acceptance Criteria

- [x] A CSS Architecture page documents the location of shared CSS components
- [x] A CSS Architecture page describes criteria for keeping CSS elements in the shared file vs. individual components

## Stages

- [x] Planned accepted
- [x] Wiki Complete
- [ ] Announced

Story points: 5.0
[Story] Campaign CRUD and data backend

## User Story

As a user, I can I can add, edit and removed campaigns from the campaign management scene 

## Details

Campaigns will have the following information:
- Title
- Description
- Image URL
- Created and Last modified date
- A list of player

For now we will use imgur to host the images for the site. The list of players can be chosen from the list of registered users in the application.

This is all placeholder and requires no specific UI at this time except the UI required to confirm the functionality.

This feature will include persistence in some manner.  This could be in memory persistence for the time being.

## Steps

- [x] Define models and DbContext
- [x] Define Controllers
- [x] Unit test at controller level
- [x] Add players
- [x] Remove players
- [x] Add Authentication and automatically associate owner
- [ ] Add Vue elements

## Acceptance Criteria

- [ ] The user can see a list of their campaigns
- [ ] The user can edit a campaign as described above
- [ ] The user can delete a campaign
- [ ] The user can add a new campaign
- [ ] The user can enter the campaign but it takes them into the default LivePlay session

## Data concerns

The data store chosen for this store is somewhat irrelevant, but a adequate abstraction layer is required.  Consider the following guide: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.1

It's possible to set up a mongodb docker container as a simple first pass for this.

## Security concerns

Intentionally ignored

## Stages

- [ ] Planned accepted
- [ ] Code Complete
- [ ] Contains tests
- [ ] Documentation updated
- [ ] Contains log changes
- [ ] Analytics included
- [ ] Deployed to `edge`
- [ ] Announced

Story points: 20.0
[Story] Add Google Analytics to app, separating Dev and Prod

<!-- Title suggestion: [Story] Name of story -->

## User Story

As a user, my usage of the app is tracked against Google Analytics for production only.
As a developer, my usage should be tracked against a separate, Developer GA property.

## Details

We're going to use [vue-gtag](https://github.com/MatteoGabriele/vue-gtag) to manage our events, and we should be able to swap out this variable based on if we're running in prod or dev.

## Acceptance Criteria

- [ ] Developers can add analytics events to be pushed from their local builds, and those events show up on the "App - Dev" property in GA
- [ ] Anything on edge.mythictable.com should also get pushed to "App - Dev"
- [ ] When we have a "Production site" for first playable (play.mythictable.com?) those events should be pushed to "App - Prod"

## 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
[Story] DMs can move from scene to scene

## User Story

As a player and I switch from scene to scene 

## Details

### Current state

Currently, we have a single default scene made. You can edit the background and the scale. Changes to these are instantly reflected in each other client.

### Next Steps

In order for this feature to work, players need the ability to add scenes. Once they can add additional scenes, they should also be able to remove the scenes they have added.

Once that is done players should be able to move from scene to scene by selecting them, clicking once or double-clicking. This will change them from scene to scene.

There should also be an option for bringing all the connected players to the focused scenes or showing with players are on which scenes.

### UI Needs

We will need the ability to do the following:

- [x] Enable Scene Editing 
- [x] Enable Change to Scene
- [x] Enable the ability to move all players to a scene
- [x] Feedback which scene you are on
- [x] Feedback which scenes others are on
- [x] Feedback when you're been transferred to a new scene
- [x] An option to toggle automatic scene transferring

## Steps

### Backend

- [x] This will use the scene collection and the collection API for adding and removing scenes
- [x] LivePlay API for adding and removing collections will be needed
- [x] A LivePlay API will be needed to handle scene traversal This can be done with a single campaign collection as well

### Frontend

- [x] Clicking add scene opens a blank scene editor window
- [x] Editor window changes `Save` button to `Add`
- [x] Cancel closes window without adding the scene
- [x] Adding sends the data to the server as a add collection LivePlay API call
- [x] Listen for Collection Item Added and update the scene library
- [x] Decide if single or double click is for scene editing @calamity_jane 
- [x] Add a `selected` state for the Scene Items
- [x] Select Scene item on click
- [x] Change Scene on Select
- [x] Send a scene change message to the server
- [x] Listen to the scene change from server to change to a new scene

### Independent Scene Movement

With this feature, players can be on different scenes

- [x] Define a campaign collection for tracking player's scene activity
- [x] Show player indicators on scenes in library
- [x] Define a UX for bringing players over to a specific scene
- [x] Wire up the scenes to the collection API
- [x] Player change scene - Other players see it in their scene library
- [x] Player is moved to a scene - their active scene changes
- [ ] [Optional] Players can lock themselves so they are not moved from scene to scene
- [ ] [Optional] Locked players have a special indicator showing they cannot be moved

## Acceptance Criteria

- [x] Player's can add new scenes
- [x] Players can move between scene
- [x] Players can move other players between scenes

Story points: 5.0
[Story] DMs can edit maps size and properties

## User Story

As a DM, I can edit maps size and properties

## Details

For the purposes of First Playable, a map has two things: A background image and a play surface (grid). Map editing must support changing both of these things and persisting the changes. 

## Tasks

Backend: 

- [x] Stub map/scene APIs
 - [GET] api/campaigns/###/scenes
 - [Live] `AddScene`, `RemoveScene`, `UpdateScene`, `MoveToScene`
 - [Event] `SceneAdded`
 - [Event] `SceneRemoved`
 - [Event] `SceneUpdated` or plugged into `ConfirmOpDelta`
- [x] InMemory implementation
- [x] Decouple campaign collections from users @jhatheway or @mfaulise 
- [x] MongoDB implementation

Frontend:

- [x] Define and create a default scene when campaigns are created
- [x] Have the UI automatically get scenes on load as we do with the characters for the campaign and the rolls
- [x] Build getScenes in the UI to populate the Scene Library
- [x] Double click a scene in the library to open a scene editor window
- [x] Build the scene editor window 
- [x] Wire up the editor window to update the scene on save
- [x] Wire up the editor window to send an update to the backend on save
- [x] Change the image associated with a map
- [x] Change the grid parameters (height and width of grid)

## Acceptance Criteria

https://edge.mythictable.com

- [x] Users can change background image of a map/scene
- [x] Users can change the size of a map/scene
- [x] Map/scene changes are persistent between sessions 
- [x] Map/scene changes are reflected in the clients of other users 

## Data concerns

Maps have different properties than characters, so it will be necessary to make any additions for that purpose in such a way that the files API remains the same as it is after #60.

## Security concerns

Same as character creation.

## Stages

- [x] Planned accepted
- [x] Code Complete
- [x] Contains tests
- [ ] Documentation updated
- [x] Contains log changes
- [ ] Analytics included
- [x] 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] Map Library

## User Story

As a DM, I can add a new map to my map library.

## Details

This story introduces another library window. This window will be used to manage DM and Player maps. Instead of the simple file interface for the character library displays, this one should reference campaign map objects which inturn reference an image file for display in the list and as the base image for the map.

In order to do this, we will need to add a context to the file upload to distinguish between character images and maps images. This will be required on the API level and propagated down to the server implementation.

We will also need APIs to create map objects in the campaign. 

On the UI side of things, we'll have a window titled `Map Library`. It will have a scrollable selectable list of maps displayed by their image. There will be an Add Button on the bottom

Clicking the add button opens a dialog box with the map properties, but this will only have an image upload option at this stage.

## Steps

Frontend:

- [x] Window/list of maps
- [x] Button/interface to add map
- [ ] Concept of "choosing" a map (for editing or otherwise)
- [ ] (Optional) Button/interface to delete map

Backend:

- [x] API to return all maps or scenes
- [x] API to add a map or scene
- [ ] (Optional) API to delete a map or scene
- [x] Create a InMemory datastore for maps
- [x] Create a MongoDB datastore for maps

## Acceptance Criteria

- [ ] User can add a map
- [ ] User sees all maps available
- [ ] When a user goes to a new campaign he sees all of his available maps

## Data concerns

This may use the same API as the character images.  In this case we will need to differentiate the two with some kind of tag or path.

## Security concerns

Intentionally ignored

Story points: 5.0