* Allow to redirect to referrer page when access is denied
* Logout user and point towards login, add redirect
* Logout user as usual but added save redirects
* Adjusted templates and page codes
* Adding live-updates for gauges
* Adding new API calls
* Updated statistics to allow custom intervals
* Disabled caching for API calls for now
* Added new hashrate graph with auto-update
Addresses #444
* Added new configuration option `$config['network_confirmations']` to
dist config
* Default to 120 if not set
This will allow us to define a different confirmation level for user
transactions but still display blocks at their approriate unconfirmed
value when displaying them in the wallet information for admins. Risky
for pool owners but still a viable option.
Fixes#610
* Migrated configuration options to admin panel
* Removed configuration options from config file
* Added help text for each configuration option into panel
Addresses #622 and needs extensive testing by pools. A lot has changed
so pool owners might have to adjust their own templates to match this
new system.
First attempt addressing #610, still missing a detection for the actual
confirmation limit required for each block in case one lowers it in the
config.
* Properly sort the array prior to sending it back
* Sort from current to one hour earlier for proper data display
* Adjusted templates to use new sorted arrays
Fixes#606
* Fix hashrate calculations and include archived shares
* Fix worker activity to only check for our_result = Y shares
* Mark as active if worker has a hashrate > 0, removes a query
Addresses #561, crons need to be updated to remove the active flag from
as the worker activity and check the hashrate instead.
* Added new column to transactions table (`007_transactions.sql`)
* Added setArchived method to mark old transactions as archived
* Honor archived flag in getBalance and getLockedBalance
This will further address and fix#536 once merged.
* Removed getAllTransactions method
* Unified getTransactions for users and admins
* Added filter abilities to user transaction view
This should speed up things a fair bit for transaction heavy pools.
Addresses #536
This will avoid double payouts via the website. Payouts will be
requested by users and processed by a cron. If, for whatever reason,
users do add two requests (it is checked if a payout exists) they would
only have one successful payout until their account balance is back up
to a save value to trigger the payout.
This should fix any issues with manual payouts being exploited through
the website. Will require some testing by others to ensure things work
as expected.