Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(ui): Allow specifying whether local or all snapshots are shown by default #186

Merged
merged 1 commit into from
Sep 14, 2023

Conversation

PhracturedBlue
Copy link
Contributor

@PhracturedBlue PhracturedBlue commented Sep 11, 2023

When I connect to the server http page, I prefer to see all snapshots shown by default. every time I switch away and come back I need to reselect 'All' instead of 'Local'. This just makes the default a preference option

Requires kopia/kopia#3289

@PhracturedBlue PhracturedBlue changed the title Allow specifying whether local or all snapshots are shown by default feat(ui): Allow specifying whether local or all snapshots are shown by default Sep 11, 2023
@PhracturedBlue
Copy link
Contributor Author

I put this comment in the kopia PR, but I'll add it here too as any changes are probably more relevant here:
I noticed that this will result in a configuration setting that has no effect when using the kopiaUI application (since multiUser is false there).

Solutions:

keep the code as is
leave the setting always available and place it in a 'multi user' section
query multi-user mode on the preferences page and hide the config option
remove the config option altogether and default to 'All Snapshots' if there is no local snapshot
The last option cold be done entirely in the UI without a need for any server-side changes, but it is the least flexible.

Copy link
Collaborator

@lupusA lupusA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @PhracturedBlue, @jkowalski,

i've tested this pr. Basically its working.

I've just got a question. Is it possible to store the selectedOwner instead of a boolean? As of now, we need to override the selectedOwner if it is null - based on the boolean that has been set by the user or using the default (true-> all snapshots, false-> local snapshots).

Saving the specific selection seems more intuitive, as the old selection will be set every time we open the snapshot tab.

What do you think?

Cheers,

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @PhracturedBlue,

there is a lint error in line 222:3. Can you fix it? Additionally, there is console log within the code that should be removed.

Right now we need to override the selectedOwner in the rendering function, which basically throws the above mentioned lint error. For the first rendering, the state is not changed. The second rendering cycle then uses the set selectedOwner.

Can we fix this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should extend the interface SerializedUIPreferences to reflect the new attribute defaultSnapshotViewAll.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@PhracturedBlue
Copy link
Contributor Author

I considered allowing selection of any user instead of just the all or local. It didn't make sense to me to save this setting, since normally I'm just using it as a filter, and not as a permanent setting. Whereas the 'Local' setting is of no use to me as I don't have any local snapshots. It is also a little weird to me to use what is effectively a filter as a preference and store that on the server. It would perhaps be better to store in in a local-store, but I don't see any enabling for that. If we do go this way, it eliminates the need for altering the preferences screen, so maybe it is overall more inuitive.

Anyhow, I can store the value as a username. we'll need to validate that the user exists each time, so I'm not sure it will actually simplify the code any though.

Please confirm you prefer preserving the last-selection, and I'll make the changes. Looks like @jkowalski already merged the boolean parameter, so we'll need a new pull-requrst into kopia for this change.

@lupusA
Copy link
Collaborator

lupusA commented Sep 12, 2023

Hi @PhracturedBlue,

then we should just fix the code and implement it as it is - with the current logic. What you you think @jkowalski?

Cheers,

@PhracturedBlue
Copy link
Contributor Author

One further option I thought of:
We can remove the preferences config and update defaultSnapshotViewAll based on the last seen of set('latest', 'all'). I.e. it wouldn't store that last selected user, but it would store the last selected latest or all.

That has the benefit of not requiring a server-only configuration section in the preferences.

@PhracturedBlue
Copy link
Contributor Author

I ended up removing the configuration option, as the more I thought about it the less it seemed helpful.

Copy link
Collaborator

@lupusA lupusA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look good to me. The selector now saves the last state - all or local snaphots.

Cheers

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jkowalski jkowalski merged commit 6e931fd into kopia:main Sep 14, 2023
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants