galaxyproject / galaxy

Data intensive science for everyone.
https://galaxyproject.org
Other
1.35k stars 979 forks source link

Single user experience #11413

Open dannon opened 3 years ago

dannon commented 3 years ago

Right now the Galaxy single_user setting (used in anvil-based galaxies, and elsewhere) provides options that are not relevant in a single user setting where the upstream header is just trusted and every operation is done on behalf of a single admin user.

Things like "Logout", some of "Sharing", etc., in the UI can be removed and/or streamlined. This issue can be a collection of items we need to handle differently in single user mode.

Masthead

History

Workflows list

User preferences

dannon commented 3 years ago

@afgane I think "Cloud Authorization" and "Custom Builds" still apply. It sounds like there may be something else broken in the Anvil context, since this interface works for me locally.

There's no use-case for API keys right? Any transaction is just going to have that single_user set regardless.

ksuderman commented 3 years ago

A (not so) quick follow up to our discussion during the JHU meeting. I ran the suite of Selenium tests against a single user Anvil instance running on GCloud.

My first attempt was to just run the tests to see what broke and where. That went better than expected in that some tests actually passed, but 166 of 175 failed.

I eliminated the test files that looked to be irrelevant to singe user mode:

The test_admin_app should likely be included as there are still some admin functions a user may want to perform, e.g. installing tools. However, many of the Selenium tests do something like:

self.home()
self.login()
# Do stuff
self.logout()
assert some post condition

I was able to get a number of tests to pass by adding a single_user_mode field to the NavigateGalaxy class and modifying the submit_login, logout, and register methods to check:

if single_user_mode:
    return

I just hard coded single_user_mode = True, but we would obviously need to pass this value from a command line parameter or environment variable. We also need a way to distinguish tests that should be skipped in single user mode, this could be a decorator or by physically separating the sets of tests for each mode. In the future we may want to add tests like: "If in single user mode the user can't log out" or "if in single user mode the user cant delete their account" so it is not clear to me right now what the best approach might be.

Following a suggestion from @jmchilton I used the test_stock_tours.py as a starting point and ran all of the tours from the GTN training materials against the instance. Unfortunately all of the tours failed due to CSS changes in the UI. I took a quick look and I suspect most of the problems can be fixed with simple grep/awk/sed scripts, e.g. the upload button no longer includes the class .fa.fa-upload but its #id hasn't changed. I hope to investigate how much effort is involved in getting all the tours working again and I'm sure the training folks would appreciate knowing when a tour gets out of sync with the UI.

jmchilton commented 3 years ago

@ksuderman Awesome, awesome, awesome.

Here is how I would setup that flag (https://github.com/galaxyproject/galaxy/commit/c03e0ccb6eba17094d8cd7f56f7339c8605b5873) as well as test decorator so you can just mark the tests that won't work in single user mode as such and they can just be skipped by pytest.

ksuderman commented 3 years ago

@jmchilton super, thanks for that. I should have a draft PR ready Real Soon NowTM, but a few quick questions first:

  1. In your example above you named the decorator requires_multi_user_galaxy, is there any objection to calling it skip_if_single_user_mode to be inline with the other skip_if_* decorators?
  2. I will add a command line flag to the run-tests.sh script to set the GALAXY_TEST_SELENIUM_SINGLE_USER_MODE environment variable and was thinking of using -single and --singe_user_mode. Do we have a naming convention for command line parameters?