{"action":"created","issue":{"url":"https://api.github.com/repos/R4stl1n/allianceauth/issues/564","repository_url":"https://api.github.com/repos/R4stl1n/allianceauth","labels_url":"https://api.github.com/repos/R4stl1n/allianceauth/issues/564/labels{/name}","comments_url":"https://api.github.com/repos/R4stl1n/allianceauth/issues/564/comments","events_url":"https://api.github.com/repos/R4stl1n/allianceauth/issues/564/events","html_url":"https://github.com/R4stl1n/allianceauth/issues/564","id":185986140,"number":564,"title":"CREST FAT","user":{"login":"Adarnof","id":14036610,"avatar_url":"https://avatars.githubusercontent.com/u/14036610?v=3","gravatar_id":"","url":"https://api.github.com/users/Adarnof","html_url":"https://github.com/Adarnof","followers_url":"https://api.github.com/users/Adarnof/followers","following_url":"https://api.github.com/users/Adarnof/following{/other_user}","gists_url":"https://api.github.com/users/Adarnof/gists{/gist_id}","starred_url":"https://api.github.com/users/Adarnof/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Adarnof/subscriptions","organizations_url":"https://api.github.com/users/Adarnof/orgs","repos_url":"https://api.github.com/users/Adarnof/repos","events_url":"https://api.github.com/users/Adarnof/events{/privacy}","received_events_url":"https://api.github.com/users/Adarnof/received_events","type":"User","site_admin":false},"labels":[{"id":134661262,"url":"https://api.github.com/repos/R4stl1n/allianceauth/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-10-28T18:10:01Z","updated_at":"2016-11-01T17:56:12Z","closed_at":null,"body":"### Overview\n\nSince IGB is dead the current FAT system doesn't work. Two options, scrap it, or introduce a CREST-based one.\n\nI'd like to scrap it but I know some people use it. Before continuing please read the following warning:\n\n**I STRONGLY BELIEVE TRACKING FLEET PARTICIPATION CREATES AN UNHEALTHY ENVIRONMENT AND FAILS TO RESPECT PILOTS' REAL LIFE COMMITMENTS. I STRONGLY DISCOURAGE THEIR USE.**\n\nNow that you've read the warning, let's talk about how to proceed. I've already incorporated SSO into auth, so we can now access CREST resources easily. It's just a matter of deciding which data we want.\n### Endpoints\n\nThere are two relevant endpoints available for the data we need:\n- `characterLocationRead` tells us, with up to a 10s delay, what system and (if docked) station a given pilot is located\n- `fleetRead` tells us, with up to a 10s delay, what system and (if docked) station each fleet member is located, as well as their active ship type and name.\n### Straight-Forward Approach\n\nThe easiest implementation would be for the fleet boss to, at a time of their choosing, go onto auth and take a \"snapshot\" of the fleet to be processed (I'd like to hand that off to celery, as the response time for large fleets could be in the minutes range).\n### Two Factor Option\n\nThere are certain scenarios in which you do not want members not actively participating to be able to get a FAT. Normally this would occur when the FC hands out the link, these members would not notice and hence not redeem it. Straight polling the fleet members endpoint would grant these members a FAT where previously they would not get one.\n\nSo an option to prevent this is a 2-factored approach. As before, the FC presses the \"go\" button and pulls member ship types. He would then hand out the typical FAT link which members would redeem via the `characterLocationRead` endpoint. The returned data would get their ship type added before being saved as a FAT.\n### Database Work\n\nThe problem with FATs is they need to be associated with a user. This can also occur in two places:\n1. upon creation, check the authenticated character's owning user and save there\n2. save FATs independent of user and when needed collect all FATs for the user's characters\n\nOption 1 is a lot more work during the saving process, is inflexible to character account changes, but would result in very fast queries when gathering statistics.\n\nOption 2 is much faster saving, would require we go the 2-factor route, ensures the FATs are always collected for the correct user even if characters change accounts, but would make statistics requests much slower.\n\nI'm not sure which is better honestly. Option 1 would work for most cases, but I don't like that it's attached to a user independent of the character's user.\n\nTo report accurate statistics, we would also need to tolerate saving FATs without associated users. This idea favors option 2 as we could simply not save the user, ever.\n### Fleet Creation UI\n\nThis new system would simplify the UI for the fleet boss a bit. Users who can run fleets would be granted a new permission on auth, hypothetically `fleetactivitytracking.add_fleet`. Users with this power would see a button to generate a fleet, and upon pressing be taken to a form requesting fleet details (a name mainly, perhaps additional info like purpose, comments, SRP-able etc). Note that fleet details are entirely unnecessary and we could simplify the process by not requiring them.\n\nAfter creating a new fleet, the boss would be prompted for the fleet URL (which is gathered in-game from the fleet members window, top left options, copy external URL) which would be saved. Either upon saving, or perhaps later with the press of a button, a snapshot of the fleet would be taken.\n\nIf we go the 2-factored route, a link would have to be generated to be handed to fleet members, and an option to stop accepting fleet participation submissions from that link either queued for a specific time/duration (via celery) or at the discretion of the fleet boss.\n### Reporting Engine\n\nThe whole point of FATs is to track member participation. Which means we need a way to report this with useful metrics.\n\nI have no idea what people are looking for here, so it's hard to design a reporting system. Please tell me what kinds of reports you would like to run.\n\nAnother option is to simply build a generic reporting engine and let fleet bosses generate their own queries. [There are a whole bunch of Django packages to base this off of.](https://djangopackages.org/grids/g/reporting/) Most of these package work at the database level so we would have to provide custom queries by default (again I need to know what people want to know).\n### Decision Time\n\nWhat do people want? Any obvious advantages or disadvantages? What use cases would you like in a new system? Do we want to preserve old FATs?\n"},"comment":{"url":"https://api.github.com/repos/R4stl1n/allianceauth/issues/comments/257640818","html_url":"https://github.com/R4stl1n/allianceauth/issues/564#issuecomment-257640818","issue_url":"https://api.github.com/repos/R4stl1n/allianceauth/issues/564","id":257640818,"user":{"login":"CokkocZateki","id":16074209,"avatar_url":"https://avatars.githubusercontent.com/u/16074209?v=3","gravatar_id":"","url":"https://api.github.com/users/CokkocZateki","html_url":"https://github.com/CokkocZateki","followers_url":"https://api.github.com/users/CokkocZateki/followers","following_url":"https://api.github.com/users/CokkocZateki/following{/other_user}","gists_url":"https://api.github.com/users/CokkocZateki/gists{/gist_id}","starred_url":"https://api.github.com/users/CokkocZateki/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/CokkocZateki/subscriptions","organizations_url":"https://api.github.com/users/CokkocZateki/orgs","repos_url":"https://api.github.com/users/CokkocZateki/repos","events_url":"https://api.github.com/users/CokkocZateki/events{/privacy}","received_events_url":"https://api.github.com/users/CokkocZateki/received_events","type":"User","site_admin":false},"created_at":"2016-11-01T17:56:12Z","updated_at":"2016-11-01T17:56:12Z","body":"For us each fleet has its own fc. so that fc can generate their own. Not sure how the others work."}}
{"actor":{"display_login":"CokkocZateki"}}