paxswill / evesrp Goto Github PK

Shouldn't be too bad to add negative filters

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

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.

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.

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

Deployment configurable emotes would be rad.

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.

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

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.

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.

Related to #23

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.

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?

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

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

It needs to be turned down

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

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

maybe 5 minutes? or even 0?

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

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).

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).

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

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

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

Maybe even make it auto-refresh the csrf token.

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.

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.

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

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

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).

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

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.

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.

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

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

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.

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

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

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.

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.

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?).

Missed this when doing previous request work.

It's failing too quickly for some reason.

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

Filtering should be available on the details field