• Add a link to create a new loadout based on this ship
• Add a tab that lists popular loadouts based on this ship (and a link to navigate more of them)

Make it an additional check instead of a view permission:

<view-permission-check> [AND/OR] <password-check>

Current password-protected loadouts are just "everyone AND password". It only makes sense to force private visibility on AND checks, thus allowing public password-protected loadouts.

I get logged out of osmium a lot. Should investigate.

Possibly due to it being a negative number, it shows as "not a number" %.

Even though by definition hidden loadouts should not be indexed, indexing hidden loadouts (and maybe returning them in search results made by their respective authors) will make searching, filtering, navigating and interacting with the APIs much easier.

Would make it easier for newbies.

Simple features like adding skills to the plan, adding "all prerequisites for fitting X".

When viewing a skill plan, filter out stuff already trained by the current skillset (ie custom character).

Also showing optimal attribute mapping, and/or optimal cybernetics training time, for starters.

Easily accessible pie graphs of CPU usage, Powergrid usages, and Cost per module type (group all guns, for instance). These will help with identifying relative resource hogs so that fits can be optimized towards these goals.

It doesn't currently seem possible to remove a project effect from an unsaved fit

Because the context menu indicators are not visible on the remote UI, and because drag and drop is needed to establish connections, the UI is currently not usable on touch devices where right-clicking and drag and drop is not possible.

Proposed solution: use something like Hammer.js to map "long press" to right-click, and "double tap" to double click.

This is a display issue, most likely caused by duplicate IDs for the tabs in the modal window.

Fix:

1. Make the tabs in show info dialog not touch the hash
2. Add a random/unique suffix to IDs in the show info tabs

Default visibility, default view/edit permission, etc.

Probably should be in a new section in the settings page, might as well put the default character on it too.

Admin-written scripts that get invoked after a predetermined operation (loadout creation, flag cast, vote cast, etc.).

Short term, they allow for easily customisable notifications for important actions, like sending a text message or a message on an IRC channel when a flag is cast.

Long term, they could alter the operation. Like deny loadout creation if it doesn't match some admin-defined criteria, etc.

At the moment, there's very little protection against spam/flood bots.

• Rate limiting some critical actions (like creating accounts, posting comments/loadouts, etc.) would be a good start.
• Requiring manual validation by a moderator after a certain threshold would be another great first step.
• Try to find FLOSS alternatives to spam filtering services like Askimet, etc.

Right now it's a bit too arcane, and the readme is a mess.

SVG is great. Easily generated programatically, cacheable, compresses well, and it can contain CSS styles and JS snippets for interactivity.

RT indexes are fairly RAM-hungry compared to plain indexes.

An idea would be using a distributed index, using two indexes:

• A plain index for the bulk of the loadouts;
• A RT index for loadouts that recently changed.

The RT index would be periodically truncated, its changes merged back in the plain index.

However, this poses several issues:

• How does sphinx handle duplicates, for example if a loadout in the plain index gets updated?
• How to handle deletion, for example if a loadout in the plain index gets deleted?
• Merging is tricky, especially without incurring downtime.

Before doing any of this, maybe do a test with a plain loadout index, see if the RAM usage gain is worth the hassle.

• Add a reason when editing a loadout, show it in the loadout history. Useful to explain moderation actions when editing someone else's loadout. 2a12f77
• Add a way to transform a comment into a comment reply. Useful for correcting people who reply to a comment with another comment.
• Notify the user when deleting a comment/loadout, add "reason" text. Also notify anyone that replied to the comment being deleted.
• Temporarily/permanently revoke/grant privileges of a specific user.
• Add Atom feed for flags (with a secret "key" parameter settable via config.ini, so only admins can access it).
• Temporary or permanent character/IP bans. NB: this is not as useful as it seems. We can effectively shadow-ban users by revoking the create public loadout/comment public loadouts privileges, so they can't harm anyone yet they can still make fits for private purposes. In the rare cases where an actual ban is needed (DoS etc.), the Osmium code is not the right place to do it.
• View log/clients tables. Add ways to filter them.
• Restrict account creation. At least rate-limit it (1 per day per IP ?).
• Lock comments on loadouts. Moderators and people with edit permission would be able to change this.

The filters are duplicated, when editing a fitting in firefox 29.0.1

http://imgur.com/yQrVghV - What it looks like

http://pastebin.com/98fnpimk - Copy of filter code from inspection

Preamble: I poked around a fair bit, and couldn't find anything like what I'm proposing. That said, it's quite possible I'm an idiot, and this already exists, in which case, feel free to tell me so!

So, when looking at or creating a loadout, you get a character choice, which is great, but:

When browsing loadouts, the little info box you see gives DPS, EHP, etc, but it's not clear which character is used to calculate this. Similarly, when doing DPS comparison graphs, it's not clear which character is used for the stats.

A choice for both of these options would be nice; the DPS graph has an obvious UI to add it to, but the browsing one, not so much, which dovetails into the next point:

It gets annoying every time you create/open/etc a loadout, to have to swap the character back to your own. So add a profile setting for "Default Character", and then use that:

• as the default when you view/edit/create a loadout
• to calculate the stats when browsing loadouts
• as the default in the DPS comparison graphs

This would further allow an indication on the loadout info boxes when browsing of whether the fit requires skills the default character doesn't have.

