I've upgraded to superset 0.38, and suddenly my admin user can't see the sources menu anymore. All he can see is Charts, Dashboards and SQL-Lab.
The user has all rights - Admin, Alpha, Beta, Gamma, SQL-Lab and Public.
Important to note that we use Google OAuth authentication based on flask, which probably impacts this somehow.
Had the same problem on upgrading to 0.38.
Running superset init fixed it for us.
$ superset init
Syncing role definition
INFO:superset.security.manager:Syncing role definition
Syncing Admin perms
INFO:superset.security.manager:Syncing Admin perms
Syncing Alpha perms
INFO:superset.security.manager:Syncing Alpha perms
Syncing Gamma perms
INFO:superset.security.manager:Syncing Gamma perms
Syncing granter perms
INFO:superset.security.manager:Syncing granter perms
Syncing sql_lab perms
INFO:superset.security.manager:Syncing sql_lab perms
Fetching a set of all perms to lookup which ones are missing
INFO:superset.security.manager:Fetching a set of all perms to lookup which ones are missing
Creating missing datasource permissions.
INFO:superset.security.manager:Creating missing datasource permissions.
Creating missing database permissions.
INFO:superset.security.manager:Creating missing database permissions.
Creating missing metrics permissions
INFO:superset.security.manager:Creating missing metrics permissions
Cleaning faulty perms
INFO:superset.security.manager:Cleaning faulty perms
I think you are using PIP install, so your UI interface has a data menu instead of source. I am also facing this problem at present, and I think there are two ways to deal with it: A.On the existing basis, NPM Run build front end, but the front end has been separated, I don't know how to build.B. Re-install superset through the source code. The official website simply provides the installation method through Docker, but I don't want to use Docker and don't know how to deal with the front-end code.The linked article on the website (https://hackernoon.com/a-better-guide-build-d-apache-superneck-source-6f2ki32n0) is also unclear,Provided by contributing. Md (https://github.com/apache/incubator-superset/blob/0.38/CONTRIBUTING.md#setup-local-environment-for-development) is also not clear, this is bad..
Related
I have 2 projects written by Django : 1- Authentication(P1) and 2- my_API(P2). in P1 I use DRF-simplejwt and 'dj-rest-auth' to register,login,logout,reset password ,... for P2 I need authentication. My opinion is that JWT does not use database for checking access token so It does not need to connect my users' db to P2. But now I have error saying that I should migrate auth_user for rest_framework_simplejwt. What should I do now for checking permissions of P2 end points? I also mention that I set both of SECRET_KEYs to the same value. Thanks for your attention :)
The rest_framework_simplejwt plugin uses the User model for authentication and other stuff, even if you don' t perform authentication in the my_API project, you need to migrate the User model (is a requirement). I advice you to create a single project with two applications.
After refactoring some models in my Django/Wagtail project I had some stale contenttypes, triggering errors in the wagtail search app.
These errors could be fixed by running a contenttypes management command:
./manage.py remove_stale_contenttypes
Ok, I got warned about what will be deleted and there were indeed some group permission objects listed. Anyway, remove_stale_contenttypes did it's job and the wagtail search was back.
But now some permissions are missing: e.g. the "Can access wagtail admin" Group permission is completely missing, even for new Group instances.
How do I get the default permissions back (some were migrated once via wagtail/admin/migration)? Ideally, I would like to restore all "default" permissions on my production site...
The following code (to be run on the ./manage.py shell command line) should to it:
from django.contrib.contenttypes.models import ContentType
from django.contrib.auth.models import Permission
wagtailadmin_content_type, created = ContentType.objects.get_or_create(app_label='wagtailadmin', model='admin')
admin_permission, created = Permission.objects.get_or_create(content_type=wagtailadmin_content_type, codename='access_admin', name='Can access Wagtail admin')
This is a bug specifically affecting the "Can access wagtail admin" permission type, and no other permissions should be affected.
I've just installed apache superset following instructions at https://superset.incubator.apache.org/installation.html. I then login to the web interface as admin. I also loaded sample data with 'superset load_examples'.
If i go to 'Sources > Tables' and click on any of the tables ('wb_health_population', for example) i get an error: 'This endpoint requires the datasource wb_health_population, database or all_datasource_access permission'.
I check permissions set for the admin role and existing permissions: 'all_datasource_access' is not enabled for the admin role, and does not exist in the list of existing permissions.
As i told, i just followed standard instalation instructions from superset's doc website. Any help on this? Thank you.
EDIT: Superset version is 0.20.6, python's 3.6.3.
Try running superset init - this should initialize permissions.
See https://superset.incubator.apache.org/installation.html#superset-installation-and-initialization
(code-wise, init calls security.sync_role_definitions() which itself calls create_custom_permissions() which creates the said permissions)
I would also try all_database_access permission.
I'm building a Django app which connects to a PostgreSQL database, and the credentials that the app uses has quite limited permissions granted over the relevant tables.
I'd like to be able to use south to manage database migrations, but given that this picks up on the same credentials that Django uses, this throws an error as south cannot make any changes to tables it doesn't own.
Is there a way to specify that south should use a different set of credentials to manage migrations other than that specified by the application settings?
Yes : have another set of settings with different credentials for south migrations and use the --settings option when calling the migrate command.
NB : to avoid DRY violation, you can as well start your special settings file by importing * from the normal settings and just override the DB credentials.
I installed the https://github.com/pennersr/django-allauth package via pip. I followed the README.rst and after a bit of rigmarole got almost everything to work.
The facebook, twitter, openid and emailconfirmation sections are now appearing in my admin screen, but when I click on any of their menu items I get an error such as:
no such table: twitter_twitterapp
and a similar error for each of the four new apps. Did I miss a step or some steps in the installation process where the database tables get created?
I'm using sqlite3, if that has any bearing on the isssue.
If you have not already done syncdb then you must do that once. After doing that go in your admin and you will see a section for twitterapp and another for facebookapp. There you need to add the required keys.