giseldo/neodataset huggingface dataset:
[Story] [Web] Discord Timestamp Syntax Generator

<!-- Title suggestion: [Story] [Web] Discord Timestamp Syntax Generator -->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As a User of the Mythic Table Discord I am often unable to correctly identify dates/times of occurring events / town halls / etc. 

## Details

Especially when scheduling Town Halls or Trying to Find Groups, individuals have a hard time expressing timezones / locales. With the tool in question our server users would be able to coordinate times much more easily.

Uploading/enabling this will also help @reid.blaine08 to tactical onboard himself to the systems, if he agrees to own this ticket.

## Steps

- [ ] Utilize this open-source software: https://github.com/DJDavid98/HammerTime
- [ ] Create a page on the mythictable.com website dedicated to discord chat syntax timestamps.

## Acceptance Criteria (To be checked off **only** during Review)

There should be a page on the site that allows us to use a system similar to the system displayed here: https://hammertime.djdavid98.art/ but native to our web presence.

<!-- Some notes on Acceptance Criteria (AC)
If you are having issues creating Acceptance Criteria, please review [Some notes on Acceptance Criteria(AC)](https://gitlab.com/mythicteam/mythictable/-/wikis/qa/acceptace-criteria). Don't hesitate to ask for AC review or assistance in #qa, it's what we're here for.
-->

- [ ] Given: Samples Criteria exists in template
    - [ ] And: it has not been removed
    - [ ] When: the ticket has been submitted
    - [ ] Then: Someone else should update this
    - [ ] And: include acceptable Acceptance Criteria
    
<!-- 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] 2021 Reports

<!-- Title suggestion: [Story] [Web] 2022 Reports-->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As an "owner" not a "customer" I have no access to the nov/dec 2021 monthly reports, nor is there a location to put them when they are ready for viewing.

## Details

We need new site infrastructure put in place so the monthly reports can be added where appropriate.

## Steps

- [x] Ensure all 2021 reports are displayed and linked to appropriately. (@reid.blaine08)
- [x] reports/2021/index
- [x] /finance/index
- [x] List months that have no report available. (@reid.blaine08)
- [x] Add 2021 reports where appropriate. (@mfaulise)
- [x] Link where appropriate (if not complete). (@mfaulise)

## Acceptance Criteria (To be checked off **only** during Review)

As "an owner" I am able to access the appropriate report locations and view the reports in question for the year 2021.

<!-- Some notes on Acceptance Criteria (AC)
If you are having issues creating Acceptance Criteria, please review [Some notes on Acceptance Criteria(AC)](https://gitlab.com/mythicteam/mythictable/-/wikis/qa/acceptace-criteria). Don't hesitate to ask for AC review or assistance in #qa, it's what we're here for.
-->

- [ ] Given: Samples Criteria exists in template
    - [ ] And: it has not been removed
    - [ ] When: the ticket has been submitted
    - [ ] Then: Someone else should update this
    - [ ] And: include acceptable Acceptance Criteria
    
<!-- 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] 2022 Reports

<!-- Title suggestion: [Story] [Web] 2022 Reports-->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As an "owner" not a "customer" I have no access to the 2022 monthly reports, nor is there a location to put them when they are ready for viewing.

## Details

We need new site infrastructure put in place so the monthly reports can be added where appropriate.

## Steps

- [x] Clone /reports/2021 into /reports/2022 (@reid.blaine08)
- [x] Add Copy to /reports/index for 2022 (@reid.blaine08)
- [x] Link Copy as indicated above to /reports/2022/index/ (@reid.blaine08)
- [x] Update /finance/index to include 2022  (@reid.blaine08)
- [x] Add 2022 reports where appropriate. (@mfaulise)
- [x] Link where appropriate (if not complete). (@mfaulise)

## Acceptance Criteria (To be checked off **only** during Review)

As "an owner" I am able to access the appropriate report locations and view the reports in question for the year 2022.

<!-- Some notes on Acceptance Criteria (AC)
If you are having issues creating Acceptance Criteria, please review [Some notes on Acceptance Criteria(AC)](https://gitlab.com/mythicteam/mythictable/-/wikis/qa/acceptace-criteria). Don't hesitate to ask for AC review or assistance in #qa, it's what we're here for.
-->

- [ ] Given: Samples Criteria exists in template
    - [ ] And: it has not been removed
    - [ ] When: the ticket has been submitted
    - [ ] Then: Someone else should update this
    - [ ] And: include acceptable Acceptance Criteria
    
<!-- 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] Subscribe - Mailing List Location

<!-- Title suggestion: [Story] [Web] Subscribe - Mailing List -->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As a user it is easy to miss the subscription / mailing list.

## Details

The mailing list is difficult to find and due to its prominent use should be featured. Potentially in a Modal Window?

## Steps

- [ ] Update the presence of the mailing list subscription in a powerful but _non-intrusive_ way.
- [ ] Create alternate view for mailing list opt-in.
- [ ] Remove current mailing list opt-in menu (if necessary.)

## Acceptance Criteria (To be checked off **only** during Review)

