- 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.
