Drupal 6 port
| Project: | Login Ticket API |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | crdant |
| Status: | closed |
I know that people are using this module, and that there is a need for it to be ported to Drupal 6.
However, given other modules that I'm also responsible for (and which are more important for me) it's unlikely that I port this module before my company has a pressing need for the port, which is not yet the case. I suspect we'll tackle the the remainder of our module ecosystem this fall, but that's still long to wait.
So, I welcome anybody who wants to provide patches for this module to get it ported to Drupal 6. It will likely be a good idea to implement the remaining part of issue #229797: Introduce an autoincrement integer id before starting the port, because we'll need it anyways sooner or later. This is open source, so feel free to chime in and help out if a timely port is of importance to you. It's a small module, and this task causes a comparatively little amount of effort, making it ideal even for people who are just getting started into Drupal development.
Hm... actually, I should probably endorse this issue on DROP because it's so nice :)
#1
attached is a 6.x port by using Deadwood
i have also applied the changes in Introduce an autoincrement integer id to this port,
up to my own comment #7 patches
#2
oops... forgot to upload the file, so here it is.
as i'm still working on the Temporary Invitation 6.x Port,
so i don't have the chance to test this out yet
but it installs nicely on my drupal 6 development website
#3
bug fix version, fixing the length of char field passcode_md5 in install file sql
this one is working fine with my Temporary Invitation 6.x Port on my dev website
#4
I had run through the same steps with Deadwood and the char length update and came by to post my patch. We've now included this version into our custom login routine (takes some info from client's Notes database and generates a ticket) and have it working as expected.
#5
I noticed reading through the uninstall hook that it does something a bit odd . . .
<?php
function loginticket_uninstall() {
// Remove tables.
drupal_uninstall_schema('loginticket');
include_once(drupal_get_filename('module', 'loginticket'));
// delete each ticket seperately in order to call the delete hooks
$tickets = loginticket_load_array('<all>', array(), TRUE);
if ($tickets) {
loginticket_delete($tickets);
}
}
?>
The call to
drupal_uninstall_schemadrops the table, then the call tologinticket_load_arrayreads from the table. Since we're not able to read from a table that's already dropped, I've reordered it to:<?php
function loginticket_uninstall() {
include_once(drupal_get_filename('module', 'loginticket'));
// delete each ticket seperately in order to call the delete hooks
$tickets = loginticket_load_array('<all>', array(), TRUE);
if ($tickets) {
loginticket_delete($tickets);
}
// Remove tables.
drupal_uninstall_schema('loginticket');
}
?>
so that the table
{loginticket}is still there when I read from it.#6
Another item I noticed and we've been discussing about
loginticket_uninstallis that invokingloginticket_deletemay not actually do anything. I understand why it's there—so thathook_loginticketcan be called—but at this point, I don't know that any module implementing the hook will actually be active. Wouldn't modules that implement the hook have a dependency onloginticket?I'm assuming that they would, which means they'd need to be disabled before
loginticketcould be. Sinceloginticketwould need to be disabled before uninstalling, there wouldn't be any active modules implementing the hook. I think the code can be further simplified to:<?phpfunction loginticket_uninstall() {
// Remove tables.
drupal_uninstall_schema('loginticket');
}
?>
#7
I noted an issue that applies to both 5 and 6 in that duplicate tickets can exist for the same user and purpose. I've put patches for both 5 and 6 on #436694: Allows multiple valid tickets per (users, purpose) pair.
#8
You know what folks, I really shouldn't slow down Login Ticket development with inactive maintainership, thus blocking patches and all. Please get in contact with each other and determine whether one or both of you feel like you would make responsible maintainers, in which case I'll hand out commit access accordingly.
#9
Jakob,
I've sent a message to Ben directly. I'm definitely interested in taking over the module. I suspect to be doing a fair amount more work over the next two weeks.
Chuck
#10
i'm not interested in taking over this module yet
so it'll be fine to let Chuck takes over as the maintainer
#11