As the end user I should be able to easily identify that the Mythic Table website has a prominent and active mailing list. I shouldn't need to search the page. The feature should be un-intrusive but easily identifiable. 

<!-- Some notes on Acceptance Criteria (AC)
If you are having issues creating Acceptance Criteria, please review [Some notes on Acceptance Criteria(AC)](https://gitlab.com/mythicteam/mythictable/-/wikis/qa/acceptace-criteria). Don't hesitate to ask for AC review or assistance in #qa, it's what we're here for.
-->

- [ ] Given: Samples Criteria exists in template
    - [ ] And: it has not been removed
    - [ ] When: the ticket has been submitted
    - [ ] Then: Someone else should update this
    - [ ] And: include acceptable Acceptance Criteria
    
<!-- 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: 3.0
[Story] [Web] Update Road Map

<!-- Title suggestion: [Story] Update Road Map -->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As a visitor, I can see the road map is being worked on.

## Details

The current road map is out of date (https://www.mythictable.com/roadmap/)

## Steps

- [x] Update road map

## Acceptance Criteria (To be checked off **only** during Review)

As the end user, I can see a message stating the section is being updated and will be available shortly.

<!-- Some notes on Acceptance Criteria (AC)
If you are having issues creating Acceptance Criteria, please review [Some notes on Acceptance Criteria(AC)](https://gitlab.com/mythicteam/mythictable/-/wikis/qa/acceptace-criteria). Don't hesitate to ask for AC review or assistance in #qa, it's what we're here for.
-->

<!-- 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] Permissions layer for collections

<!-- Title suggestion: [Story] Name of story -->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story
* As an owner of an object in the library, I can update and delete the object. No one else can.
* As an owner of an object in the map or as the Game Master, I can update and delete the object. No one else can.

## Details

Suggested solution is a "permissions layer AKA super lightweight ACL" which sits in front of the collections functionality and performs operations for adding and removing permissions on collections items for updating and deleting those items.

Designed modularly so that we use a default "permissions layer / ACL" logic being used.

## Steps
- [ ] Implement the "permissions layer" logic in the back-end as outlined in the Epic/Story.

## 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.

<!-- Some notes on Acceptance Criteria (AC)
If you are having issues creating Acceptance Criteria, please review [Some notes on Acceptance Criteria(AC)](https://gitlab.com/mythicteam/mythictable/-/wikis/qa/acceptace-criteria). Don't hesitate to ask for AC review or assistance in #qa, it's what we're here for.
-->

- [ ] Given: Samples Criteria exists in template
    - [ ] And: it has not been removed
    - [ ] When: the ticket has been submitted
    - [ ] Then: Someone else should update this
    - [ ] And: include acceptable Acceptance Criteria
    
<!-- 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
[Polish] Add orange logo for T&R Day

<!-- Title suggestion: [Polish] Name of improvement -->
<!-- Polish issues track work to improve the look, feel and usability of existing features -->

# Description

For Truth and Reconciliation day in Canada, it would be good to change the mythic logo on the site to orange, and redirect on click of that to our land acknowledgement and Canada's call to action.

## Current State


## How should it look/feel?

How to Fix it?

Pictures?


<!-- 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
[Improve] Split our deployment.yaml into multiple files

<!-- Title suggestion: [Improvement] Name of improvement -->
<!-- Improvement issues are internal initiatives meant to improve code quality, tests, infrastructure or process -->

# Description

Separate the deployment by kind

## The Problem

The single deployment.yaml is getting a little complicated

## Background/Current State

Everything is in the same file

## Solution

Make a folder (deploy?), and make a new folder for each kind

Change the `gitlab-ci.yml` apply to:
```
kubectl --token=$KUBE_TOKEN apply -f deploy? --recursive
```

## 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
[Improve] Remove the duplication in the gitlab yaml for the First Playable

<!-- Title suggestion: [Improvement] Name of improvement -->
<!-- Improvement issues are internal initiatives meant to improve code quality, tests, infrastructure or process -->

# Description

Remove the duplication in the gitlab yaml (`.gitlab-ci.yml`) for the First Playable

We want to remove this duplication to make it easier to release different versions.

One of the things we also want to do is to get away from making releases via branching. 
Instead we can use the gitlab `Release` feature which should work via tags. https://docs.gitlab.com/ee/user/project/releases/

We can consider switching to Rules. https://docs.gitlab.com/ee/ci/yaml/#rules


## The Problem

The following stages are duplicated:
- deploy (deploy:fp)
- build:client (build:client:fp)
- package (package:fp)
- containerize (containerize:fp)

## Background/Current State

Hack for FP release

The way things currently work is that the branch for fp `releases/firstplayable` is specified in the `only`
field of the jobs.

```
build:client:fp:
    ...
    only:
        - releases/firstplayable
```

## Solution

We need to be able to:
* parameterize `- npm run build -- --mode firstplayable` in the `build:client` or
* Remove the need for the `.env` files altogether or
* Use gitlab variables to control the build https://docs.gitlab.com/ee/ci/variables/

There will be some Frontend work
- We need to get away from using the node .env files

## Additional Information

## Steps

- [ ] Stop referencing the docker image by `latest`



<!-- 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: 5.0
[Polish] Tutorial map has no invite ui.

<!-- Title suggestion: [Polish] Name of improvement -->
<!-- Polish issues track work to improve the look, feel and usability of existing features -->

# Description

Clean up the UX to either allow or dis-avow inviting users to the tutorial.

1 of these:
1. Add an explicit part of the tutorial that covers inviting friends and allow invites to the tutorial.
2. Driving them to make their own campaign, and instead prompt how to invite on first campaign creation.

## Current State

Currently we are treating the tutorial game differently, in regards to invites etc.

It is currently impossible to invite a friend to the tutorial game.

![image](/uploads/348cd1efe473756d0730ce7e32f5608f/image.png)

This is causing users in the discord to feel confusion as they can't work out how to share a link, so they attempt to share the 'game' link in the address bar. The user being invited is [not greeted with a helpful error](https://gitlab.com/mythicteam/mythictable/-/issues/470) either.

## How should it look/feel?

How to Fix it?

Ideally the tutorial game should match a regular game as far as possible.
It's entirely likely that a user will run the tutorial game, and attempt to edit it into their own campaign as they learn the system.

It may be worthwhile warning, or preventing this somehow, if the intention is to continually reset the tutorial, in order to update all players with the latest changes.

They may want to run through a tutorial with a friend, if they are discovering mythic together for the first time.

So 2 options:

1. allow tutorial to invite players, and give them some other method of warning against using it as a 'real' game. (assuming we want to dis-avow 'evolving' a tutorial into a full game.

2. Do not allow tutorial campaigns to invite other players, BUT include UI in the same areas, stating that invites are disabled, and why.

<!-- 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: 3.0
[Story] Token Visibility

# User Story

As a DM or a token owner, I can toggle the token visibility

- [x] This visibility state is clear and recognizable 
- [x] Invisible tokens can only be seen by owning player **or with GM permissions**

## Steps

- [x] Data
  - [x] Look through token data and find where a `hidden` tag should be added.
  - ~~Make available at the `character` level so it can be `hidden` in the library~~
- [x] Permissions
  - [x] Always token owner
  - [x] With permission GM can always see as well.
    - Possibly do not make visible to GM in the library?
- [x] Tokens
  - [x] Filter through all tokens
    - [x] When `hidden` and not owner or GM without permission token is not added to canvas
    - [x] When `hidden` and owner or GM with permission render token at reduced opacity
      - [x] Add a symbol when hidden and in the library, not opacity
    - [x] Functions even if `hidden` property has not been added to `data`
      - [x] Assume not hidden
  - [x] Layer Rework
    - Scene already has to much responsibility
    - [x] Move tokens into their own component to house the logic associate with this update
    - [x] Remove current responsibility of tokens out of Scene as much as possible

## Acceptance Criteria (To be checked off **only** during Review)

- [x] Character Library
  - [x] Double click opens Character Editor
  - [x] Can set to `Public` or `Private`
  - [x] `Private` has an icon in list
  - [x] `Public` has a default look in list
  - [x] User can tell difference between the two in the editor window
  - [x] `Private` characters cannot be seen by non-owners. 
  - [x] GM Permissions do not not effect visibility
- [x] Token on Map
  - [x] Double click opens Character Editor
  - [x] Can set to `Visible` or `Hidden`
    - This is doing effectively the same work in different context
  - [x] `Visible`
    - [x] Default look
    - [x] Should be fully opaque to all users
  - [x] `Hidden`
    - [x] Should be at 50% opacity
    - [x] Should not be visible to any player who isn't the owner of the token on map
    - [x] With GM permission active, any GM should also be able to see the token on map
  - [x] Default settings for token spawn
    - Character List - `Public`
      - [x] Token is `Visible`
    - Character List - `Private`
      - [x] Token is `Hidden`

Story points: 2.0
[Improvement] Feature Flags need Environment specific identifiers

# Description

Currently we are using the Node Env for the App Name instead of the Environment name

## The Problem

Both Edge and FP use `production`



<!-- 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
Add ability to hide grid layer

<!-- Title suggestion: [Story] Name of story -->
<!-- Story issues track work to create new features and provide distinct new value to the user -->

## User Story

As a player/user/DM I would like the ability to hide the grid layer, especially for maps with a pre-made grid on them.

## Details

Probably would want the ability to toggle on/off.  Still want the functionality (snap to, etc) just not display it if not needed.

## Steps

- [ ] TBD

## 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.

<!-- Some notes on Acceptance Criteria (AC)
If you are having issues creating Acceptance Criteria, please review [Some notes on Acceptance Criteria(AC)](https://gitlab.com/mythicteam/mythictable/-/wikis/qa/acceptace-criteria). Don't hesitate to ask for AC review or assistance in #qa, it's what we're here for.
-->

- [ ] Given: Samples Criteria exists in template
    - [ ] And: it has not been removed
    - [ ] When: the ticket has been submitted
    - [ ] Then: Someone else should update this
    - [ ] And: include acceptable Acceptance Criteria
    
<!-- 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: 5.0