2020-01-13 23:05:50 +01:00
|
|
|
|
#+TITLE: Network Inventory
|
|
|
|
|
:preamble:
|
2020-01-14 23:11:32 +01:00
|
|
|
|
#+author: Andreas Zweili
|
2020-01-13 23:05:50 +01:00
|
|
|
|
:end:
|
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
* Introduction
|
|
|
|
|
** How to work with this file
|
|
|
|
|
|
|
|
|
|
1. All URLs should get included as footnotes on order to have a cleaner layout.
|
|
|
|
|
2. All tasks need a priority, tasks with a priority higher than C are
|
|
|
|
|
considered must haves for the 1.0 release. Everything with C or lower is
|
|
|
|
|
considered a nice to have an might never get implemented.
|
|
|
|
|
3. Once an item changes its status to either DONE or CANCELLED it gets moved to
|
|
|
|
|
the "Done" heading. CANCELLED items should get an explanation why they were
|
|
|
|
|
cancelled.
|
|
|
|
|
|
|
|
|
|
** Vocabulary
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
2020-01-14 23:08:22 +01:00
|
|
|
|
- Technician :: An employee working with the inventory tool and full access to
|
|
|
|
|
its information.
|
|
|
|
|
- Customer :: A customer which owns some of the devices in the inventory tool
|
|
|
|
|
and might have access to only the information related to the devices he owns.
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
2020-07-05 14:07:46 +02:00
|
|
|
|
* TODO Must Have [0/14]
|
2020-05-26 23:23:21 +02:00
|
|
|
|
** TODO [#A] Forms [0/12]
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** TODO Computer Forms [0/3]
|
2020-05-01 17:04:34 +02:00
|
|
|
|
- [X] Add
|
|
|
|
|
- [X] Update
|
2020-04-27 21:28:37 +02:00
|
|
|
|
- [ ] Delete
|
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
**** NEXT CPU Forms
|
2020-07-04 11:54:46 +02:00
|
|
|
|
- [X] Add
|
|
|
|
|
- [X] Update
|
|
|
|
|
- [X] Delete
|
2020-04-27 21:28:37 +02:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
**** NEXT RAM Forms
|
2020-07-04 11:54:46 +02:00
|
|
|
|
- [X] Add
|
|
|
|
|
- [X] Update
|
|
|
|
|
- [X] Delete
|
2020-04-27 21:28:37 +02:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
**** NEXT Disk Forms
|
2020-07-04 11:54:46 +02:00
|
|
|
|
- [X] Add
|
|
|
|
|
- [X] Update
|
|
|
|
|
- [X] Delete
|
2020-04-27 21:28:37 +02:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** NEXT Customer Forms
|
2020-05-24 17:58:50 +02:00
|
|
|
|
- [X] Add
|
2020-04-27 21:28:37 +02:00
|
|
|
|
- [ ] Update
|
|
|
|
|
- [ ] Delete
|
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** NEXT Backup Forms
|
2020-04-27 21:28:37 +02:00
|
|
|
|
- [ ] Add
|
|
|
|
|
- [ ] Update
|
2020-07-05 14:07:46 +02:00
|
|
|
|
- [X] Delete
|
2020-04-27 21:28:37 +02:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** NEXT UserLicense Forms
|
2020-04-27 21:28:37 +02:00
|
|
|
|
- [ ] Add
|
|
|
|
|
- [ ] Update
|
|
|
|
|
- [ ] Delete
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** NEXT DeviceLicense Forms
|
2020-07-04 11:54:46 +02:00
|
|
|
|
- [X] Add
|
|
|
|
|
- [X] Update
|
|
|
|
|
- [X] Delete
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** NEXT Net Forms
|
|
|
|
|
- [ ] Add
|
|
|
|
|
- [ ] Update
|
|
|
|
|
- [ ] Delete
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** NEXT Software Forms
|
|
|
|
|
- [ ] Add
|
|
|
|
|
- [ ] Update
|
|
|
|
|
- [ ] Delete
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** NEXT Users Forms
|
|
|
|
|
- [ ] Add
|
|
|
|
|
- [ ] Update
|
|
|
|
|
- [ ] Delete
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
*** NEXT Groups Forms
|
|
|
|
|
- [ ] Add
|
|
|
|
|
- [ ] Update
|
|
|
|
|
- [ ] Delete
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-05-02 22:46:39 +02:00
|
|
|
|
*** NEXT Limit the dropdowns in update views
|
|
|
|
|
|
|
|
|
|
When a user edits an object he should only be able to select objects from the
|
|
|
|
|
dropdowns he's allowed to view.
|
|
|
|
|
Meaning that we have to limit every dropdown in an update view to the customer
|
2020-05-03 22:21:02 +02:00
|
|
|
|
he's allowed to see. Like only the Nets or Users related to that customer.
|
2020-05-02 22:46:39 +02:00
|
|
|
|
|
2020-05-02 22:47:57 +02:00
|
|
|
|
We can use the get_objects helper function in core.utils.
|
|
|
|
|
|
2020-05-24 17:58:50 +02:00
|
|
|
|
*** NEXT Limit the customer views to superusers
|
2020-05-26 23:23:21 +02:00
|
|
|
|
*** NEXT Add + button for nets in the DeviceInNet form
|
|
|
|
|
|
|
|
|
|
This way we can quickly add a net when we want to add an IP to a device.
|
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#A] a backup should be able to contain multiple computers :model:
|
|
|
|
|
** NEXT [#A] implement view for groups
|
|
|
|
|
** NEXT [#A] Add a feature to copy objects
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
This is a must have for the first release.
|
|
|
|
|
As a user I would like to have a way of quickly copy an object and make some
|
|
|
|
|
adjustments in order to add many objects after another.
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#A] Add search boxes to the views.
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
So that one can search for a string in the responding column.
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#A] Create custom user model :model:
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
It is best practice to create a custom user model to allow future modifications
|
|
|
|
|
to the users without causing problems.
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#B] Implement a license check into all forms
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
This should prevent technicians from assigning licenses which the customer has
|
|
|
|
|
already fully used.
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#B] calculate licence usage for customer
|
2020-03-25 14:30:26 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
The view should show the licenses which the customer currently has available
|
|
|
|
|
and how many are already used. In addition it should show a visual warning to
|
|
|
|
|
the technician when the limit is reached.
|
2020-02-16 22:10:50 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#B] Convert the NETSheet Data file to YML fixtures.
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
A lot of this is already done. Only the hardware models are currently missing.
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#B] Have a look at the documentation of django-nested-admin
|
2020-03-25 09:44:25 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
I implemented nested-admin currently in a very basic way. I should read the
|
|
|
|
|
documentation in order to make sure that I'm using it correctly.
|
2020-03-25 14:30:26 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#B] have a look at django select_related, it might solve a problem for me.
|
2020-03-25 14:30:26 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
I often find myself trying to get related objects. The method select_related
|
2020-04-27 22:52:33 +02:00
|
|
|
|
might help with that [fn:1]:
|
|
|
|
|
-
|
2020-03-25 14:30:26 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#B] Extend the Admin tables
|
2020-03-25 09:33:05 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
The admin tables show currently very little information about the various
|
|
|
|
|
objects. At minimum every object should display the customer it belongs to.
|
2020-03-25 14:30:26 +01:00
|
|
|
|
|
2020-05-03 21:10:08 +02:00
|
|
|
|
** NEXT [#B] In the warranty form validate the date inputs
|
|
|
|
|
|
|
|
|
|
The starting date shouldn't be allowed to be newer than the end date.
|
|
|
|
|
|
2020-07-05 14:07:46 +02:00
|
|
|
|
** NEXT [#C] Filter Hardware Model to corresponding device manufacturer
|
|
|
|
|
|
|
|
|
|
When changing the HardwareModel field of a device the dropdown should be
|
|
|
|
|
filtered to the provided DeviceManufacturer.
|
|
|
|
|
|
|
|
|
|
Currently it could still make sense to make the DeviceManufacturer only
|
|
|
|
|
available through the HardwareModel. This way we wouldn't have to filter the
|
|
|
|
|
HardwareModel dropdown. However we would loose the ability to only select the
|
|
|
|
|
DeviceManufacturer for a device in case we don't know the specific model which
|
|
|
|
|
happens quite often.
|
|
|
|
|
|
|
|
|
|
* TODO Nice to Have [0/11]
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#C] allow technicians to add custom fields
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
This would allow technicians to create custom models without change
|
2020-04-27 22:52:33 +02:00
|
|
|
|
Maybe this approach would be something [fn:2]:
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#C] calculate the used space on a host
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
Means calculate the size all the VMs would use if they were thick.
|
|
|
|
|
This could help a technician to properly plan ressources on a host.
|
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#C] include a RAID calculator
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
I would like to use this to show the usable space in a RAID system. Currently
|
|
|
|
|
we enter this information by hand but it would be easier to calculate it
|
2020-04-27 22:52:33 +02:00
|
|
|
|
automatically [fn:3].
|
|
|
|
|
-
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#C] Get warranty information from Dell
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
We sell a lot of Dell devices and it would be nice to use the service tags to
|
2020-04-27 22:52:33 +02:00
|
|
|
|
collect the warranty information directly from Dell. There's an API for that [fn:4]:
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#C] A "to deactivate" feature on inventory users
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
This way a technician could mark a user for deactivation and anyone could check
|
|
|
|
|
if there are users to deactivate. This would help if we would've to deactivate
|
|
|
|
|
a user at a certain date. The inventory tool could then show to all technicians
|
|
|
|
|
that the user needs to be deactivated. Then any technician could deactivate the
|
|
|
|
|
user and not just the technician responsible for the customer, increasing the
|
|
|
|
|
security of the customer.
|
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** NEXT [#C] change the admin url
|
|
|
|
|
|
|
|
|
|
For security reasons it's recommended to change the name of the admin panel
|
|
|
|
|
url. This way automated tools can't find it so easy. It only increases the
|
|
|
|
|
security slightly.
|
|
|
|
|
|
|
|
|
|
** NEXT [#C] implement guardian
|
|
|
|
|
|
|
|
|
|
This needs to be done for basically every model which lives on a view. E.g.
|
|
|
|
|
~BackupListView~, ~SoftwareListView~. I can’t remember how this should be
|
|
|
|
|
implemented. However it might be implemented in the customer table view. The
|
|
|
|
|
security concept works like this:
|
|
|
|
|
1. check if the user is logged in
|
|
|
|
|
2. check if the user is allowed to view the customer, if not return an error
|
|
|
|
|
3. Get all matching objects which the user is allowed to view. Step two can't
|
|
|
|
|
be replaced by an empty table because we need a customer object to operate
|
|
|
|
|
on. Therefore it's better to quickly check the customer before we fetch all
|
|
|
|
|
the other objects from the database.
|
|
|
|
|
|
|
|
|
|
** NEXT [#C] Implement an excel import and export
|
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
might be achieved with the django-excel project [fn:6].
|
2020-04-27 22:37:22 +02:00
|
|
|
|
This might be a nice to have feature but the copy button is more important to
|
|
|
|
|
achieve a similar funcition.
|
|
|
|
|
|
|
|
|
|
** NEXT [#C] implement SoftwareDetailView
|
|
|
|
|
|
|
|
|
|
I don't remember what the initial idea here was. We could show here
|
|
|
|
|
which customers are using this software. But that is currently a really low
|
|
|
|
|
priority item.
|
|
|
|
|
|
2020-04-30 19:22:28 +02:00
|
|
|
|
** NEXT [#C] Implement the .all command in templates
|
|
|
|
|
|
|
|
|
|
This stackoverflow post should help [fn:9]
|
|
|
|
|
|
2020-07-05 14:07:46 +02:00
|
|
|
|
** NEXT [#B] Check tests for response.context[‚table‘]
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-07-05 14:07:46 +02:00
|
|
|
|
This would allow for tests of the views which check explicitly what gets
|
|
|
|
|
returned by the view. Might be easier/faster then rendering the whole view.
|
|
|
|
|
|
|
|
|
|
However for some views it would be better to test the final view because the
|
|
|
|
|
template contains logic which can fail.
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
* Resources
|
|
|
|
|
|
2020-05-01 16:12:13 +02:00
|
|
|
|
[fn:11] https://gist.github.com/neara/6209563
|
|
|
|
|
|
|
|
|
|
[fn:10] https://github.com/timhughes/django-cbv-inline-formset
|
|
|
|
|
|
2020-04-30 19:22:28 +02:00
|
|
|
|
[fn:9] https://stackoverflow.com/questions/4270330/django-show-a-manytomanyfield-in-a-template
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-30 19:22:28 +02:00
|
|
|
|
[fn:8] https://docs.djangoproject.com/en/3.0/ref/forms/fields/#multiplechoicefield
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
[fn:7] https://stackoverflow.com/questions/23059088/manytomany-field-check-if-relation-exists
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
[fn:6] https://github.com/pyexcel-webwares/django-excel
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
[fn:5] https://docs.djangoproject.com/en/2.2/topics/http/urls/#views-extra-options
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
[fn:4] https://www.programmableweb.com/api/dell-warranty-status-rest-api
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
[fn:3] https://thoughtworksnc.com/2017/08/30/writing-a-raid-calculator-in-python
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
[fn:2] https://stackoverflow.com/questions/34907014/django-allow-user-to-add-fields-to-model
|
2020-05-01 16:12:13 +02:00
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
[fn:1] https://docs.djangoproject.com/en/2.2/ref/models/querysets/#select-related
|
2020-02-16 20:17:17 +01:00
|
|
|
|
|
2020-04-27 21:40:18 +02:00
|
|
|
|
** Class Based Views
|
|
|
|
|
|
|
|
|
|
- http://ccbv.co.uk/
|
|
|
|
|
|
|
|
|
|
** Design
|
|
|
|
|
*** Admin themes
|
|
|
|
|
- django-grappelli
|
|
|
|
|
- django-suit
|
|
|
|
|
- django-admin-bootstrapped
|
|
|
|
|
|
|
|
|
|
** Forms
|
|
|
|
|
|
|
|
|
|
- https://django-crispy-forms.readthedocs.io/en/latest/index.html
|
|
|
|
|
- https://stackoverflow.com/questions/25321423/django-create-inline-forms-similar-to-django-admin*25340256
|
|
|
|
|
- https://stackoverflow.com/questions/5171365/django-inline-form-with-custom-forms
|
|
|
|
|
|
|
|
|
|
** Permissions
|
|
|
|
|
|
|
|
|
|
- https://django-guardian.readthedocs.io/en/stable/userguide/assign.html
|
|
|
|
|
- https://github.com/dfunckt/django-rules/blob/master/README.rst
|
|
|
|
|
|
|
|
|
|
#+begin_src python
|
|
|
|
|
decororator (function) :
|
|
|
|
|
if user has permission(object.customer):
|
|
|
|
|
return function
|
|
|
|
|
#+end_src
|
|
|
|
|
|
|
|
|
|
Maybe it would be possible to add a property to the classes which allows to
|
|
|
|
|
access the customer of an object like this:
|
|
|
|
|
|
|
|
|
|
#+begin_src python
|
|
|
|
|
object.customer
|
|
|
|
|
#+end_src
|
|
|
|
|
|
|
|
|
|
* Links to include
|
|
|
|
|
|
|
|
|
|
- https://docs.djangoproject.com/en/2.2/ref/models/querysets/#id4
|
|
|
|
|
- https://docs.djangoproject.com/en/2.2/ref/request-response/
|
|
|
|
|
- https://duckduckgo.com/?q=django+get_related&t=fpas&ia=qa
|
|
|
|
|
- https://pybit.es/selenium-pytest-and-django.html
|
|
|
|
|
- https://stackoverflow.com/questions/28533174/programatically-accessing-django-models-from-another-app
|
|
|
|
|
- https://stackoverflow.com/questions/54592026/how-to-create-a-custom-mixin-in-django
|
|
|
|
|
- https://stackoverflow.com/questions/58307055/access-django-model-name-from-admin-url-pattern
|
|
|
|
|
- https://stackoverflow.com/questions/6069070/how-to-use-permission-required-decorators-on-django-class-based-views#6069444
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
* Done
|
|
|
|
|
** DONE Recreate the RM in draw.io
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
The Dia RM is okay but not really that great. Draw.io would give a better
|
|
|
|
|
result.
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
** DONE create multiple requirements files
|
|
|
|
|
** DONE put passwords into environment variables
|
|
|
|
|
** DONE Permissions recherchieren
|
|
|
|
|
** DONE customer tabelle erweitern mit listen
|
|
|
|
|
** DONE Models erstellen
|
|
|
|
|
** DONE Add a Counter to the RAM Modules
|
|
|
|
|
** DONE Create a NET category where a device can live in.
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
This NET Category should display it's IP range, Subnet mask and show it's DHCP
|
|
|
|
|
range if one is configured.
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
** DONE Create class DeviceInNet
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
This class shows the relationship between the device and a NET. An attribute of
|
|
|
|
|
a DeviceInNet should be an IP address.
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
** DONE Create an abstract company class
|
|
|
|
|
** DONE Create Customer and a Manufacturer sub class Those two would be based on
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
the company class. I'm currently not sure how I should handle the case where a
|
|
|
|
|
company is both a customer and a manufacturer.
|
|
|
|
|
|
|
|
|
|
** DONE A text field next to the customer
|
|
|
|
|
|
|
|
|
|
where one can enter additional information which can't be put into the normal
|
|
|
|
|
documentation.
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
** DONE Fix test for net detail view
|
|
|
|
|
** DONE NETs, add a description field, for NETs like HEHImmo it might be nice to
|
2020-01-14 23:08:22 +01:00
|
|
|
|
|
|
|
|
|
have a short description for what it is intendet.
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
** DONE ComputerDetailView, add link to SoftwareDetailView
|
2020-01-14 23:08:22 +01:00
|
|
|
|
** DONE implement NETSheet list
|
|
|
|
|
|
|
|
|
|
this view should give an overview of all the devices in the NET and there
|
|
|
|
|
current IP Address.
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
** DONE implement BackupListView
|
2020-01-14 23:08:22 +01:00
|
|
|
|
** DONE Filter the queryset in the AllComputerView
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
2020-01-14 23:08:22 +01:00
|
|
|
|
so that it only shows the customers the current user is allowed to view
|
|
|
|
|
|
|
|
|
|
** DONE Disks in RAID and RAID have overlapping Felds (disks appear on both).
|
|
|
|
|
|
|
|
|
|
And they don't have the proper relationship. There can be disks from variing
|
|
|
|
|
sizes in a RAID therefore the relationship between DisksInRaid and
|
|
|
|
|
RaidInComputer needs to be a manytoone relationship
|
|
|
|
|
|
|
|
|
|
** DONE fix column name links in customer table
|
|
|
|
|
|
|
|
|
|
they throw an error when one clicks on them.
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
|
|
|
|
** DONE ComputerDetailView, add all properties to the view table
|
|
|
|
|
** DONE implement UserListView
|
2020-01-14 23:08:22 +01:00
|
|
|
|
** DONE implement SoftwareListView
|
|
|
|
|
|
|
|
|
|
this and the next view would probably better be a License view. Since the
|
|
|
|
|
software should be available to all devices from all customers. It doesn’t make
|
|
|
|
|
much sense to add 100 of different Office softwares. Probably a Software model
|
|
|
|
|
could be attached to a License model.
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
** DONE implement UserDetailView
|
2020-01-14 23:08:22 +01:00
|
|
|
|
** DONE Implement the license so that it can get attached to a user
|
|
|
|
|
|
|
|
|
|
when the user gets created. This way they might get less easily forgotten.
|
|
|
|
|
|
2020-01-13 23:05:50 +01:00
|
|
|
|
** DONE fix the Makefile so that the fixtures don't get applies twice.
|
|
|
|
|
|
2020-01-14 23:08:22 +01:00
|
|
|
|
This is already done for the ~make local~ command but needs fixing in the
|
|
|
|
|
~make~ command. However there's a bit more difficult because it runs in Docker
|
2020-01-13 23:05:50 +01:00
|
|
|
|
and with PostgreSQL
|
|
|
|
|
|
2020-01-14 23:08:22 +01:00
|
|
|
|
** DONE refactor the project to have a core app.
|
|
|
|
|
CLOSED: [2020-01-14 Tue 21:25]
|
|
|
|
|
|
|
|
|
|
This way I can split the project into multiple apps such as Customer, Computer,
|
|
|
|
|
Backups etc. and import the shared models from core. This allows me to split
|
|
|
|
|
the views and tests over multiple apps making the whole thing a bit easier to
|
|
|
|
|
understand. See the Notability note for more information.
|
|
|
|
|
https://github.com/netbox-community/netbox/tree/develop/netbox might provide an
|
|
|
|
|
example When doing the refactor I should correct the imports. The current
|
|
|
|
|
system is very annoying when I add a new object/class.
|
|
|
|
|
|
2020-02-14 20:34:31 +01:00
|
|
|
|
** DONE Hardware Model
|
|
|
|
|
CLOSED: [2020-02-14 Fri 20:28]
|
|
|
|
|
|
|
|
|
|
I'm currently unsure if I should implement a hardware model. With this model I
|
|
|
|
|
could add the hardware model to a device. Currently this capability is missing.
|
|
|
|
|
|
2020-02-15 18:57:34 +01:00
|
|
|
|
** DONE add a list of assigned users and computers to the license view
|
|
|
|
|
CLOSED: [2020-02-15 Sat 18:53]
|
|
|
|
|
** DONE Server mit NGINX aufsetzen
|
|
|
|
|
CLOSED: [2020-02-15 Sat 18:56]
|
|
|
|
|
|
|
|
|
|
- https://docs.djangoproject.com/en/2.2/howto/deployment/wsgi/uwsgi/
|
|
|
|
|
- https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html
|
|
|
|
|
- https://linuxconfig.org/how-to-host-django-with-nginx-on-ubuntu-18-04-bionic-beaver-linux
|
|
|
|
|
|
2020-02-16 20:17:17 +01:00
|
|
|
|
** DONE CustomerListView [3/3]
|
|
|
|
|
CLOSED: [2020-02-16 Sun 18:45]
|
|
|
|
|
|
|
|
|
|
add all the objects
|
|
|
|
|
|
|
|
|
|
- [X] Backup
|
|
|
|
|
- [X] Software
|
|
|
|
|
- [X] Users
|
|
|
|
|
|
|
|
|
|
** DONE implement permission decorators currently all the items can get viewed.
|
|
|
|
|
CLOSED: [2020-02-16 Sun 18:52]
|
|
|
|
|
|
|
|
|
|
I either have to implement a decorator for each object type or find a general
|
|
|
|
|
way. This problem is only related to detail views. The tables and lists have a
|
|
|
|
|
general way to check the permission. I maybe could get the model name from the
|
|
|
|
|
url, this Stackoverflow post might help:
|
|
|
|
|
- https://stackoverflow.com/questions/58307055/access-django-model-name-from-admin-url-pattern
|
|
|
|
|
and get the object with this function:
|
|
|
|
|
- https://stackoverflow.com/questions/28533174/programatically-accessing-django-models-from-another-app
|
|
|
|
|
|
|
|
|
|
** DONE Add tests for multiple nets and devices
|
|
|
|
|
CLOSED: [2020-02-16 Sun 18:52]
|
|
|
|
|
** DONE rename variables for the querysets to XXXRelations
|
|
|
|
|
CLOSED: [2020-02-16 Sun 18:53]
|
|
|
|
|
|
|
|
|
|
** DONE limit the queryset in the customer_table
|
|
|
|
|
CLOSED: [2020-02-16 Sun 19:13]
|
|
|
|
|
|
|
|
|
|
The queryset should only contain results which a users is allowed to see.
|
|
|
|
|
|
|
|
|
|
** DONE make sure the licenses models are correct.
|
|
|
|
|
CLOSED: [2020-02-16 Sun 19:31]
|
|
|
|
|
|
|
|
|
|
I think manytomany might not be the correct relation since a user should only
|
|
|
|
|
be attached once to a user license and a computer should only be attached once
|
|
|
|
|
to a computer license. However a user can stil have many licenses and a license
|
|
|
|
|
can still have many users.
|
|
|
|
|
|
2020-04-20 14:07:25 +02:00
|
|
|
|
** DONE tables problem
|
|
|
|
|
CLOSED: [2020-04-20 Mo 12:49]
|
|
|
|
|
|
|
|
|
|
This isn't fully working yet in django_tables2
|
|
|
|
|
https://github.com/jieter/django-tables2/issues/721
|
|
|
|
|
|
|
|
|
|
#+begin_src diff
|
|
|
|
|
-from django_tables2.utils import A
|
|
|
|
|
+
|
|
|
|
|
|
|
|
|
|
class CustomersTable(tables.Table):
|
|
|
|
|
- name = tables.LinkColumn('customer', args=[A('pk')])
|
|
|
|
|
- nets = tables.LinkColumn('nets', text='Nets', args=[A('pk')])
|
|
|
|
|
- computers = tables.LinkColumn('computers', text='Computers', args=[A('pk')])
|
|
|
|
|
- devices = tables.LinkColumn('devices', text='Devices', args=[A('pk')])
|
|
|
|
|
- backups = tables.LinkColumn('backups', text='Backups', args=[A('pk')])
|
|
|
|
|
+ name = tables.Column(linkify=("customer", [tables.A("pk")]))
|
|
|
|
|
+ nets = tables.Column(verbose_name="Nets",
|
|
|
|
|
+ linkify=("nets", [tables.A("pk")]))
|
|
|
|
|
+ computers = tables.Column(verbose_name="Computers",
|
|
|
|
|
+ linkify=("computers", [tables.A("pk")]))
|
|
|
|
|
+ devices = tables.Column(verbose_name="Devices",
|
|
|
|
|
+ linkify=("devices", [tables.A("pk")]))
|
|
|
|
|
+ backups = tables.Column(verbose_name="Backups",
|
|
|
|
|
+ linkify=dict(viewname="backups", args=[tables.A("pk")]))
|
|
|
|
|
#+end_src
|
|
|
|
|
|
|
|
|
|
** DONE implement a warranty overview
|
|
|
|
|
CLOSED: [2020-04-20 Mo 13:31]
|
|
|
|
|
|
|
|
|
|
2020-04-20
|
|
|
|
|
This is implementend now. I've setup the view so that customers can use the
|
|
|
|
|
view as well and the content gets limited to what they are allowed to see.
|
|
|
|
|
|
|
|
|
|
This view would show all devices which are running out of warranty, maybe this
|
|
|
|
|
could be shown as well in the CustomerDetailView. So that we would've a list
|
|
|
|
|
for the customers to see and one large list which shows the warranties for all
|
|
|
|
|
customers for internal usuage.
|
|
|
|
|
|
2020-04-27 21:40:18 +02:00
|
|
|
|
** DONE Fix the warranty in the device view
|
|
|
|
|
CLOSED: [2020-04-27 Mo 21:31]
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
2020-04-27 21:40:18 +02:00
|
|
|
|
With currently the containers don't disappear fully. Should be easy to fix.
|
2020-01-13 23:05:50 +01:00
|
|
|
|
|
2020-04-27 22:37:22 +02:00
|
|
|
|
** CANCELLED Move the lists to their own page
|
|
|
|
|
CLOSED: [2020-04-27 Mo 22:15]
|
|
|
|
|
|
|
|
|
|
Since I have more devices than I thought it would provide a better overview
|
|
|
|
|
than one big list. Forgot again what this exactly means.
|
|
|
|
|
|
2020-04-27 22:52:33 +02:00
|
|
|
|
|
2020-04-30 15:45:30 +02:00
|
|
|
|
** DONE [#A] cpu reduce required fields :model:
|
|
|
|
|
CLOSED: [2020-04-30 Do 14:54]
|
|
|
|
|
|
|
|
|
|
The CPU has many required fields but sometimes they don't make sense. For
|
|
|
|
|
example when we have a virtual CPU we usually don't need to know the specific
|
|
|
|
|
frequenzy.
|
|
|
|
|
|
|
|
|
|
** DONE [#A] the computer is missing a GPU :model:
|
|
|
|
|
CLOSED: [2020-04-30 Do 15:45]
|
|
|
|
|
|
|
|
|
|
CAD computers often have sppecial graphics cards which we should be able to
|
|
|
|
|
track.
|
|
|
|
|
|
2020-04-30 19:22:28 +02:00
|
|
|
|
** DONE [#A] Days need to be manytomany :model:
|
|
|
|
|
CLOSED: [2020-04-30 Do 19:21]
|
|
|
|
|
|
|
|
|
|
A backup can be run on multiple days
|
|
|
|
|
|
2020-04-30 20:34:54 +02:00
|
|
|
|
** DONE [#A] the IP needs to be able to be null :model:
|
|
|
|
|
CLOSED: [2020-04-30 Do 20:33]
|
|
|
|
|
|
|
|
|
|
Currently it's always required however when a device is in DHCP mode we can't
|
|
|
|
|
know the IP for sure.
|
|
|
|
|
|
2020-05-03 19:33:28 +02:00
|
|
|
|
** DONE [#B] Add the warranty to the Device, ConnectedDevice and Computer admin pages
|
|
|
|
|
CLOSED: [2020-05-03 So 19:32]
|
|
|
|
|
|
|
|
|
|
This is a relationship which a technician should be able to add directly on the
|
|
|
|
|
device and not have to navigate to the warranty option first.
|
2020-05-03 22:21:02 +02:00
|
|
|
|
** DONE [#A] check if the connected device and device model could get merged :model:
|
|
|
|
|
CLOSED: [2020-05-03 So 22:19]
|
|
|
|
|
|
|
|
|
|
When using the forms for warranties and net relations they both point to
|
|
|
|
|
different models but use the same logic so they always go back to the device
|
|
|
|
|
details.
|
|
|
|
|
|
|
|
|
|
However it's nice to differentiate between the connected device and the device
|
|
|
|
|
in the forms. So that one only can select the connected devices in the
|
|
|
|
|
dropdown. However the line between a connected device and a device is very thin.
|
|
|
|
|
|
|
|
|
|
** DONE Device Forms [2/2]
|
|
|
|
|
CLOSED: [2020-05-03 So 22:20]
|
|
|
|
|
- [X] Add
|
|
|
|
|
- [X] Update
|
|
|
|
|
- [X] Delete
|
|
|
|
|
|
|
|
|
|
*** DONE Warranty Forms
|
|
|
|
|
CLOSED: [2020-05-03 So 22:19]
|
|
|
|
|
- [X] Add
|
|
|
|
|
- [X] Update
|
|
|
|
|
- [X] Delete
|
|
|
|
|
|
|
|
|
|
*** DONE DeviceInNet Forms
|
|
|
|
|
CLOSED: [2020-05-03 So 22:19]
|
|
|
|
|
- [X] Add
|
|
|
|
|
- [X] Update
|
|
|
|
|
- [X] Delete
|
|
|
|
|
|
2020-07-05 14:07:46 +02:00
|
|
|
|
** DONE [#A] add a button to add a relation
|
|
|
|
|
CLOSED: [2020-07-05 So 13:05]
|
|
|
|
|
|
|
|
|
|
For the many to many relationships it might be a better idea to add them in a
|
|
|
|
|
separate form. So that the view displays the information but when you want to
|
|
|
|
|
add a new CPU for example it shows a button "Add CPU" which you can click an it
|
|
|
|
|
brings you to a new page where the PC is already preselected and the CPU can
|
|
|
|
|
get selected from a drop down.
|
|
|
|
|
|
|
|
|
|
The update form currently adds a new relation every time I update. The idea
|
|
|
|
|
above would be an easy solution. Another option to try out might be the
|
|
|
|
|
MultipleChoice field[fn:8].
|
|
|
|
|
Maybe with this I can limit the number of times a relation can be added.
|
|
|
|
|
|
|
|
|
|
** DONE [#A] Fix the table for the connected devices
|
|
|
|
|
CLOSED: [2020-07-05 So 13:36]
|
|
|
|
|
|
|
|
|
|
Currently there is a column for "Device_ptr" I have no idea where that came
|
|
|
|
|
from.
|
|
|
|
|
|
|
|
|
|
** DONE [#A] Add a view for DeviceManufacturer details
|
|
|
|
|
CLOSED: [2020-07-05 So 13:39]
|
|
|
|
|
|
|
|
|
|
since the DeviceManufacturer model now contains various contact details we
|
|
|
|
|
should provide a details view to let uses access those details.
|
|
|
|
|
|
|
|
|
|
** DONE [#B] Show all models in the admin interface
|
|
|
|
|
CLOSED: [2020-07-05 So 13:49]
|
|
|
|
|
:LOGBOOK:
|
|
|
|
|
- State "WAITING" from "NEXT" [2020-07-05 So 13:49]
|
|
|
|
|
:END:
|
|
|
|
|
|
|
|
|
|
Currently I'm hiding a lot of models from the admin interace to make it look a
|
|
|
|
|
bit nicer. However for the production site we want to work mostly on the
|
|
|
|
|
frontend. The admin page should then become really what it is. An admin
|
|
|
|
|
inteface so that we can delete or add models which currently don't have a
|
|
|
|
|
frontend interface.
|
|
|
|
|
|
|
|
|
|
** DONE [#C] Extend the CSS
|
|
|
|
|
CLOSED: [2020-07-05 So 13:50]
|
|
|
|
|
|
|
|
|
|
- A more centered layout would be nice
|
|
|
|
|
- Maybe some colours
|
|
|
|
|
|
|
|
|
|
** CANCELLED [#C] update the url code [fn:5]
|
|
|
|
|
CLOSED: [2020-07-05 So 13:56]
|
|
|
|
|
|
|
|
|
|
I'm currently not sure what I wanted to do with this.
|
|
|
|
|
|
|
|
|
|
** CANCELLED [#C] Add a check to see if a software has a license attached to it.
|
|
|
|
|
CLOSED: [2020-07-05 So 14:04]
|
|
|
|
|
|
|
|
|
|
I forgot the reason why I need this. Maybe to show in general if a software has
|
|
|
|
|
any licenses attached to it.
|
|
|
|
|
Add a check to see if a software has a license attached to it.If so it
|
|
|
|
|
increases the used licenses counter. Maybe with this this stackoverflow post
|
|
|
|
|
can help [fn:7].
|
|
|
|
|
|
|
|
|
|
** CANCELLED [#C] Inline Formfields like in the admin interface
|
|
|
|
|
CLOSED: [2020-07-05 So 14:06]
|
|
|
|
|
|
|
|
|
|
If already found various Github projects which might serves as an
|
|
|
|
|
example[fn:10] [fn:11]
|
|
|
|
|
|
|
|
|
|
currently not needed anymore I solve it with multiple form views because the
|
|
|
|
|
manytomany always generate a new object when updating.
|
|
|
|
|
|