As a researcher, I can see a list of catalogue items available.

• catalogue items read from database
• items are links to the URN
• alphabetic order to start with
• convert from selmer to hiccup? (write rationale)
• basic tests at hiccup level
• no pagination needed for now

Applicant/approver can close an application

• extract concept of handled applications (approved, rejected, closed) and use it
• applicant can return applications with status applied (withdraw/cancel application)
• changing application to status approved -> closed (applicant only)
• use modals for scary closing operations

• opening with view button
• approver can see the comment rows
• approver can edit the comment rows
• approver can go back to the approvals page
• approver can approve and reject in the form view

cloverage doesn't work (fails with tempura :t/foo/bar keywords)

lein with-profile test cloverage fails

• separate roles table
• widget for switching active role if multiple available
• persist active role in db
• active role(s) available in context

E.g.:

• a readonly transaction for every GET
• a readwrite transaction for every POST

• roles for the usual users: developer, alice, bob, RD{applicant,approver}*
• multi-round workflows and items
• applications of all states?
• localized link licenses

Get look-and-feel feedback from Kielipankki in the demo. (Colours, fonts, etc.?)

As a researcher, I can fill in the application form corresponding to the item in my basket.

• labels (label)
• short text field type (text)
• long text field type (texta)
• partial applications stored in db with the draft state

