Closed PerMalmberg closed 8 years ago
A quick start guide makes a lot of sense. I'll get on that.
Yes, you need a separate user account (not django admin) because of how the logic surrounding blue members works. It's dumb, fixing it is on the to-do list.
Groups are created from the django admin interface. From there you should assign your user account every permission except auth | user | blue_member
as well as mark the account as staff.
Assign the permissions that begin with auth to users or groups as you see fit. A description of what they do is available in the readme for this repo.
Fits is actually a static html page. Edit its template in stock/templates/registered/fleetfits.html
or something, and save changes to customization/templates/registered/fleetfits.html
Groups are used to assign permissions to swaths of users. Assigning permissions to groups in the admin interface ensures users added get them. Users get added to groups by requesting access from the website or you can manually edit their user in the admin interface. These groups also sync to all services where you can customize their access.
Awesome, great info. I'll be back with more feedback once I've tried things out.
So far, it all seems to be working.
I'm missing these functions regarding HR:
auth | user | human_resources
is missing the ability to show closed applications iircauth | user | corp_stats
gives you ability to see characters and APIs, don't remember if it actually groups by mainI'm interested in getting into Python so I might take on some of these tasks.
Sounds great! Just note on my to-do list is to attach API keys entered into auth to the applications, rather than having users manually enter APIs as text to the application.
I've double-checked with the XML API documentation, no way to pull corp members, so no way to show un-auth'd members that I can figure out. Maybe EVEWho scraping? I can see this being useful, but not critical.
It wouldn't be too hard to add the ability to show applications based on result - just need to pass a variable of status to this logic maybe via a custom variable in the URL handler to get parsed by the view, default being to show those still waiting approval (approved_denied == Null)
For corp stats grouping, you'd have to add additional logic to the view and template. The character models have a user field so you can easily determine which characters are associate with which account by filtering by user. You'd have to create a more complex context to be rendered by the template: my suggestion would a list of dicts, something like:
account = {
main: main character
alts: [list of other toons]
apis: [list of API keypairs]
}
And then have the template loop through each account, listing the main and then alts with a jacknife link for each api. You could also sort the API keys by characters, that would require slightly different logic, depends what you feel is best.
(% for account in corp_accounts %}
render main character in a div
{% for alt in account.alts %}
render alt name in a div
{% endfor %}
{% for api in apis %}
render jacknife link for api
{% endfor %}
{% endfor %}
This would be a fantastic project for you to work with Python. I've just suggested how I would tackle these problems, if you come up with another solution go for it!
Thanks for the feedback, I'll try to get some time to dig into this during Christmas. I guess that it will be Django that is the larger hurdle to get grips on, Python is after all just another programming language.
Yes, having the system provide the APIs to an application is a great idea, but how about being able to select a character to do the application with? That way you can do multiple applications to get alt-characters into a corp too, without having to select a new primary.
Django has some of the best documentation I've ever had the pleasure of using. Note that we're on Django 1.6 iirc.
Why multiple applications? An application is attached to a user, and users have characters associated with them, as well as a main character defined in their AuthServicesInfo. If someone's applying, they should enter their main and alts' APIs into auth and then make one application, with recruiters being able to see all APIs associated with their account - ideally with some indication of who is the main. At least that's my grand vision. Would need to double-check AuthServicesInfo models are generated on account creation and enforce main selection.
Quick start guide is now available on allianceauth.com. Let me know if it needs anything more.
The thing with multiple applications is that we don't accept alts into the corp without verifying we've got the API on them. As such, multiple applications would help a lot. Another thing that would be nice is to get a notification whenever a character leaves the corp, or the API expires.
Good quick start, gives a push in the right direction.
A notifications system has been on the drawing board for a while now, no progress however.
You can verify there's an API on file through the corp stats page. The goal of the applications on AllianceAuth isn't to replace in-game applications, rather to provide an alternative to a google form for collecting information about applicants.
Google forms are exactly what we're trying to get away from. If an alt applies via AA, it can easily provide the API, contrary to an in-game application. And yes, the corp-stats page also shows the sought info, but it requires a manual search and we're all lazy :)
Anyhow, I'll come back to this later on once I've familiarized myself with Python.
Just realized I'm wrong - not in every case will you be able to check the corp stats page for an atls API if that alt isn't on the account of a member in corp. Curious. I don't have a good solution except, as you stated, multiple applications. Or some way to check all registered APIs for a character's account.
It's been 2 weeks, gonna go ahead and close this to keep things tidy. You know where to reach me.
Perhaps I'm just misunderstanding things and expecting too much from AA, but now that I've gotten AA up and running (no services yet installed) it feels as if there is something missing.
I've registered, added an API and selected the primary character.
I suppose, what I'm really asking is how do I make a character into an admin?
A short getting started guide would be very helpful.
Lastly, I think I remember reading somewhere to use a separate non-admin account for day-to-day business; was that for AA or have I mixed it with something else?