paxswill / evesrp Goto Github PK

Different divisions may have different requirements for processing, so figure out if there's a way to facilitate that.

(pasting in from #86)

Right now the information from a killmail has a 1-to-1 relationship with the information about a request (sidenote: Killmail info is like the time of loss, where, who. Request info is payout, modifiers, division). Splitting the concept of a request would also mean changing a division would no longer be a thing, and would mean you could apply to multiple divisions at once.

Problems to solve include:

• What information to share across divisions and how to share it.
• How to migrate existing requests (probably an Alembic migration from hell).

It should be specified more strictly, maybe all absolute modifiers then percentage ones?

Use Flask-Script for the little admin tasks like creating the database schema or migrating the schema.

Also investigate providing low-level admin tasks like creating+modifying divisions, requests, etc. Maybe also allow forcing changes to go through using the constraint/verification skipping I was thinking of adding for the tests.

Error pages (404, 403, etc) are currently a boring default. They should be styled like the rest of the app.

Maybe a brief little floating window, or maybe have a mouseover thingy like the payout does.

Details should be updatable, in case the submitter messes up. When updated, the request should be set back to evaluating if it was marked incomplete.

18:57:43 Arnath_Othorem: ui complaint: "Killmail URL" should specify what kind of url it wants before I try with a wrong one

Admin permissions should be grantable in divisions separately from the site admin permissions.

Current deployed version on braveineve.com is missing a fulltext index on the requests.details column. Not sure if the DB is built on deploy but something to look into. Adding the index fixed the details search.

CSV for Excel, although XML with the API key process would probably work best (ImportXML in spreadsheets would be cool).

Auditors can view requests, but not change them. Pretty simple, and gives a way to allow leadership to see what people are reimbursing (like a CEO seeing what his corp members are submitting for reimbursement at an alliance level).

Probably as query arguments. For the AJAXy goodness of Pourover, I'll probably use history.js to keep the history state workable.

This'll also probably mean I'm going to remove page numbers as part of the URL path for request listings.

Show users stuff like maybe stats (#1), what groups they're in (although the auth source should handle that), what divisions they have permissions to.

Reviewers/Payers should be able to make notes about Users, like if a user has been warned about something and shouldn't be given leeway in the future.

Upgrades are going to be a pain if there isn't a way to migrate database schemas. Maybe look into Alembic.

The spate of bugs I ran into point to a massive need for proper testing. I've skimped on them so far, but there've been a bunch of regressions and I need to fix them.

Need to add a payout view so payouts can be done quickly by payers

I want to be able to evaluate all ships of a certain type (maybe in a certain system) with links to go to the next request directly.

When a request is moved to a new division and the mover doesn't have access to the request anymore, they should not get a 403 error.

Use case: TEST has online skill sheets, and these are occasionally used in evaluation.

The default form width is really wide (at least for medium+ size viewports).

Shouldn't be too bad to add negative filters

Brave Core support is lacking, it doesn't really work with groups yet and I need to figure out what needs to happen to fix it.

Sometimes reviewers will both be on the same request at once. It'd be nice to have maybe an advisory lock for a few minutes after a reviewer opens a page. Maybe have the lock get refreshed when the page is viewed (ajax-y and maybe a view event thingy?).

There's a ton of queries done per page, I need to get that number down.

Maybe hover on the calculated payout? I don't want the base payout super prominent as it can be confusing for some people (me when doing payouts, although payout mode should help with that).

It needs to be turned down

An empty result is returned from the app, for all interfaces (HTML, JSON, XML). This is throwing me for a loop.

Right now 'paxswill' is hard-coded in to the TestAuth module. This needs to be fixed before too long so other people can stand up their own instances and play (and maybe contribute).

I'm thinking of adding an argument to the AuthMethod constructor taking a list of IDs to treat as admins. That way every AuthMethod will have access to it, and I can probably work it into the constructor to set the admin flag.

It's failing too quickly for some reason.

Maybe even make it auto-refresh the csrf token.

Have a way to notify users (maybe groups as well?) for comments on requests, or when certain statuses are done. Maybe add a button for reviewers?

Filtering should be available on the details field

Sometimes people screw up, so the division should be modifiable by either the submitter and/or the reviewer (and maybe payer as well).

Payout mode can have a high probability of double-payouts if two people are paying out at the same time. Tangentially related to #16, but this is slightly different, so rows can get updated in real time.

Add support for easily adding new languages without rewriting tons of stuff. Look into Flask-Babel to see if it's a good fit.

Something like OpenID or along those lines. A non-affiliated option. It should also be set as the new default AuthMethod, to make initial setup easier.

Deleting items (while rare) should work properly if an admin decides it has to be done.

Related to #23

They show even if the logged in user doesn't have those permissions anymore.

Missed this when doing previous request work.

maybe 5 minutes? or even 0?

Not sure why I didn't do it in the first place, but it needs to be fixed.

Example links:
http://zkillboard.com/kill/0 and
http://zkillboard.com/kill/123081203874108723408712304871203487102374172304

Deployment configurable emotes would be rad.

Lists of requests should be filterable by things like date, ship, system, pilot, user, corp, alliance, etc.