refactor administrative interface for keys

No, This was just the image of the main interface, but I also suggested to mix both configuration forms: key and roles forms into a single form to create and edit registration keys (as it's done in many drupal modules, e.g. 'user edit form' = 'user add form').

This way you will not have a half configured key anymore, because you may create a key setting the roles in the same form. Does this makes sense?

PD: edited.. s/module/form/

I guess I introduced an error when I talked about the Role Key roles form. I was talking about merge the two forms available for each key. I didn't mean the user/rolekey/roles 'view' form. In fact, I would say we should leave this as is, as it's in drupal permissions form. But about the "key" creation and edition, the ability to create a key using a single form would help the usability, and if this form is used for add/edit key, it will clarify the code and flows of the module.

Also, I would suggest to remove the anonymous and authenticated roles as they are managed by core, and there's no option to configure them in this module.

mm For me this doesn't make sense for now to have deltas. Default roles adminstration page has no this option and this part of rolekey would have probably even less entries than default roles view.

About the 'interest' point in this administration view (for me):
- It makes no sense to have the "Add" button with half of the options for a new key. I would preffer a new Tab (as in admin/build/block or admin/user/user/) to add a new registration key with the complete form. It gets more drupalished
- From the administration viewpoint, this would me my main control panel for the keys in use, and would like to enable/disable or change keyword in this page, so foreach row (each key) the editable keyword would be the key.

This form currently does support a few of keys, have you thought about having hundreds of them? personalized or sms keys could take days to setup (I'm not talking about importing, but managing), so I'm thinking in a more flexible view with multiple selection included: to select from checkboxes in the left of the rows and remove 5 or 6 keys at once, or to remove a role from all of them, but this is just a "would like", not a "do like" as it's not a mature idea at all. Maybe it's time to get Daniel in this conversation and talk about an API for creating and managing keys as this UI evolves..

Good work splitting the module in several files. I didn't understand why were they commited to HEAD but it's fine for me (for now).

Just a little bit of literature:

I did pass the tests and everything is still being shown as it should. The first set of tests just checks visibility, permissions and errors in all the pages of the module. I would like to improve a little bit before commiting, just because of this strage issue status..

#243532: Catch notices, warnings, errors and fatal errors from the tested side support to catch warnings in simpletest, closed as of Dec 2008
#442436: Full backport of Drupal 7 SimpleTest closed to weeks ago, but doesn't include the assertNoDrupalErros, so I've to code the previous issue by myself to test if the module introduces any warning

The branch shows the developmental snapshot, so I thought that I'd let you have a look before adding these to the dev version

OK, next time a diff patch will be enough. I would like to have HEAD free for the merge of other operations or main change.. But we can leave head for d7 branch and create a 6.-2 branch with mayor changes, for example, all this stuff of the admin interface. For now, as I said, it's ok using head as you did.

Having the main interface grabbed form role module is a good start for what it must do, now we can focus on what we would like to do, and for this we need a flexible approach. I've been thinking about this just few minutes (too much for me :) ) and I've arrived to this conclusion: having "Add" as the first tab would help other helpers to include their administrative interface. See the attached image.

I've just considered import (so there's a need for an API to insert keys) and also tracking (so there's a need for an API to control when a key is used). Also other key properties (time limit, count limit and so) could be included. Now we just have to look for something close to this idea already existing in drupal.. (I'm not aware of anything right now, just userpoints could be the closest thing..), but can't be used for that.

The editable keys (to current implementation) for now it's an option, if we end considering this feature we will finish creating the issue for that.

Working on it..

It's not yet finished, and applied over the 'splited' version of the module, so change to 6-x-dev is a mayor change and don't want to do for now. This is not a simple change in the admin interface, it also affects code readness and clarification, and also prepares the code to accept other flows. HEAD was commited for you to see, and currently there are two branches, 5 and 6, and both look the same. Having different 5 or 6 branches could lead to confusion.

I'm just using head as dev, to avoid breaking 6 branch, and I just focused on "Key administration" interface for now, preparing for other functionalities - features, while the rest of merging operations move. And yes, taking a look to the existing modules, there's no one managing keys - correction - with a well defined interface to manage keys - appart from what we are doing right now. It's not double job, neither lost job. It would be necessary in the end. don't you think?

For now it's ok for me. I'm currently busy in other things so I've been appart from d.o. for two weeks now, and hope no more than one remaining. I've got news about other modules I've to deal with also.

Let's settle this. Thanks Alan.