- Show a notification 60 days, 30 days, 1 week, and 1 day before distribution
upgrade. If a notification is dismissed for any of these periods don't show
again until new period starts. Override any previous notification.
- Show a notification just before the distribution upgrade showing that the
process has started. Override any previous notification.
- Show a notification after the distribution upgrade is completed that it is
done. Override any previous notification. Keep this until it is 60 days before
next distribution upgrade. If user dismisses the notification, don't show it
again.
Tests:
- Start a bookworm VM.
- Disable the auto updates. Set the date to 2025-08-01. Start the service.
Notification is not shown when distribution check is done. Enable auto updates.
- Set the date to 2025-07-01. Start the service. No notification is shown after
distribution upgrade check is run.
- Set the date to 2025-08-01. Start the service. Notification is shown when
distribution check is done. Clicking on the 'Go to Distribution Update' takes to
distribution update page.
- Set the date to 2025-08-02. Start the service. Notification is not updated
when distribution check is done. Dismiss the notification.
- Set the date to 2025-08-03. Start the service. Notification is not shown when
distribution check is done.
- Set the date to 2025-08-22. Start the service. Notification is shown when
distribution check is done. Dismiss the notification.
- Set the date to 2025-08-23. Start the service. Notification is not shown when
distribution check is done.
- Set the date to 2025-09-15. Start the service. Notification is shown when
distribution check is done.
- Set the date to 2025-09-18 18:00. Start the service. Notification is shown
when distribution check is done.
- Set the date to 2025-09-19 18:00. Start the service. Notification is shown
that distribution update has started. Distribution upgrade has started. Dismiss
this notification. Upgrade does not succeed to due timestamp miss matches with
release file.
- Once the distribution upgrade has started. Start the service. Notification is
not shown when distribution check is done.
- Rollback to a snapshot before distribution upgrade. Start the distribution
upgrade manually and notice that notification is not shown when distribution
check is done.
- Once the distribution upgrade has completed, start the service. Notification
is shown the distribution upgrade has completed when distribution check is done.
Dismiss this notification.
- Restart the service. Notification is not shown when distribution check is
done.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Refer to the manual and mention that users can keep their distribution for 5
years before upgrade.
Tests:
- Proofread, links work.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: #2090
- Create a new page for distribution upgrade.
- If distribution upgrade is running show its status here without any other UI.
- Show various conditions for not allowing distribution upgrades.
- Automatic updates disabled
- Distribution updates disabled
- Not enough free space.
- Unknown or mixed distribution in sources.list.
- If distribution upgrade was interrupted, show that information here and allow
triggering distribution upgrade again. This is detected by noticing that
codename in base-files is higher than one detected in sources.list.
- If the user is not testing/unstable, show a message and don't allow
triggering.
- If next stable has not been released, don't auto-upgrade but allow manual
upgrade. Show special warnings.
- If next stable has been released but only recently, don't auto-upgrade but
allow manual upgrade.
- If next stable has been released and it has been 30 days, allow auto-upgrade
and manual upgrade.
- Seek confirmation before triggering manual upgrade. Provide appropriate
advice.
- Rely on hard-coded list of releases and their release dates instead of
querying the server.
Tests:
- When automatic updates or distribution updates are disabled, an alert message
is shown distribution upgrade page. If both are disabled, both messages show up
in the alert. The start distribution upgrade button is disabled. Clicking on the
button does not work.
- Reducing the available free disk space will cause alert message to show up and
start upgrade button to be disabled.
- When the distribution in /etc/apt/sources.list is mixed or unknown, an alert
message is shown. the start distribution upgrade button is disabled.
- When the distribution in /etc/apt/sources.list is testing or unstable, an
alert message is shown "You are on a rolling release distribution...". the start
distribution upgrade button is disabled. The current distribution is
'None (testing)' or 'None (unstable)'. Next stable distribution is Unknown.
- If get_current_release is hard-coded to return (None, 'trixie'). Then a
message is show in the distribution update page 'A previous run of distribution
update may have been interrupted. Please re-run the distribution update.' A
'Continue Distribution Update' button is shown in warning color. The button
takes to confirm page where the confirm button is shown in blue and is enabled.
- On a bookworm VM, visiting the page shows the message "You are on the latest
stable distribution...". Upgrade button shows in red. Clicking it takes to
confirmation page. The page shows a warning alert and red confirmation button.
- Setting the clock to '2025-08-21' shows the message "A new stable distribution
is available. Your FreedomBox will be update automatically in 4 weeks...".
Upgrade button shows in blue. Clicking it takes to confirmation page. The page
does show warning. The button is in blue.
- Setting the clock to '2025-09-30' shows the message "A new status distribution
is available. Your FreedomBox will be updated automatically soon...". Upgrade
button shows in blue. Clicking it takes to confirmation page. The page does show
warning. The button is in blue.
- Clicking the confirmation button starts the distribution upgrade process. This
distribution upgrade page is shown. The page shows spinner with a message and no
other UI. Page is refreshed every 3 seconds. When the distribution upgrade
process is completed, the page shows the current status.
- Killing the apt-get process during distribution upgrade stop the page refresh.
The page shows that process was interrupted and also continuation. Clicking on
the confirmation button resumes the distribution upgrade process.
- After distribution upgrade, the page shows the current distribution and next
distribution properly. There is not release date for the next distribution. A
message shows: "Next stable distribution is not available yet."
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Custom CSS variables were declared with Bootstrap 4 since it did not use CSS
variables itself. In Boostrap 5, CSS variables are available. Use them to
eliminate custom color definitions. This means that when Bootstrap colors are
changed, custom colored elements will not look different.
- Use color utilities from Bootstratp instead of .processing, .warning, and
.normal.
- Collect more repeated colors into variables. This will make themeing easier.
- Using Bootstrap variables also makes implement dark mode easier.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Ensure that .sr-only is replaced with newer classes.
- Ensure that icons are present for all alerts.
- Use flex-box for display of icons on the left center of the alert.
- .close has been renamed to .btn-close.
- × is no longer required for close buttons.
Tests:
- Visually verify all the changes by triggering them with code changes.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Remove the first setup wizard step to run security upgrades. At the time of
its introduction, it was felt that this is very important. Some things have
changed since then:
- We have mechanism for queuing package operations. Users can now trigger
software updates and start installing apps before that is completed. Or vice
versa. Earlier if the software updates were running, app install used to fail
with an error.
- There were no notifications. Since then we have added 'first setup'
notification for important topics such as Privacy. This step can be replaced
with a notification.
- Automatic diagnostics and a diagnostic to notify of updated packages also
helps bring attention to software updates if they are missed during first
setup.
- A proposed change will re-introduce an advice to run updates in the 'Next
steps' wizard step along with a button trigger it right there.
- The new notification for software updates will bring more attention to running
updates as part of first setup.
- It would be nice not be stuck in the first setup wizard for a long period and
make it look simple. It improves the fun factor of setting up FreedomBox.
- It would present an opportunity to utilize the parallel installation of
apps/updates to the full extent. Although this can also be done by skipping the
progress step after updates are run.
- First wizard steps tend to get less testing.
Tests:
- Run the first setup wizard by removing /var/lib/plinth/plinth.sqlite3 and
running the service. Notice that the software update step is not shown and
wizard completes successfully.
- On stable container, backports step is shown as expected (if not already
enabled).
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- In non-development mode, button does not appear.
- On testing system, button does not appear.
- On stable system in development mode, the button appears.
- Pressing the button starts a dist-upgrade.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
[sunil: Join strings that fit in the same line]
[sunil: Fix indentation in template]
[sunil: Change 'dist-upgrade' to 'distribution upgrade' in UI strings]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- Important information such as id of the notification should be available when
rendering the body template.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- The term 'Update' without a context is not easy to understand. This is
especially true during first setup wizard.
- This makes our UI similar to Android and lot of other OSes.
Tests:
- Trigger a update notification by incrementing FreedomBox version. In there,
the name of the app in the first line shows 'Software Update'.
- During first setup wizard, the title of the wizard step is 'Software Update'
initially and also when upgrades are running.
- In the System page, the title on the card is 'Software Update'. So is the
title on the app page.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Add running spinner before every app installation step text, this
makes the fact that installation is in progress visually more noticeable.
Tested when installing the mediawiki app, the running spinner is shown
on every installation step.
Signed-off-by: Veiko Aasa <veiko17@disroot.org>
[sunil: Horizontally align the text and spinner by the spinner inline]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Closes: #1939.
- Force a delay before returning the upgrade result to allow upgrade to kick in.
Otherwise when the flow returns, get_context_data() creates the context too
early and finds the upgrade not yet busy, causing the refresh loop to miss it.
The page renders static and the user gets no clue to the upgrade executing in
the background.
Signed-off-by: Fioddor Superconcentrado <fioddor@gmail.com>
[sunil: Retain the styling for the remainder of the page]
[sunil: Re-style the status section as a simple web-page]
[sunil: Drop unused running-status CSS styles]
[sunil: Rename CSS variables, minor changes to color values]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
It is confusing to combine the user's intent of wanting to have backports
activated with whether they have actually been configured in the system.
- Separate out checking for requested which is a key in the kvstore from enabled
which is about checking system configuration for backports.
- Implement convenience method for setting whether user requested backports.
- Do not base the status display (in security and upgrades modules) on the
configuration status and instead focus on user intent.
- If user requested backports but they have not been enabled yet due to not
being available, show as activated. System will keep trying the background and
configure eventually.
- If user requested backports but their configuration is outdated yet due to
newer release, show as activated. System will keep trying in the background
and configure latest settings eventually.
- In all places where backports enabling is being checked, split the logic for
'can be activated' from 'already activated' and 'user requested activation'
properly.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: #1855.
Tests:
- On unstable, first boot step is not shown. Backports are not
enabled.
- On testing, tested enabling backports at first boot step. Backports
are enabled.
- On testing, tested not enabling backports. Backports are not enabled
and can be activated later.
- On testing, confirmed that functional tests can click through the
first boot step.
- On stable with backports, first boot step is not shown. Backports
are enabled.
- On stable, tested enabling backports at first boot step. Backports
are enabled.
- On stable, tested not enabling backports. Backports are not enabled
and can be activated later.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
[sunil: Avoid two different i18n strings with almost same content]
[sunil: Use box_name instead of hardcoded FreedomBox name]
[sunil: Use consistent terminology 'activate' instead of 'enable']
[sunil: Rename the wizard, form, view, url for consistency with existing code]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Backports are not enabled and cannot be activated on unstable.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
[sunil: Add statement that backports may not be necessary]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Call backports as 'Frequent Feature Updates'. This is make it easy for a
non-technical user to understand better what they are.
- Clearly recommend enabling backports as this is our current consensus.
- Explain that if backports are disabled, feature updates will come every 2
years or so.
- Show the status of backports on upgrades app even after it is enabled.
Disappearing options in the UI are generally confusing for users (hiding of
expand partition feature should be seen as exception rather than as example).
- Tone down the alarm on backports:
- Rename 'Security Notice' to 'Frequent Feature Updates' in security page.
- Remove 'on a best-effort basis' phrase, as everything in Debian is similar.
- Set the activate button to primary priority rather than warning to make the
user comfortable with it.
- Share translation strings across the two apps so that effort for translators
is reduced.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Implement ability to refresh page at the framework level so that every page
does not need to handle it.
- Refresh after number of seconds specified in context of the view.
Tests performed:
- Trigger the following functions and ensure that page reload after 3 seconds
during the running operation while it does refresh before and after the
operation.
- Diagnostics tests from the module.
- Gitweb repository cloning.
- Monkeysphere publish key to server.
- OpenVPN setup.
- Tor configuration update.
- Manual software update.
- App installation.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Manual update is placed in a new section under Configuration.
Tests:
- Ran manual update with packages to be upgraded.
- Busy indicator is shown as expected.
- Log display button appears when logs are available.
- Logs can be expanded and collapsed.
Closes: #1771.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
[sunil: Change the update now button into default priority button]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- Don't not show notification on first install/run.
- Shows notification when upgrading or downgrading.
- This also serves as an example of how to show more specific notifications when
upgraded to a newer version. Closes: 1637.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
In the event setup page is being shown after the application installation is
already completed. Immediately reload instead of waiting for 3 seconds are
usual.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
"Update" is universally applied as the term for
upgrade/update/unattended upgrade/... as agreed on #1376 .
Changes also include simplifcation of text and interface, too.
Code may still need to be updated. This commit only touches on visibile
text.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Using the existing meta tag for refresh as a noscript fallback.
Fixes#1350
Signed-off-by: Joseph Nuthalapati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Closes#366 and closes#304 (all sub-tasks).
- Start new process group with setsid() by sending
start_new_session=True
- Detach from parent process fds by closing all FDs and attaching stdin,
stdou and stderr to /dev/null.
- Don't wait for the process to complete.
- This allows for upgrading Plinth while upgrades are trigged from
Plinth itself.
- Show log of upgrade exection instead of output and error log of the
process which can no longer be collected. This has the advantage of
showing automatic executions also.
- Rewrite the mechanism to detect whether upgrades can be run. It is
now based on whether the package manager is busy. This has the
advantage of working properly if other apt processes are running,
automatic upgrades are running, etc.
- Busy status works even if Plinth is restarted while upgrades are in
progress.
- More descriptive messages showing that upgrades don't have to be
triggered manually.
- Warn that other packages can't be installed while upgrades are
running, which may take a long time.
- Warn the users of potential temporary unavailability of
Plinth/Apache2.
- Show error message based on return code rather than messages in
stderr.
- Don't decorate the message paragraph with alert color, we are already
doing that by showing a message at the top.
- Untabify.
- Improve message showing that upgrades are running, gramatically.
- Show errors messages decorated as errors.
- Minor cleanups.
- Remove emacs mode line as emacs automatically detect Python files
based on the #! line.
- End comments with a '.'.
- Use single quotes instead of double quotes for string for consistensy.
- Update message to say that it take more than a minute to finish
upgrades. Some times it takes a lot more than that.