For backwards compatibility, make the new setting start as the 'All V' character, and also use that for users who are not logged in. So nothing changes, but users who want can switch the default to their own character, and then see everything tailored to them.

Make it easy for people hosting their own instance to hook up another authentication source: like corporation forums, etc.

When opening a fit, display the damage profile the author selected, instead of defaulting to omni.

While PvP fits always fit omni tanks, save for special situations, pve fits will generally not. An example tank is shown, intended for a specific NPC faction's damage profile. Ideally, you would get the intended tank numbers displayed upon browsing to a fit, instead of having to figure out what tank was used and then selecting the appropriate damage pattern.

When an account gets API verified or lose its verified status, the loadouts owned by the account should be reindexed to reflect the change.

It'd be really nice to be able to see the minimum required skills as already calculated in the mastery window to display missing skills. Creating a "Metaskillset" of them,

Allow users to preview any Markdown stuff (like comments, loadout descriptions, preset descriptions, etc.) before submitting.

Could use the saveAs method from the File API.

Benefits:

• Simpler registration
• Password reset is no longer our problem
• Gives us an email address to potentially contact the user in case of emergency

Issues:

• Dosen't play nice with NoScript
• Requires JS and a recent-ish browser
• Reliance on Mozilla
• How to handle old accounts? Force them to use Persona, or still allow legacy login and registration?
• What would be the accountnames/passwordhashes of Persona accounts (make up random ones or allow NULL values in the schema)?

Make it easy for people that want to host their own instance to restrict it to a predefined list of alliances, corporations, people etc.

BEGIN gzCLF BLOCK
eJzdU8tqwzAQ/BWz16qgV2xZt0Khp556LDmo1qYROLIrK4UQ/O9dJw1xUgjkWp00s7OzQhrt
oWlXj9+YhtBFsIIRDhjzmapULcuKwQaz8y47sHvIIbcIFt7WAVtfvKD3JGXgcWhS6POhEYho
EroJUeOkf+0iK4QunvpUSE4bYazmVuvigdOCkcGwDv1hxK7H4MGWWhHbJxwwD2Df97/76DaT
4zOu3LbNxZGkiZvOb1s8Kk8eUnExshmW5iZWRl/WuTZzrDVf3IOllLW4kyi5MfcRWtXVHIua
no6eYO3S5/WF6IVS4/JfqEtd1X+J5clgnpypzBlcReeoOyWI3KnXpy7ijbgd6ufQhfjhdpcn
NVLQZ/raukifhWqCT74hDr1r8LZ0MZ1h/AGLryba
END gzCLF BLOCK

Edit, delete the first rig, save. Rig is still there.

Thanks to Deveyus for finding a way to reproduce the issue.

I'd like a way to, from a module, see skills that affect the module's attributes, and override the level in the skillset. This would be for answering questions like "Argh, what skills do I need to get this thing cap stable?"

It would be very helpful if price was included when comparing types. For example, when there are four types that all have identical stats I would choose the cheapest one.

Often I want to save and edit a DNA loadout, but I'm not logged in. When I hit the login link, after logging in, I land on the osmium homepage, and then I have to find the fit a couple of pages back in my browser history.

Right now the code roughly assumes that the API is always working and returning data that makes sense.

Ideally, API fetches/errors should be logged, and users should be notified when their API keys goes invalid or errors out.

Database-wise, keys (for accounts and character skills) should be put in one unique table.

Related to #11.

With SSO (Single Sign On from CCP) being available to third party devs any day now, using it to provide a seamless user experience will be difficult, considering the current structure in place with accounts.

• Initial login – user logs in with SSO with a character Osmium doesn't know about. The sensible thing to do would be to create an account then tie the character to it. This can get problematic if the user then stops paying his subscription but still wants to access the Osmium account. A solution is to refactor authentication methods and allow accounts to have many of them: traditional user/pass, SSO, Persona, OpenID etc.
• API verification overhaul – with SSO, accounts will be able to have character credentials without being API verified, yet the codebase checks for API verification to use them. Also, an account could use SSO for logging in but still want to use the API verification to import the contact list. Could handle this by adding a ssoverified column in accounts.
• Character transfer – if a character switches accounts, the new owner should not be able to access the Osmium account created by the previous owner. Need to store some kind of account-unique identifier in accounts for SSO-verified accounts.

Make the loadout UI more friendly to small viewports.

• Make the source/attribute side bars retractable
• Mini mode for the attribute bar that only shows vital attributes
• …More?

The current UI doesn't show module states, which can be a bit confusing when projecting them.

They are an important feature and are unsupported by the in-game browser.

An alternative is (like the main sprite), a container with hidden overflow, and insite is the absolutely positioned image.

Would require changing the graphs a bit to draw the legends in the canvas itself instead of around it, then use the saveAs from the File API to save the canvas as an image.

I get the following error with different keys over and over in my logs (and sometimes also reflected in generated pages):

PHP Warning:  sem_get(): failed for key 0x7fffffd7: Permission denied in /srv/www/osmium.atlantis-ascendant.com/inc/state-cache.php on line 435

I can fix it by changing the sem_start key in the config.ini but after a while it will just occur again.
I think it starts whenever I try to call up a fitting from a user's submitted fittings page instead of search or the overview, but I'm not perfectly sure that is not just coincidence.

Using Osmium 0.13.0 on Ubuntu 12.04.4 LTS with a 2.6.32 kernel and running on Apache 2.4.9 with PHP 5.5.14.