Update documentation

This commit is contained in:
Thu Trang Pham
2021-04-28 14:38:26 -07:00
parent 16642b991c
commit f03f55dda7
4 changed files with 151 additions and 130 deletions
+128
View File
@@ -0,0 +1,128 @@
### Local Development Setup
**Local:**
_You can skip this and just use docker if you want_
Install pyenv
pyenv install 3.8.0
Create **virtualenv** via pyenv
```
pyenv vituralenv 3.8.0 django-admin-confirm-3.8.0
```
Now your terminal should have `(django-admin-confirm-3.8.0)` prefix, because `.python-version` should have auto switch your virtual env
Install requirements
```
pip install -r requirements.txt
pip install -e .
```
Run **migrations** and create a superuser and run the server
```
./tests/manage.py migrate
./tests/manage.py createsuperuser
./tests/manage.py runserver
```
You should be able to see the test app at `localhost:8000/admin`
**Running tests:**
```sh
make test # Runs unit tests with coverage locally without integration tests
make test-all # Runs unit tests + integration tests, requires extra setup to run locally
```
Use `python -m pytest` if you want to pass in arguments
`make t` is a short cut to run without coverage, last-failed, and fail fast
Testing local changes on test project:
```
pip install -e .
make run
```
**Debugging**:
There's a environment variable `ADMIN_CONFIRM_DEBUG` which when set to true will print to stdout the messages that are sent to `log`.
The test project already has this set to true.
Example:
```py
from admin_confirm.utils import log
log('Message to send to stdout')
```
**Docker:**
Instead of local set-up, you can also use docker.
Install docker-compose (or Docker Desktop which installs this for you)
```
docker-compose build
docker-compose up -d
```
You should now be able to see the app running on `localhost:8000`
If you haven't already done migrations and created a superuser, you'll want to do it here
```
docker-compose exec web tests/manage.py migrate
docker-compose exec web tests/manage.py createsuperuser
```
Running tests in docker:
```
docker-compose exec -T web make test-all
```
The integration tests are set up within docker. I recommend running the integration tests only in docker.
Docker is also set to mirror local folder so that you can edit code/tests and don't have to rebuild to run new code/tests.
### Release process
Honestly this part is just for my reference. But who knows :) maybe we'll have another maintainer in the future.
Run tests, check coverage, check readme
```
docker-compose exec -T web make test-all
make check-readme
```
Update version in `setup.py`
```
make package
make upload-testpypi VERSION=<VERSION>
```
Install new version locally
First you have to uninstall if you used `pip install -e` earlier
```
pip uninstall django_admin_confirm
make install-testpypi VERSION=<VERSION>
```
Add test locally
```
make run
```
Go on github and make a release in UI
+14
View File
@@ -0,0 +1,14 @@
## Feature List
This is a list of features which could potentially be added in the future. Some of which might make more sense in their own package.
- [x] confirmations on changelist actions
- [ ] confirmations on inlines
- [ ] global actions on changelist page
- [ ] instance actions on change/view page
- [ ] action logs (adding actions to history of instances)
- [ ] add help tooltip/popover to any field for more info
- [ ] add help tooltop/popover/help button to admin actions on changelist
- [ ] run scripts from admin
- [ ] completed action summary page
- [ ] add top and bottom areas to instance pages which can be configured for any content
+126
View File
@@ -0,0 +1,126 @@
# Testing Documentation/Notes
[![Coverage Status](https://coveralls.io/repos/github/TrangPham/django-admin-confirm/badge.svg)](https://coveralls.io/github/TrangPham/django-admin-confirm)
Hello, friend! You have found the list of test cases that this package can benefit from.
You seem concerned about the stability and reliability of this package. You're probably wondering if you should include it in your production codebase. Well, although I have tried very hard to get 100% code coverage, there are so many permutations of ModelAdmins in the wild. And I'm only one person.
So if you want to include this package in your production codebase, be aware that AdminConfirmMixin works best with simple unmodified ModelAdmins.
# Probable Issues
These are some areas which might/probably have issues that are not currently tested. Use at your own risk!
- [ ] Saving file/image changes on inlines when confirming change on parent model
## Save Options
- [x] Save
- [x] Conitnue
- [x] Save As New
- [x] Add another
### Field types
- [x] CharField
- [x] PositiveIntegerField
- [x] DecimalField
- [x] TextField
- [x] ImageField
- [x] FileField
- [x] ManyToManyField
- [x] OneToOneField
- [x] ForeignKey
- [x] DateField
- [x] DateTimeField
- [x] Custom Readonly fields
### Options
- [x] .exclude
- [x] .fields
- [x] .readonly_fields
- [x] Actions
### Options to test
- [x] ModelAdmin.fieldsets
- [ ] ModelAdmin.form
- [x] ModelAdmin.raw_id_fields
- [x] ModelAdmin.radio_fields
- [ ] ModelAdmin.autocomplete_fields
- [ ] ModelAdmin.prepopulated_fields
## ModelAdmin form template overrides?
https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#custom-template-options
(Maybe??? IDK this is esoteric)
## Function overrides to test
- [ ] .save_model()
- [ ] .get_readonly_fields()
- [ ] .get_fields()
- [ ] .get_excludes()
- [ ] .get_form()
- [ ] .get_autocomplete_fields()
- [ ] .get_prepopulated_fields()
- [x] .get_fieldsets()
- [ ] ModelAdmin.formfield_for_manytomany()
- [ ] ModelAdmin.formfield_for_foreignkey()
- [ ] ModelAdmin.formfield_for_choice_field()
- [ ] ModelAdmin.get_changeform_initial_data()
## Inline instance support??
Confirmation on inline changes is not a current feature of this project.
Confirmation on add/change of ModelAdmin that includes inlines needs to be tested. Use AdminConfirmMixin with ModelAdmin containing inlines at your own risk.
- [x] .inlines
- [x] .get_inline_instances()
- [x] .get_inlines() (New in Django 3.0)
- [ ] .get_formsets_with_inlines() ???
#### Options for inlines
- [ ] classes of inlines: Tabular, Stacked, etc
- [ ] extra
- [ ] action on the inline: add or change
- [ ] clicking add another on the inline
## IDK if we want to support these
- [ ] .get_changelist_form()
- [ ] ModelAdmin.list_editable
- [ ] ModelAdmin.changelist_view()
- [ ] ModelAdmin.add_view(request, form_url='', extra_context=None)
- [ ] ModelAdmin.change_view(request, object_id, form_url='', extra_context=None)
## More tests for these?
Note: Currently the code always calls super().\_changeform_view(), which would ensure permissions correct as well
- [x] ModelAdmin.has_add_permission
- [x] ModelAdmin.has_change_permission
### Tests for confirming models/forms with validations
- [x] ModelForm.clean_field
- [x] ModelForm.clean
- [x] Model.clean
- [x] validator on the model field
There are other possible combos of theses
### Tests where save functions are overridden
- [ ] ModelForm.save
- [ ] ModelAdmin.save_model
### Tests for storage backends for ImageField and FileField
- [x] Local storage
- [ ] S3