mirror of
https://github.com/projectsend/projectsend.git
synced 2026-09-17 09:05:08 +00:00
ignacionelson
997debc6a3
The check ran daily and there was no other way to run it. An administrator who has just read that a release fixes the thing bothering them had to reach a terminal — or wait until tomorrow to be told what the project announced this morning. There is now a Check now button beside the setting that schedules it. It says what came back: the version waiting, or that this installation is already on the newest. The time of the last check sits next to it, because the notice on the dashboard is only as good as when it was last refreshed and nothing said when that was. Deliberately not gated on the daily-check setting. Switching that off says "do not have my server phone out unattended", which is not the same sentence as "refuse to answer when I ask" — so the button works either way and the setting keeps governing only the schedule. The work moved out of the command into CheckForUpdates, because the part that must not drift between the two callers is the part with consequences: which staff get notified, and the guard that stops them being notified again for a release they already know about. A second copy of that in a controller would have been found wrong six months later by somebody receiving the same notification every time a colleague pressed a button. Two throttles, and the second is not redundant. The route's bucket is per user; GitHub's limit is per server address, so two administrators each within their own allowance can still exhaust the installation's. The cooldown is installation-wide and costs no new setting — it reads the timestamp every check already writes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
60 lines
1.7 KiB
PHP
60 lines
1.7 KiB
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\Modules\Platform\Updates\Console;
|
|
|
|
use App\Modules\Platform\Settings\Setting;
|
|
use App\Modules\Platform\Settings\Settings;
|
|
use App\Modules\Platform\Updates\CheckForUpdates;
|
|
use Illuminate\Console\Command;
|
|
|
|
/**
|
|
* Community edition only, once a day. The work itself lives in
|
|
* CheckForUpdates, which the settings screen's "check now" button calls
|
|
* too; this is the scheduled half, and the only thing it adds is the
|
|
* setting that switches the schedule off.
|
|
*
|
|
* That setting governs *this* command and not the service on purpose: an
|
|
* administrator who does not want a daily outbound call should still be
|
|
* able to ask the question themselves.
|
|
*
|
|
* There is still no in-app self-updater — nothing here downloads or
|
|
* applies anything. Applying an update is `update.sh` on a server
|
|
* install, or a new image on a container one.
|
|
*/
|
|
class CheckForUpdatesCommand extends Command
|
|
{
|
|
protected $signature = 'projectsend:check-for-updates';
|
|
|
|
protected $description = 'Check for a newer ProjectSend release and notify admins (Community edition, runs daily)';
|
|
|
|
public function __construct(
|
|
private readonly Settings $settings,
|
|
private readonly CheckForUpdates $check,
|
|
) {
|
|
parent::__construct();
|
|
}
|
|
|
|
public function handle(): int
|
|
{
|
|
if ($this->settings->get(Setting::CheckForUpdates) !== true) {
|
|
$this->info('Update checks are disabled.');
|
|
|
|
return self::SUCCESS;
|
|
}
|
|
|
|
$result = $this->check->run();
|
|
|
|
if (! $result['ok']) {
|
|
$this->warn($result['message']);
|
|
|
|
return self::FAILURE;
|
|
}
|
|
|
|
$this->info($result['message']);
|
|
|
|
return self::SUCCESS;
|
|
}
|
|
}
|