Project

General

Profile

Bug #9038

Remove population rights from admin but show "Upload jobs tree" button

Added by Ilja Zakharov 7 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Urgent
Category:
Bridge
Target version:
Start date:
06/29/2018
Due date:
% Done:

0%

Estimated time:
Detected in build:
svn
Platform:
Published in build:

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.

History

#1 Updated by Evgeny Novikov 7 months 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.

#2 Updated by Vladimir Gratinskiy 7 months 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.

#3 Updated by Ilja Zakharov 6 months ago

  • Status changed from Feedback to Open

#4 Updated by Ilja Zakharov 6 months ago

  • Description updated (diff)
  • 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

#5 Updated by Evgeny Novikov 6 months ago

  • Target version changed from 1.1 to 2.0

Let's Vladimir will do this after his vacation.

#6 Updated by Vladimir Gratinskiy 4 months ago

  • Status changed from Open to Resolved

Implemented in bridge-2.0.

#7 Updated by Vladimir Gratinskiy 4 months 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.

#8 Updated by Evgeny Novikov 4 months 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.

#9 Updated by Vladimir Gratinskiy 4 months ago

  • Status changed from Open to Resolved

Fixed in "bridge-2.0".

#10 Updated by Evgeny Novikov 4 months 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

#11 Updated by Vladimir Gratinskiy 4 months 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.

#12 Updated by Evgeny Novikov 4 months ago

  • Status changed from Resolved to Closed

Tests passed, so, I merged the branch to master in b8bda00ac.

#13 Updated by Evgeny Novikov 4 months 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.

Also available in: Atom PDF