mnixo / kindly Goto Github PK

This project forked from enbloc-org/kindly

0.0 0.0 0.0 7.7 MB

License: GNU General Public License v3.0

Shell 0.06% JavaScript 9.13% TypeScript 75.15% CSS 0.73% PLpgSQL 8.46% HTML 6.46%

kindly's Introduction

Kindly is an open source web application created by Trafalgar Girls and enBloc that supports Ukrainian refugees in the United Kingdom. Individuals can contribute items at no cost to provide much-needed support to members of the Ukrainian refugee community.

Who is it for?

Kindly is for anyone who wants to share items with the Ukrainian refugee community. Equally, it is for members of the Ukrainian refugee community who want to give back, borrow or receive items
Who are we?

Trafalgar Girls is a volunteer project providing informational, practical and emotional support to Ukrainian Refugees living in Great Britain and beyond

enBloc is a web agency born from the ever growing Founders and Coders alumni community and a creator of open source tools. Our ethos is simple: inspire, collaborate, and grow together
How to start using it?

Kindly is currently in beta stage, meaning that it is being tested by a small community of volunteer testers. If you want to get involved at this stage, check out the documentation linked under Contributing

Contributing

Kindly is an open source project and we welcome anyone looking to get involved. Please familiarise yourself with our documentation before getting started. You can find guidance on how to contribute in the following sources:

Our discord server - say Hi to the other developers and share knowledge here 👋
Before your first issue
Contributing
Best practice
Testing
Privacy
For details on the different roles you can take on

Governance

For details on different ways you can help maintaining Kindly please see our documentation on governance

Product Roadmap

For more detail on what features are planned for Kindly please see the roadmap

Copyright (C) 2024 enBloc

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License or any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses/.

kindly's People

Contributors

kindly's Issues

240

Setup

Create a new project:

Template: Board.
Name: "Kindly (enBloc)".
Rename "TODO" column as "Backlog".
Check project settings: visibility should be private, like the original one.
Check repository settings: visibility should be public, like the original one.

Create a new issue:

Leave unassigned.
Make sure it shows up in the project board. If not, add it to the "Backlog" column.

Fix

Both workflows (here and here) are showing the same issue:

`issue` is not a valid event name

This is because it should be issues instead of issue. This probably came from the example provided for the action being used. Using issues should fix the issue.

Pushed 54a425c. Assigned the issue to myself. Workflow run failed:

Error: Target column does not exist on project. Please use a different column name

Strange. The column ("In Progress") does exist on the project board.
Unassigned the issue. The other workflow run failed. The "Backlog" column also exists.
Will try a different action, this one hasn't been updated in a while.

Found an official GitHub article: Moving assigned issues on projects (classic).
Uses a different action: alex-page/github-project-automation-plus.
Let's try that one.

Pushed ccddf25. Assigned the issue to myself, then unassigned it. Both workflow runs failed (here and here):

Error: Resource not accessible by integration

Could be related with the token being used. The action has documentation detailing that GITHUB_TOKEN might not be sufficient if either the repository or the project is private.
Followed the instructions (and URL) to create the token with greater level of access and named it KINDLY_REPO_ORG. Then, added it to the repository as an Action secret. Tweaked the workflows to use this token.

Pushed f321122. Assigned the issue to myself, then unassigned it. Both workflow runs failed (here and here):

Error: Could not find the column "In Progress" or project "Kindly (enBloc)"

Found an issue of the action (93) that describes this same problem. It seems that the action is no longer compatible with the GitHub API. The owner is considering archiving the action, stating:

A lot of the functionality is already built into GitHubs UI with projects.

But the built-in automations cannot do what we need.

Sunset of Projects (Classic). So... The APIs won't be replaced with anything?

test

Test issue

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

I am running the latest version
I checked the documentation and found no answer
I checked to make sure that this issue has not already been filed

Expected Behaviour

Please describe the behaviour you are expecting:
 - refer to relevant files by their name in the codebase
 - add screenshots if the behaviour targeted affects the UI
 - outline any necessary setup to reproduce the behaviour you expect

Current Behaviour

Please outline the unwanted behaviour seen at the moment:
 - add screenshots if the behaviour affects the UI
 - add any error messages displayed at the moment
 - specify if this is a bug 🪲

Steps to Reproduce

Please provide detailed steps for reproducing the issue.

1. step 1
2. step 2
3. you get it...

216

Before anything, here are my current supabase versions (2024/06/13):

supabase -v -> 1.167.4.
- Installed using brew when I did my first setup for kindly (around 2024/05/24).
npx supabase -v -> 1.172.2.
- Installed the last time I executed npm i, not really sure when.

If I were to install supabase using the same methods now (2024/06/13), I would get different versions:

brew info --json supabase -> 1.172.2.
npm view supabase versions --json -> 1.176.10.
- Running npm i (in the project) or npm i supabase --save-dev would (in theory) install the same version.

Not only these are already different from the previous ones, they're also different between one another.

The goal is to rely on a single install of supabase that can be used across every OS, so it makes sense to take advantage of the one that is already being pulled through the package.json file. This dependency is specified using the ^, so it will automatically use the latest version available up to 2.0.0 (not including it).

We want to make sure that after the merge every contributor is relying on a supabase version that is at least the same (or newer) than the one that they were using. The only way to ensure that is to use the latest available version of supabase at the time of the merge.

After the setup of the new supabase version is done, we should try to validate 3 scenarios: It's possible to start supabase and the app:

Without any previous supabase data.
- Validated successfully.
With existing data, created by a previous supabase start instance (installed from brew).
- Validated successfully. In my case the version difference was between 1.167.4 and 1.176.10.
With existing data, created by a previous npx supabase start instance (installed from npm with --dev).
- Validated successfully. In my case the version difference was between 1.172.2 and 1.176.10.

After all the setup is done, it would be a good idea to uninstall all other previously installed versions of supabase.