Views & IP Address Field module integration for IP Login

Updated patch, to supersede the first, that includes the hook_views_api in ip_login.module

Here's a somewhat redacted screenshot of the default IP Login users view attached.

I'm looking into a patch to provide a Field API field for IP Login, perhaps using the field_ipaddress module.

The Field API automatically provides Views integration, so this patch can probably wait until then.

It does work on the current codebase however.

Thanks Jim,

I like the idea of a dependency on field_ipaddress too, as the module specialises in IP address handling and also makes it quite easy to do the IP range matching to user.

As for the issues you mentioned:

We need to ensure that this new module's field can handle all the ranges, wildcards and other bits -- e.g. it appears to have separate widgets for CIDR notation, but that's at UI-level only (hopefully).

While there is a CIDR notation widget available, I've been testing with the "Shorthand" widget ( x.* ) which is more end-user friendly.
Theoretically, a familiar user could switch to use the CIDR style widget instead.
Does the current version of ip_login support both styles in the one textfield? If so, that may be a problem as it looks like the widget needs to be one or the other.
field_ipaddress does handle the required ranges, e.g 203.0.0.0 - 203.45.3.12, 203.45.0.0 - 203.45.3.12, or 203.45.3.12-14 as well as 203.45.3.*

We'll need to have some hook_update and migrate code to move from the ip_login_users table to this field. OR support both, which kinda sucks from a code redundancy/maintenance/legacy PoV.

Yes, just using the field storage is alot simpler here and saves duplication and rework.
I'm thinking either an update hook, or a page where an end-user can migrate the data across. Migration is quite easy to do.

Since this approach (field API or other modules) won't work for D6, we'll always have this legacy codebase until D6 is end of lifed, and that'll be a looong while yet... On the bright side, 6.x-2.0 is nice and stable and we can just backport the views patch you're working on.

Yes, that makes sense, we'd keep the existing approach for the 6.x branch.

As for:

Use field_ipaddress only for future D7 3.x branches when that module has everything we need, but leave D6/7 2.x codebase with ip_login_users table PLUS your views patch.

Agreed.

Cheers,

DT

OK, I've got an update working with field_ipaddress.

As field_ipaddress takes care of all the validation while data storage and retrieval is all done by the Field API, it means we're able to remove quite a bit of code from the base ip_login module, such as insert, update hooks/code

I've also put together an update hook that creates the field_ip_login ip address field and uses the batch api to migrate user ip data across to it.

All my 195 test IP addresses were migrated successfully across to the new field, including address patterns like

123.45.67.*
123.45.*.*
123.45.67.89/24

So that's looking good too.

cheers,

DT

Jim, there's a new 7.x-3.x branch committed to git that contains a working copy of IP Login using the field_ipaddress module.

An update hook / upgrade path is provided there for migration.

I'm thinking to publish a new 7.x-3.x-alpha/beta branch with this update soon.

Please test it out and let me know what you think.

cheers,

David

Heh, yes, this one's ready for testing.

Using it myself.

Cheers,

DT