• favicon
• logo image
• colors
• translations with __load-resource
• try to read external resources first and then war resources
• convert to using garden
• defaults in resources/theme, resources/translations/*.edn, ...

• user can only access own applications / drafts
• user only sees own applications / drafts in application list
• POST handlers check user & rights
• read user id from shibboleth session
• store user id when creating application
• support for multiple users in fake shibboleth
• support displayname etc. fields of shibboleth user

• flash message after saving
• "back to catalogue" button
• button styling: spacing, back on the left, save and apply on the right (use actions css class)

build uberwar on travis, transfer to pouta

store archive of uberwars on pouta persistent volume

As a researcher, I can add a requested resource to basket, and see the contents of my basket

• basket stored in session
• test at hiccup level
• create basket contents component
• initially place basket component in content pane above the resource list
• remove item already added to basket

• Travis already configured
• Autodeploy for master branch
• Use Docker
• Deploy to Amazon ECS. Approval for t2.medium instance (~$4/month). or pouta?

As a researcher, I want to see the # of resources in my cart

• "5 resources in cart" in the cart title

The current data model, inherited from the old REMS is complex and sometimes makes code quite complex. I think the model could be simplified without losing expressivity or features.

It's important to remember that the more our data model diverges from the old data model, the more migration scripts we need.

Ideas (in random order):

General localization

Instead of separate localization tables for each table, we could have one table of localizations, that the other tables would reference with a localizationKey.

However this would make searching by localized data (e.g. search for catalogue items that contain "kuusi" in finnish) less efficient.

Minor normalization work

• entitlement references both resource and catalog_item_application, even though we can get to it via catalog_item_application -> catalog_item -> resource
• catalogue_item_application_approvers references workflow_approvers via id, but also duplicates the approver user id and round

Use more natural keys

Synthetic keys (id serial PRIMARY KEY) make database access code more complex. Natural keys would simplify many tables. Examples:

• resource could use key resId
• application_form_item_map could use key (formId, formItemId)
• workflow_approvers could use key (wfId, round, apprUserId) (with index on (wfId, round) if key prefix searches aren't efficient)
• catalogue_item_approvers could use key (catAppId, round, apprUserId) (with index on (catAppId, round) if key prefix searches aren't efficient)

These might have some performance implications, but the data amounts are pretty small and so it shouldn't be a problem.

As a native Finnish user, I can change the language on the site to my native language.

• Use tempura library?
• Finnish, English (*Swedish)
• Language switcher component
• Separate translations file
• Initial language according to browser preferences
• Store language in session
• Unknown language => English
• Tests at the hiccup level

As a researcher, I can view the applications, that I have applied for, and its/their status

• id
• status
• resource
• last modified creation date
• "View" button

• use the html5 required attribute?
• sending an application with missing required fields fails
• saving a draft with missing required fields works

• application phase component
• highlight current phase
• show in applications and approving view

active class could be added to this nav-link.

• localized names from db

• Use postgres & migratus
• Integration tests run by travis against postgres
• Document db initialization
• Script for migrating data from old mysql database
  1. use pgloader to move old data from mysql to postgres
  2. shell script that munges data from pgloader's tables to our application's tables. Shell script should be idempotent if possible.
• remove rms_ prefix from tables

As a researcher, I want to be able to view the license agreement and be able to approve to the terms and conditions if I so choose.

• license field type
• only link license type required
• localize licenses
• validate that licenses have been checked before submitting
• save also license agreements in draft

@tjalka has a shell script already

Currently there are asserts in the apply-event code. There are also checks in approve-application etc. that try to guarantee that events that fail these assertions never get added.

This is a fragile design. It's easy to make a mistake with changing the two sets of checks. Also, one invalid transaction will break lots of stuff, as for instance get-approvals runs get-application-state on many applications.

Some options:

• Add an invalid state that applications go to if an event can't be applied
• Ignore invalid events (this does the right thing with e.g. double approval)
• Change the code so that e.g. approve-application uses a transaction to 1) add the event 2) run all events 3) commit transaction only if sequence of events is consistent

• catalogue page
• application page
• actions page
• click header to sort

As a researcher, I can checkout to apply for the resources in my basket.

• send button at the end of the application form
• update application status from draft to applied
• show read-only applied form without save buttons
• splash message "application sent"
• back to catalogue button
• remove resource from basket

• top nav is too high
• center login vertically in available space
• add space between catalogue table and footer
• "you don't have any applications" text instead of empty table
• save as draft should be green when saving us successful
• when saving draft the required fields should be in white (don't complain)
• placeholder text should be lighter colour
• approve, reject, view button colors
• back to approval button position
• "Liitä päätökseen kommentti (näkyy hakijalle)" for approver
• "Päätöksen kommentit" for applicant
• style the decision and comment section text as box
• put the approval decision to the top in its own box (success green if approved, danger if rejected)

Ask for confirmation in approvals. Pop up window with commenting.

• add confirmation modal for approving / rejecting (closing, review)
• commenting moved to modal

• check console access
• remove examples
• remove docs
• take into use manager & host-manager
• install fail2ban
• investigate other hardening options
• installing apr with ansible

Encoding is incorrect in the dissplayname and license texts.

Is this a problem with DB connection or perhaps file.encoding of the server?

lein migrate etc. are very slow to start

measure and find out if it can be made faster

Currently rejecting the application returns it to the applicant.

Should rejection be separate from the returning? Or is rejected application always available for re-sending?

As an approver, when approving an application, additional information can be accessed through expanding fields

• Status with events
• From applicant status
• Application also collapsible but default is open
• Remove application title
• applied items (only one resource for this)
• visual improvements to the form after features done

• support workflows where any approver can approve ("parallel workflow")
• access restricted by workflow-round-approver
• approve action:
  • increment round
  • create row in catalogue_item_application_approvers
  • change state applied -> approved
  • if final round, create entitlement
  • TODO @tjalkane to check this
• reject action:
  • change state to rejected
  • create row in catalogue_item_application_approvers

As an approver, I want to be able to view the applications I have approved

• dummy buttons for export, statistics (under construction modal)
• list of handled applications sorted recent first (under the open approvals)

Don't show login component for signed in users that navigate to root

• reroute signed in users to landing page

• delete all resources
• close AWS account

License approval is not shown in the approver's view of the application.

Rems is possibly fetching by the approver's id and not by the applicant's.

As an approver, I can view the applications that need my approval.

• new "approvals" view / nav item
• only visible for "approver" role
• show applications that:
  • are in state "applied"
  • have a workflow with the user as an approver in the current round

• Use shibboleth:<eppn> as user id for shibboleth users
• Store shibboleth json blob in table