You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please be as detailed as possible with workarounds you considered and why a native feature is the better way. This gives me better context and will make it more likely to be implemented. Ideally a feature request should be in the format "I want to be able to do XYZ so that ZYX. I considered these approaches XYZ".
Fixing core functionality bugs not solvable with workarounds
New core functionality unlocking other opportunities (e.g.: plugins)
Refactoring enabling faster implementation of future functionality
UI improvements
Design philosophy: Focus on core functionality and leverage existing apps and tools to make PiAlert integratable into other workflows.
Examples:
1. Supporting apprise makes more sense than implementing multiple individual notification gateways
2. Implementing regular expressions support across settings for validation makes more sense than validating one setting with a specific expression.
UI specific requests are low priority as the framework picked by the original developer is not very extensible (and afaik doesn't support components) and has limited mobile support. Also I argue the value proposition is smaller than working on something else.
Feel free to submit PRs if interested. try to keep the PRs small/on topic so they are easier to review and approve.
That being said, I'd reconsider if more people and or recurring sponsors file a request 😉.
Check that your changes are backward compatible with existing installations and with a blank setup.
Existing features should always be preserved.
Keep the PR small, on-topic and don't change code that is not necessary for the PR to work
New features code should ideally be re-usable for different purposes, not be for a very narrow use-case.
New functionality should ideally be implemented via the Plugins system, if possible.
Suggested test cases:
Blank setup with no DB or config
Existing DB / config
Sending a notification (e. g. Delete a device and wait for a scan to run) and testing all notification gateways, especially:
Email, Apprise (e.g. via Telegram), webhook (e.g. via Discord), MQTT (e.g. via HomeAssitant)
Saving settings
Test a couple of plugins
Check the Error log for anything unusual
Some additional context:
Permanent settings/config is stored in the pialert.conf file
Currently temporary (session?) settings are stored in the Parameters DB table as key - value pairs. This table is wiped during a container rebuild/restart and it's values re-initialized from cookies / session data from the browser.
Please go ahead and create an issue with sufficient details if the above didn't help. 😉
The text was updated successfully, but these errors were encountered:
Repository owner
locked as resolved and limited conversation to collaborators
Dec 17, 2022
Contributing to this project
The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests.
🐛 Submitting an issue or bug
Before submitting a new issue please spend a couple of minutes on research:
⚠ Please follow the pre-defined issue template to resolve your issue faster.
Please read: https://github.com/jokob-sk/Pi.Alert/tree/main/docs#-submitting-an-issue-or-bug
🙏 Feature requests
Please be as detailed as possible with workarounds you considered and why a native feature is the better way. This gives me better context and will make it more likely to be implemented. Ideally a feature request should be in the format "I want to be able to do XYZ so that ZYX. I considered these approaches XYZ".
Please read: https://github.com/jokob-sk/Pi.Alert/tree/main/docs#-feature-requests
👨💻 Development priorities
Highest to lowest:
Design philosophy: Focus on core functionality and leverage existing apps and tools to make PiAlert integratable into other workflows.
Examples:
UI specific requests are low priority as the framework picked by the original developer is not very extensible (and afaik doesn't support components) and has limited mobile support. Also I argue the value proposition is smaller than working on something else.
Feel free to submit PRs if interested. try to keep the PRs small/on topic so they are easier to review and approve.
That being said, I'd reconsider if more people and or recurring sponsors file a request 😉.
Please read: https://github.com/jokob-sk/Pi.Alert/tree/main/docs#-feature-requests
➕ Pull-requests (PRs)
If you submit a PR please:
Suggested test cases:
Some additional context:
pialert.conf
fileParameters
DB table as key - value pairs. This table is wiped during a container rebuild/restart and it's values re-initialized from cookies / session data from the browser.Please go ahead and create an issue with sufficient details if the above didn't help. 😉
The text was updated successfully, but these errors were encountered: