Permissions for device adding is not working #1024

New Issue

adam · 2025-12-29T16:28:03+01:00

adam commented

2025-12-29 16:28:03 +01:00

Originally created by @Atoms on GitHub (Jun 13, 2017).

Issue type:

**Python version: 3.4
**NetBox version: 2.0.5

When User Group has only can add permission in menu you can see link to add device, but clicking on it it asks for login (you already are logged in)

When you add permission to change object then you can add and change object without the problems.

Originally created by @Atoms on GitHub (Jun 13, 2017). ### Issue type: **Python version: 3.4 **NetBox version: 2.0.5 When User Group has only can add permission in menu you can see link to add device, but clicking on it it asks for login (you already are logged in) When you add permission to change object then you can add and change object without the problems.

adam added the type: bug label 2025-12-29 16:28:03 +01:00

adam closed this issue

2025-12-29 16:28:03 +01:00

adam commented

2025-12-29 16:28:03 +01:00

@jeremystretch commented on GitHub (Jun 13, 2017):

This is because we're using one view to handle both creates and edits:

class DeviceEditView(PermissionRequiredMixin, ObjectEditView):
    permission_required = 'dcim.change_device'
    model = Device
    form_class = forms.DeviceForm
    template_name = 'dcim/device_edit.html'
    default_return_url = 'dcim:device_list'

(This is a common pattern for most objects in NetBox, not just devices.)

We could add a second view named DeviceAddView which inherits from the view above and merely modifies the required permission to be "add" instead of "change," but that does call into question the practicality of separating the two functions. Is there a reasonable use case where we would want to allow a user to create objects but not edit them?

@jeremystretch commented on GitHub (Jun 13, 2017): This is because we're using one view to handle both creates and edits: ``` class DeviceEditView(PermissionRequiredMixin, ObjectEditView): permission_required = 'dcim.change_device' model = Device form_class = forms.DeviceForm template_name = 'dcim/device_edit.html' default_return_url = 'dcim:device_list' ``` (This is a common pattern for most objects in NetBox, not just devices.) We could add a second view named `DeviceAddView` which inherits from the view above and merely modifies the required permission to be "add" instead of "change," but that does call into question the practicality of separating the two functions. Is there a reasonable use case where we would want to allow a user to create objects but not edit them?

adam commented

2025-12-29 16:28:03 +01:00

@Atoms commented on GitHub (Jun 13, 2017):

I cannot see now use case where we would like to use it, this was just like big confusion and you probably labeled correctly. As we are starting to use netbox, we are trying different scenariosm and one of them was to add user which can only add devices.

Maybe this is somehow connected to API permissions (we didn't checked that) ?

If it not affects API part, then as a fix i would say remove Add permision and rename Change to Add/Change
this would be less confusing :)

@Atoms commented on GitHub (Jun 13, 2017): I cannot see now use case where we would like to use it, this was just like big confusion and you probably labeled correctly. As we are starting to use netbox, we are trying different scenariosm and one of them was to add user which can only add devices. Maybe this is somehow connected to API permissions (we didn't checked that) ? If it not affects API part, then as a fix i would say remove Add permision and rename Change to Add/Change this would be less confusing :)

adam commented

2025-12-29 16:28:04 +01:00

@jeremystretch commented on GitHub (Jun 13, 2017):

Even if it's a rare use case, I think it makes sense to enforce the "add" and "change" permissions separately to ensure they do exactly what they sound like. It should be easy enough to tweak the ObjectEditView to apply one or the other appropriately.

Maybe this is somehow connected to API permissions

Just FYI the API utilizes the same permissions as the web UI.

@jeremystretch commented on GitHub (Jun 13, 2017): Even if it's a rare use case, I think it makes sense to enforce the "add" and "change" permissions separately to ensure they do exactly what they sound like. It should be easy enough to tweak the ObjectEditView to apply one or the other appropriately. > Maybe this is somehow connected to API permissions Just FYI the API utilizes the same permissions as the web UI.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#1024