cca-public / scope Goto Github PK
View Code? Open in Web Editor NEWSCOPE: An access interface for DIPs from Archivematica
License: GNU Affero General Public License v3.0
SCOPE: An access interface for DIPs from Archivematica
License: GNU Affero General Public License v3.0
An admin account should be only edited by an admin.
Only a small black bar without navigation elements is being shown in widths bellow 992px.
Looking at the README, there is an "Edit Collections and Folders" group but there isn't a way to add an user to that group.
To enable tagging by series, project, etc.
ValueError at /new_user/
The view dips.views.new_user didn't return an HttpResponse object. It returned None instead.
Request Method: POST
Request URL: http://localhost:8080/new_user/
Django Version: 1.11.5
Exception Type: ValueError
Exception Value:
The view dips.views.new_user didn't return an HttpResponse object. It returned None instead.
Exception Location: /home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/core/handlers/base.py in _get_response, line 198
Python Executable: /home/radda/dip-access-interface/venv/bin/python
Python Version: 3.6.3
Python Path:
['/home/radda/dip-access-interface/accesspoc',
'/home/radda/dip-access-interface/venv/lib/python36.zip',
'/home/radda/dip-access-interface/venv/lib/python3.6',
'/home/radda/dip-access-interface/venv/lib/python3.6/lib-dynload',
'/usr/local/lib/python3.6',
'/home/radda/dip-access-interface/venv/lib/python3.6/site-packages']
Server time: Fri, 22 Dec 2017 19:48:42 +0000
Descriptions currently take up a lot of space on the screen. Is there a way to make the description cut off after, for example, 50 words that can be expanded if the user clicks?
The DigitalFiles' datemodified
field of is currently being stored as a char field in the database and therefore as a text field in the Elasticsearch index. This is made to allow any date format from the METS file but, considering that this field will be used to sort the digital files data tables, it should be stored as a date time field, which will also allow to do better aggregations in Elasticsearch queries in the future.
Pay special attention to the timezone when parsing and saving the date time to the database and the Elasticsearch index.
Create a "Production installation" section in the README file with technical requirements for hosting the application.
We should also consider removing the development notes using Python virtualenv and the Django development server in favor of the Docker environment. The installation requirements will grow soon with Elasticsearch, the Celery worker and maybe a different database service and they will be similar in production and development (outside Docker).
Three suggested improvements for the continuous integration process:
Check for migrations:
As suggested by @sevein in #66:
You should use https://github.com/artefactual/archivematica-storage-service/blob/31bad497be0ce1c94f3bf3413a93b75bae9815e3/.travis.yml#L36-L37.
Check executed tests code:
Add Flake8 import order check (or isort):
Considering that it could be multiple instances of this application, the database shouldn't be tracked as part of the source code.
For the initial stages of development a database seeder task could be used to add the first admin. user. This could be replaced later for some sort of install plugin, which could also be used to set other configuration options, like setting Elasticsearch, etc.
Ideally, the README file should include how to create, migrate and seed the database in the "Installation (dev)" section.
Parsing METS files can be a really time consuming operation in DIPs with a lot ofobjects and metadata. Such operation should be handled asynchronously using Celery or a similar system. Check:
http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
Initially for development and testing purposes.
Like the 'link' field in the Collection model. Should they be renamed in the interface from 'Finding Aid' to 'Link'?
The migrations created with python accesspoc/manage.py makemigrations
should be committed alongside the model changes. It should only be necessary to run python accesspoc/manage.py migrate
to create the database.
Preliminary design notes / questions:
Logo: see CCA logo-2018.zip
CCA Blue: see Pantone Reflex Blue C.png (blue should only be used as an accent color)
Typeface: CCA currently uses Univers for digital external communication tools and Futura Bold and Book for internal communications tools. Which font should be used?
Visual reference(s): CCA uses their website as their main design reference. Internal tools and platforms have a different look and feel at the moment. This is something that we intend to address in the future. This should be discussed in more detail.
Other client feedback to address:
The bot created this issue to inform you that pyup.io has been set up on this repo.
Once you have closed it, the bot will open pull requests for updates as soon as they are available.
The first time entering the GUI, after the admin user is created in the CLI, yo are redirected to the login page, with the following error:
Internal Server Error: /login/
Traceback (most recent call last):
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/core/handlers/exception.py", line 41, in inner
response = get_response(request)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 217, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 215, in _get_response
response = response.render()
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/response.py", line 107, in render
self.content = self.rendered_content
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/response.py", line 84, in rendered_content
content = template.render(context, self._request)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/backends/django.py", line 66, in render
return self.template.render(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/base.py", line 207, in render
return self._render(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/base.py", line 199, in _render
return self.nodelist.render(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/base.py", line 990, in render
bit = node.render_annotated(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/base.py", line 957, in render_annotated
return self.render(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/loader_tags.py", line 177, in render
return compiled_parent._render(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/base.py", line 199, in _render
return self.nodelist.render(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/base.py", line 990, in render
bit = node.render_annotated(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/base.py", line 957, in render_annotated
return self.render(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/defaulttags.py", line 315, in render
match = condition.eval(context)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/defaulttags.py", line 892, in eval
return self.value.resolve(context, ignore_failures=True)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/template/base.py", line 736, in resolve
new_obj = func(obj, *arg_vals)
File "/home/radda/dip-access-interface/accesspoc/dips/templatetags/custom_tags.py", line 12, in has_group
group = Group.objects.get(name=group_name)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/db/models/manager.py", line 85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/home/radda/dip-access-interface/venv/lib/python3.6/site-packages/django/db/models/query.py", line 380, in get
self.model._meta.object_name
django.contrib.auth.models.DoesNotExist: Group matching query does not exist.
First draft of the user management feature file is temporarily placed in https://gist.github.com/jraddaoui/bc344b32a3a0cb92346a00b3d080da79.
@jhsimpson, how about a features
folder in the root of the project to track this and the following feature files?
Currently, everything is being saved to a "media" directory. Need way to configure multiple (mounted) storage spaces: as size of total DIPs passes 5TB, CCA will need to split storage into several directories
After the introduction of custom Javascript code in #71, we should add tests and syntax checks to this code and integrate them in the CI process.
Similar to the home page, including the Collections table.
The PREMIS events/Preservation Metadata should be hidden by default (showing just the words “Preservation metadata”). If the user clicks on the words “Preservation metadata”, the field expands to show the events. Users didn’t know what PREMIS events were and found them overwhelming to look at, but still wanted to have the information available, if less prominent.
Currently, there are no tests for https://github.com/CCA-Public/dip-access-interface/blob/master/accesspoc/dips/parsemets.py
This class is being re-formatted in #70, which should ease the addition of such tests.
Since we're targeting Python 3.6 or higher we should consider the upgrade to Django 2.x. Some deprecation warnings when running the tests (with python -Wall
):
/src/accesspoc/dips/models.py:27: RemovedInDjango20Warning: on_delete will be a required arg for ForeignKey in Django 2.0. Set it to models.CASCADE on models and in existing migrations if you want to maintain the current default behavior. See https://docs.djangoproject.com/en/1.11/ref/models/fields/#django.db.models.ForeignKey.on_delete
ispartof = models.ForeignKey(Collection, related_name='dips')
/src/accesspoc/dips/models.py:60: RemovedInDjango20Warning: on_delete will be a required arg for ForeignKey in Django 2.0. Set it to models.CASCADE on models and in existing migrations if you want to maintain the current default behavior. See https://docs.djangoproject.com/en/1.11/ref/models/fields/#django.db.models.ForeignKey.on_delete
dip = models.ForeignKey(DIP, related_name='digital_files')
/src/accesspoc/dips/models.py:73: RemovedInDjango20Warning: on_delete will be a required arg for ForeignKey in Django 2.0. Set it to models.CASCADE on models and in existing migrations if you want to maintain the current default behavior. See https://docs.djangoproject.com/en/1.11/ref/models/fields/#django.db.models.ForeignKey.on_delete
digitalfile = models.ForeignKey(DigitalFile, related_name='premis_events')
/src/accesspoc/dips/tests.py:3: RemovedInDjango20Warning: Importing from django.core.urlresolvers is deprecated in favor of django.urls.
from django.core.urlresolvers import reverse
/src/.tox/py36/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
return f(*args, **kwds)
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
/src/accesspoc/dips/tests.py:52: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(view.func, collection)
./src/accesspoc/dips/tests.py:48: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(response.status_code, 404)
./src/accesspoc/dips/tests.py:43: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(response.status_code, 200)
./src/accesspoc/dips/tests.py:85: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(view.func, dip)
./src/accesspoc/dips/tests.py:81: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(response.status_code, 404)
./src/accesspoc/dips/tests.py:76: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(response.status_code, 200)
./src/accesspoc/dips/tests.py:26: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(view.func, home)
./src/accesspoc/dips/tests.py:22: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(response.status_code, 200)
..../src/accesspoc/dips/tests.py:133: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(response.status_code, 200)
Changes needed in the header based on the GUI mock-up:
The accounts app is empty and not being used.
And configure some settings based on the environment.
https://github.com/artefactual-labs/mets-reader-writer
I found it really helpful and easy to use in the DIP creation script and it's being used in some parts of AM and the SS. Although it's not considered to be in a production state, our idea is to move all interactions with METS files to that repository.
Any contribution is appreciated ;)
Without being completely sure of how this works, it looks like there is no pagination involved in the request/response cycle of pages with data tables and that it's being handled by datatables.min.js
.
It also looks like the sort options are being handled by sortable.js
and that it only works with the entire table header, so I'm not sure how hard would be to remove it from columns like "Details" and "Edit" where a sort option isn't needed.
Getting all the data from the server and using this two libraries to do pagination and sorting on the client side will become a problem when the application data grows. Moreover, if the plan is to use Elasticsearch in the future to browse and search over the data, you can't retrieve all the documents from the index at once as it requires a pagination/scroll system to do it. Therefore, pagination and sorting should be moved to the server side as soon as possible.
Ideally, a couple of partials should be created to render the pagination and table header elements and that could be reused for all data tables using include.
The same code is used in several templates to render the breadcrumbs, e.g.:
<ol class="breadcrumb">
<li class="breadcrumb-item"><a href="{% url 'home' %}">{% trans "Collections" %}</a></li>
<li class="breadcrumb-item"><a href="{% url 'collection' digitalfile.dip.collection.pk %}">{{ digitalfile.dip.collection }}</a></li>
<li class="breadcrumb-item">{% trans "Folder" %}</li>
<li class="breadcrumb-item"><a href="{% url 'dip' digitalfile.dip.pk %}">{{ digitalfile.dip }}</a></li>
<li class="breadcrumb-item">{% trans "Digital file" %}</li>
<li class="breadcrumb-item active">{{ digitalfile.uuid }}</li>
</ol>
This should be moved to a partial and create the <li>
elements from a list generated in the views.
For users without Python/Django knowledge wanting to test the application, it would be helpful to add how to use the Django development server to do so in the "Install (dev)" section.
https://docs.djangoproject.com/en/1.11/intro/tutorial01/#the-development-server
And make sure it's included in the Collections and Folder edit and view pages and that is taken in consideration by the new settings to handle DC fields.
Some of the DC fields do not display in the view page of DIP
and Collection
objects. Ideally, the ones that are empty should not display only its label.
Currently, Managers and Administrators can edit all users but Editors and Viewers don't have access to the manage user pages.
An "Edit account" link should be added to the user drop-down to allow access to all users to their own edit user form to change their personal data. This form should not include the "Active", "Administrator" and "Groups" fields if the user is an Editor or a Viewer.
Before moving to production we should consider a more robust database service for the application. Django abstract the database interactions so it should not require major code changes, just configuration. Knowing this will allow us to use that service in the development and test instances to prevent issues when moving to production.
Artefactual needs to provided expanded / improved documentation about the technical infrastructure required to host this application. Initial documentation is in the README.
The management of users and other entities should only be handled from the developed application(s).
This is just a personal preference to make the code a little clear and avoid writing a lot of indented code.
For example:
@login_required(login_url='/login/')
def new_user(request):
# only admins can make new users
if request.user.is_superuser:
if request.method == 'POST':
form = UserCreationForm(request.POST)
if form.is_valid():
user = form.save()
return redirect('users')
else:
form = UserCreationForm()
return render(request, 'new_user.html', {'form': form})
else:
return redirect('home')
Looks a little better like:
@login_required(login_url='/login/')
def new_user(request):
# only admins can make new users
if not request.user.is_superuser:
return redirect('home')
if request.method is not 'POST':
form = UserCreationForm()
return render(request, 'new_user.html', {'form': form})
form = UserCreationForm(request.POST)
if form.is_valid():
user = form.save()
return redirect('users')
This will require to add collection data to the digital files search index and to update that data in all digital files descendants of a collection when that collection changes.
You can find a good example in our automation-tools repository, check:
If an account is deactivated, on the login page display a different error message. Instead of "Please enter a correct username and password. Note that both fields may be case-sensitive." display "Your account has been disabled, please contact the reference librarian".
The DC fields shared between the Collection
and DIP
models should have its own table and be related with them to keep a cleaner database and to avoid code duplication (that could get worse as the app. grows).
Having its own form and partial template to be shared in the other models forms would be great after they are separated.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.