Limit as textfield, instead of select list
comrax - June 3, 2009 - 10:14
| Project: | Invite |
| Version: | 6.x-2.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
The current implementation suggests predefined (and not editable through the Web) values for "Invitation limit" for a role. The page is http://www.example.com/admin/user/invite/settings
This patch will make the select box as a regular input text field, and allow you to enter any number you like. Proper description has been given also to insert a value that indicates "unlimited" invitations.
I hope to see this being part of new releases.
| Attachment | Size |
|---|---|
| invite_admin.patch | 1.04 KB |
#1
#377858: limit as textfield, instead of select list, Drupal 5 is a request for a backport of this. #196250: Invitation limit should not be an input field raises an issue that needs consideration before this can be marked RTBC. The patch is clean and works.
#2
Rerolling for dev branch. Still needs work due to issues raised in #196250: Invitation limit should not be an input field
#3
#4
#5
This version of the patch addresses the issue raised in #196250: Invitation limit should not be an input field by validating the user input values for role limits. It needs review and some testing.
#6
user_roles(0) looks scary. Why?
#7
It is not using
user_roles(0)to set any values, just to find keys of values in the form submission ($form_state['values']). I copied this iteration technique from:<?php
function invite_settings() {
$roles = user_roles(0, 'send invitations');
// ...
foreach ($roles as $role) {
$role_no_space = str_replace(' ', '_', $role);
$form['role'][$role_no_space] = array(
'#type' => 'fieldset',
'#title' => t('@role settings', array('@role' => drupal_ucfirst($role))),
'#collapsible' => TRUE,
'#collapsed' => TRUE,
);
// ...
}
// ...
}
?>
There are 5 other places in
invite.moduleandinvite.installthat already useuser_roles(0)in this way (and one that usesuser_roles(1)).Ideally they would use booleans
FALSEandTRUEinstead of integers, but that is a separate issue.Also, in this case, passing any different parameters such as
user_roles(1)would be an error, since users invited by anonymous users would not gain anonymous users' target role. Though implementing invite.module in this way would probably be an error of it's own (on the part of the configurator)!#8
Are you going to integrate this into 2.x-DEV?