Bug #9038
closedRemove population rights from admin but show "Upload jobs tree" button
0%
Description
The following changes are proposed:
- Remove the population button and rights from the admin user and give them to the manager instead;
- Forbid admin to upload jobs as it takes place for other new users;
- Show for admin and new users buttons "Upload jobs tree" in the main menu and "Download with children" in the drop-down menu "Selected jobs". But you can show them with different colors as deactivated or just show an access error if the user does not have rights to perform these actions.
Updated by Evgeny Novikov over 6 years ago
- Target version changed from 2.0 to 1.1
This issue is not strictly bound with purposes of 2.0 that targets verification of C software.
Updated by Vladimir Gratinskiy over 6 years ago
- Status changed from New to Feedback
Nobody has button "upload job". Button "upload jobs" is used for a single job upload also. If administrator doesn't have an access to upload jobs then he would get and error "You don't have an access to upload jobs" if he try to upload any job. Buttons in main menu are fixed. Rejected.
Updated by Ilja Zakharov over 6 years ago
- Subject changed from An administrator has button upload jobs that should be available for manager and/or other roles to Remove population rights from admin but show "Upload jobs tree" button
- Description updated (diff)
Updated by Evgeny Novikov over 6 years ago
- Target version changed from 1.1 to 2.0
Let's Vladimir will do this after his vacation.
Updated by Vladimir Gratinskiy about 6 years ago
- Status changed from Open to Resolved
Implemented in bridge-2.0.
Updated by Vladimir Gratinskiy about 6 years ago
As admin now doesn't have population rights, there is no need to populate manager user (as manager is already exists if population page is loaded). So this form can be deleted from population page.
Updated by Evgeny Novikov about 6 years ago
- Status changed from Resolved to Open
Vladimir Gratinskiy wrote:
As admin now doesn't have population rights, there is no need to populate manager user (as manager is already exists if population page is loaded). So this form can be deleted from population page.
This is a good idea. Indeed, for the most of Klever instances Manager and Service user are populated in advance by means of manage.py task PopulateUsers that is invoked automatically by deployment scripts. For the rest instances we can easily request to follow this way as well.
Updated by Vladimir Gratinskiy about 6 years ago
- Status changed from Open to Resolved
Fixed in "bridge-2.0".
Updated by Evgeny Novikov about 6 years ago
- Status changed from Resolved to Open
When opening a page pointing to a non-existing job, e.g. http://localhost:8998/jobs/100/, Bridge 2.0 raises the following exception:
No job found matching the query Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/django/views/generic/detail.py", line 51, in get_object obj = queryset.get() File "/usr/lib/python3.6/site-packages/django/db/models/query.py", line 403, in get self.model._meta.object_name jobs.models.DoesNotExist: Job matching query does not exist. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/django/core/handlers/base.py", line 126, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python3.6/site-packages/django/views/generic/base.py", line 69, in view return self.dispatch(request, *args, **kwargs) File "/usr/lib/python3.6/site-packages/django/utils/decorators.py", line 62, in _wrapper return bound_func(*args, **kwargs) File "/usr/lib/python3.6/site-packages/django/contrib/auth/decorators.py", line 21, in _wrapped_view return view_func(request, *args, **kwargs) File "/usr/lib/python3.6/site-packages/django/utils/decorators.py", line 58, in bound_func return func.__get__(self, type(self))(*args2, **kwargs2) File "/home/novikov/work/klever/bridge/tools/profiling.py", line 185, in dispatch response = getattr(super(), 'dispatch')(request, *args, **kwargs) File "/usr/lib/python3.6/site-packages/django/views/generic/base.py", line 89, in dispatch return handler(request, *args, **kwargs) File "/usr/lib/python3.6/site-packages/django/views/generic/detail.py", line 105, in get self.object = self.get_object() File "/usr/lib/python3.6/site-packages/django/views/generic/detail.py", line 54, in get_object {'verbose_name': queryset.model._meta.verbose_name}) django.http.response.Http404: No job found matching the query
Updated by Vladimir Gratinskiy about 6 years ago
- Status changed from Open to Resolved
That exception was caught. But anyway in birdge-2.0 I've fixed it so default "Page not found" will be shown (not only for jobs, but for all "Detail" views). Later I'll add custom pages for "not found" and "forbidden" errors. And will change some errors processing.
Updated by Evgeny Novikov about 6 years ago
- Status changed from Resolved to Closed
Tests passed, so, I merged the branch to master in b8bda00ac.
Updated by Evgeny Novikov about 6 years ago
Don't forget to populate users for all new databases:
./manage.py PopulateUsers --admin '{"username": "admin", "password": "admin"}' --manager '{"username": "manager", "password": "manager"}' --service '{"username": "service", "password": "service"}'
For populating administrator you still can use createsuperuser.