Hello from another developer/Want to add some features
Hi everyone, My maiden post to the list so please be kind. ;) First of all, congrats to you all for the great product so far. Big kudos for implementing a proper form api as well! Would love to chat to someone that designed/implemented it to get some idea of the design. I'll be happy to draw an image to represent it if I do get that chat. I've been maintaining a couple drupal run sites for two years and am now tasked with updating stuff from 4.4 to 4.7. Following is the list of things i've built into the 4.4 core that i'd like to port into 4.7. As you can imagine, security holes are very hard to close if you don't keep the core pure. Once a feature i'm proposing to implement has been accepted for inclusion in the core, i'll be happy to submit the patches. If these things are in the core already, a pointer towards some examples of it's use in modules would be much appreciated. Any questions about any of the additions i'm happy to answer. * Support for form fields to be rendered as either editable or view only. This has implications when one of the view-only fields is a key field. Additionally, it would be nice to discuss any ideas you've had implementing a system-wide user-based module field permission mechanism. There might be something in place already so forgive me if i've not rtfm. * Support for datetime and time fields. * Disabling changes to usernames and passwords of administrative users by users having administer users permission. Is anyone currently addressing the date field support in drupal? It could do with some localisation features as well, which i'm happy to add in. How does all this grab you lot? Cheers, -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/
* Support for form fields to be rendered as either editable or view only.
#attributes => array('readonly' => 'readonly') . Or you can intrdouce a #type => view_only which would expand any element to a hidden and a markup. None of these require any core change.
* Support for datetime and time fields.
I thought we have #type => date now.
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
This is not my expertise. Forms are :) Regards NK
Op zaterdag 28 januari 2006 12:15, schreef Karoly Negyesi:
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
That would be a great one; It will solve the issue where: * any user with administer user perms can edit superuser (change pw) * then log in as superuser. * p0wn3 your site. ATM the only way around this is to simply not give anyone admin users perms; Looking forward to a patch, Bèr
On Saturday 28 January 2006 05:59, Bèr Kessels wrote:
Op zaterdag 28 januari 2006 12:15, schreef Karoly Negyesi:
That would be a great one; It will solve the issue where: * any user with administer user perms can edit superuser (change pw) * then log in as superuser. * p0wn3 your site.
ATM the only way around this is to simply not give anyone admin users perms;
Looking forward to a patch,
Bèr
There is one, but Dries rejected it: http://drupal.org/node/39636 It's a trivially small patch that I'd like to see go in. Even if it doesn't, it's easy to apply after the fact. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 28 Jan 2006, at 1:15 PM, Karoly Negyesi wrote:
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
This is not my expertise. Forms are :)
But it can be done using the forms api, and attaching additional validation to the forms. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
I smell hiearchical roles here. Some user ought to be able to change other users psswords... including admins... I guess at least.
On 28 Jan 2006, at 2:46 PM, Karoly Negyesi wrote:
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
I smell hiearchical roles here. Some user ought to be able to change other users psswords... including admins... I guess at least. i'm going to get roasted for this. ... ..
but taxonomy. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 28-Jan-06 13:46, Karoly Negyesi wrote:
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
I smell hiearchical roles here. Some user ought to be able to change other users psswords... including admins... I guess at least.
Yes indeed some user must be able to change these attributes of _all_ users. Here is how I am planning on doing this to KISS and avoid using taxonomy or hierarchical roles in the short term. Was planning to add a setting to the user setting page allowing the selection of a role (or none) where users are given the ability to modify usernames and passwords of every user in the system. None: everyone with administer users permission can edit all users <role>: users with selected role are given the ability to edit all users. users with administer users permission can not change username and password of those with the selected role. Any troubles with the above? -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/
On 28 Jan 2006, at 3:21 PM, Sammy Spets wrote:
On 28-Jan-06 13:46, Karoly Negyesi wrote:
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
I smell hiearchical roles here. Some user ought to be able to change other users psswords... including admins... I guess at least.
Yes indeed some user must be able to change these attributes of _all_ users. Here is how I am planning on doing this to KISS and avoid using taxonomy or hierarchical roles in the short term.
Was planning to add a setting to the user setting page allowing the selection of a role (or none) where users are given the ability to modify usernames and passwords of every user in the system.
None: everyone with administer users permission can edit all users <role>: users with selected role are given the ability to edit all users. users with administer users permission can not change username and password of those with the selected role. You can do a function like :
function mymodule_form_alter($form_id, &$form) { if ($form_id == 'user_edit') { // might have to double check the form id if (/* check that the user is not allowed to edit things*/) { $form['name']['#type'] = 'value'; // whatever the password requires. might have to make it hidden } } return $form; } This will remove those fields from the form if the user isn't allowed to edit them. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 28-Jan-06 15:50, Adrian Rossouw wrote:
function mymodule_form_alter($form_id, &$form) {
if ($form_id == 'user_edit') { // might have to double check the form id if (/* check that the user is not allowed to edit things*/) { $form['name']['#type'] = 'value'; // whatever the password requires. might have to make it hidden } }
return $form; }
This will remove those fields from the form if the user isn't allowed to edit them.
Yep. Thanks for the suggestion Adrian. I'll implement it this way to leave the hierarchical roles business till later in the game. -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/
Karoly Negyesi wrote:
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
I smell hiearchical roles here. Some user ought to be able to change other users psswords... including admins... I guess at least.
I'm not sure what you mean by "hierarchical roles". But I'm about to fix a problem on a site similar to this, and considered something that sounds like "hierarchical roles". My problem is that I want some subset of users to be able to administer some subset of users, but not all users. The "administer users" privilege is too general; if you can administer one, you can administer all. And you can elevate your own level of privilege. A simple solution to this would have "levels" of roles -- a simple weight number. The rule is: you cannot assign a role to another user that has a lower weight than the most privileged role that is assigned to you. This would allow a simple way to partition the administration of users into sub-administrators, and is easier to create admin UI for than a hierarchy (take a look at og_hierarchy if you want to see how nasty that kind of UI can get). This is a simple work around a serious problem (IMHO) with the Drupal user model: it's currently possible for any user with "administer users" privileges to effectively elevate his/her privilege level. Am I missing something, and there's some other way to prevents this? Rob Thorne Torenware Networks
On 28-Jan-06 15:29, Rob Thorne wrote:
A simple solution to this would have "levels" of roles -- a simple weight number. The rule is: you cannot assign a role to another user that has a lower weight than the most privileged role that is assigned to you. This would allow a simple way to partition the administration of users into sub-administrators, and is easier to create admin UI for than a hierarchy (take a look at og_hierarchy if you want to see how nasty that kind of UI can get).
This is a simple work around a serious problem (IMHO) with the Drupal user model: it's currently possible for any user with "administer users" privileges to effectively elevate his/her privilege level.
Am I missing something, and there's some other way to prevents this?
This is definitely a simple solution to my problem. Overall however, I think the model you've suggested will have to look out for the cases presented in multi-site setups as well as Drupal network. -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/
On 28-Jan-06 12:15, Karoly Negyesi wrote:
* Support for form fields to be rendered as either editable or view only.
#attributes => array('readonly' => 'readonly') . Or you can intrdouce a #type => view_only which would expand any element to a hidden and a markup. None of these require any core change.
Thanks for this info. I'll play around with that. :)
* Support for datetime and time fields.
I thought we have #type => date now.
AFAIK drupal doesn't have a time field with two dropdowns and a datetime where the date and time fields are combined into one to fully utilize the timestamp type of a DB.
* Disabling changes to usernames and passwords of administrative users by users having administer users permission.
-- Sammy Spets Synerger Pty Ltd http://www.synerger.com/
Sammy Spets wrote:
AFAIK drupal doesn't have a time field with two dropdowns and a datetime where the date and time fields are combined into one to fully utilize the timestamp type of a DB.
$form['effective_date'] = array( '#type' => 'date', '#title' => t('Effective date'), '#default_value' => $node->effective_date ? array('day' => $node->effective_date[2], 'month' => $node->effective_date[1], 'year' => $node->effective_date[0]) : array('day' => format_date(time(), 'custom', 'j'), 'month' => format_date(time(), 'custom', 'n'), 'year' => format_date(time(), 'custom', 'Y')), '#required' => FALSE);
His question was about the lack of a field with type "time", and "date time" in FAPI. The forms allow a year, month, date, but not an hour, minute, second field. On 1/28/06, Robert Douglass <rob@robshouse.net> wrote:
Sammy Spets wrote:
AFAIK drupal doesn't have a time field with two dropdowns and a datetime where the date and time fields are combined into one to fully utilize the timestamp type of a DB.
$form['effective_date'] = array( '#type' => 'date', '#title' => t('Effective date'), '#default_value' => $node->effective_date ? array('day' => $node->effective_date[2], 'month' => $node->effective_date[1], 'year' => $node->effective_date[0]) : array('day' => format_date(time(), 'custom', 'j'), 'month' => format_date(time(), 'custom', 'n'), 'year' => format_date(time(), 'custom', 'Y')), '#required' => FALSE);
On Sun, 29 Jan 2006 03:10:56 +0100, Khalid B <kb@2bits.com> wrote:
His question was about the lack of a field with type "time", and "date time" in FAPI.
Form API has no field types. OK, theming some elements got in, but otherwise, Adrian was pretty agitated about keeping it as typeless as it's possible. All in all, if you miss that type or any type you are free to code and release it. The very reason for form API is extensibility. Regards NK
On 29 Jan 2006, at 4:29 AM, Karoly Negyesi wrote:
Form API has no field types. OK, theming some elements got in, but otherwise, Adrian was pretty agitated about keeping it as typeless as it's possible.
It doesn't have any field types. yet. That's one of the first things we need to rectify when 4.8 opens up. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
On 29 Jan 2006, at 4:29 AM, Karoly Negyesi wrote:
Form API has no field types. OK, theming some elements got in, but otherwise, Adrian was pretty agitated about keeping it as typeless as it's possible.
It doesn't have any field types. yet.
That's one of the first things we need to rectify when 4.8 opens up.
This statement really makes me think that either you're going to benefit greatly from the CCK work, or you're going to make the CCK work completely redundant. It would be great if the "visionaries" out there could write up their own 4.8 roadmaps (ponies and ferrets included) before we see each other next week. Robert
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 29 Jan 2006, at 3:36 PM, Robert Douglass wrote:
This statement really makes me think that either you're going to benefit greatly from the CCK work, or you're going to make the CCK work completely redundant. Yeah. it's definitely going to embrace the CCK work and get some of it into core. Essentially the input/output/validation layer, but not specifically focusing on the data layer (ie: the actual saving and reading from the database).
The part that makes the forms api so complex right now is the fact that we are representing two different data structures, within a single multi-dimensional array. 1 : field definition, which is essentially what we are validating against, and populating from the request.. 2 : structure, which is essentially fieldsets and tables and things. The single most complex function in forms api is _form_builder() which essentially recursively steps through the form array, and creates a field definition array from the element definitions. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
We need all of the layers. The CCK layer is about three things: - data to and from the database - content type definitions - configuring content types and field types through the web (and, I would add, field attributes to be interpreted by Forms API) - loose coupling between field types, content types, and semantic functionality The Forms API layer is about the mechanics of translating internal field representations into HTML and dealing with standard browser-based validation and submission. I would add to this a third layer, the views layer, which has to do with the structure of the output. What part of the content type do we want to view, with which criteria? At 2:36 PM +0100 1/29/06, Robert Douglass wrote:
roadmaps (ponies and ferrets included) before we see each other next week.
Wow, that's coming right up, isn't it? :)
I require the following field types in my modules and am in the middle of coding them. The types I plan to add to core are: type MySQLtype PgSQLtype ----------------------------------------- date date date datetime timestamp timestamp time time time Some problems i've found while upgrading my modules. These i've fixed (or am currently fixing) and am willing to submit a patch. * FormAPI doesn't set error class of any select elements. * FormAPI doesn't validate dates (i.e 30/Feb/2000 is valid) * FormAPI doesn't automatically set the default value of a date field to the value from the database. This is annoying because then you have to put repetitive code into _every_ module using date type fields. * FormAPI doesn't automatically bring the date back to ISO 8601 format prior to submit code. This is annoying because then you have to put repetitive code into _every_ module using date type fields. Which types go into core and what to leave out? IMHO core should support all oftused DBMS types. Especially date/time types. I also believe the types i've listed above are the most fundamental of date/time types and others, such as timestamp with timezone, can be added in later. I can see one reason why these should not be added to core. It will make FormAPI changes (and CCK most likely) more time consuming to implement and test. Those wanting to use dates in 4.7, and ensure modules will need minimal changes after that, will rejoice for this much needed addition. If FormAPI maintainers don't want to accept an extra 15 or so lines of code i'll have to go beat 'em up with a date field. ;) C'mon! 15 lines of code aren't that hard to maintain! What's the point of having an API if it doesn't do everything for you automatically? Does core want my patch or what?! :) Actually, while i'm on the soapbox... I wanted to propose another element for the FormAPI, '#decess' or in other words, the opposite of '#process'. First of all, it allows the API to de-process a field. E.g put the three fields (month, day, year) in $form_values back together into an ISO 8601 date string so modules don't have to do it. Additionally, it should allow modules to override the API's decess function to give them flexibility on format of the date string. Whatcha reckon Adrian?! *ducks* -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/ On 29-Jan-06 17:23, Adrian Rossouw wrote:
On 29 Jan 2006, at 3:36 PM, Robert Douglass wrote:
This statement really makes me think that either you're going to benefit greatly from the CCK work, or you're going to make the CCK work completely redundant. Yeah. it's definitely going to embrace the CCK work and get some of it into core. Essentially the input/output/validation layer, but not specifically focusing on the data layer (ie: the actual saving and reading from the database).
The part that makes the forms api so complex right now is the fact that we are representing two different data structures, within a single multi-dimensional array.
1 : field definition, which is essentially what we are validating against, and populating from the request.. 2 : structure, which is essentially fieldsets and tables and things.
The single most complex function in forms api is _form_builder() which essentially recursively steps through the form array, and creates a field definition array from the element definitions.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 31 Jan 2006, at 8:20 AM, Sammy Spets wrote:
I require the following field types in my modules and am in the middle of coding them. The types I plan to add to core are:
type MySQLtype PgSQLtype ----------------------------------------- date date date datetime timestamp timestamp time time time
Some problems i've found while upgrading my modules. These i've fixed (or am currently fixing) and am willing to submit a patch.
Drupal core uses integers for time fields. This is all that was coded for.
* FormAPI doesn't set error class of any select elements. That can be construed as a bug, and should be fairly simple to fix.
* FormAPI doesn't validate dates (i.e 30/Feb/2000 is valid) Then write a validation function which does validate dates and make it the default on the date field (in system_elements);
* FormAPI doesn't automatically set the default value of a date field to the value from the database. This is annoying because then you have to put repetitive code into _every_ module using date type fields. Because we use integers in core. I know that the date/time field has changed since last I worked on it though, as I think some of alex' code made it in.
* FormAPI doesn't automatically bring the date back to ISO 8601 format prior to submit code. This is annoying because then you have to put repetitive code into _every_ module using date type fields. You could create an #after_build that did this for you, but once again drupal core uses integers.
Which types go into core and what to leave out? IMHO core should support all oftused DBMS types. Especially date/time types. I also believe the types i've listed above are the most fundamental of date/time types and others, such as timestamp with timezone, can be added in later.
Because Drupal core doesn't use date/time types, the forms api wasn't designed to use them. I personally like using date/time types, and I think there's good enough reason that we should actually move to date/time fields for all timestamps in Drupal, instead of having two different mechanisms. I know that postgres can be ... peculiar when it comes to date time fields though, and converting to unix timestamps is very different between them (unix_timestamp(datefield) vs extract (epoch from datefield), so cross platform sql is also not as simple as it might seem.
I can see one reason why these should not be added to core. It will make FormAPI changes (and CCK most likely) more time consuming to implement and test. Those wanting to use dates in 4.7, and ensure modules will need minimal changes after that, will rejoice for this much needed addition. If FormAPI maintainers don't want to accept an extra 15 or so lines of code i'll have to go beat 'em up with a date field. ;) C'mon! 15 lines of code aren't that hard to maintain! You can very easily maintain this in contrib without needing to put it into core. and at this stage, I think it's a bit too late to try and get it into core.
Keep in mind. the forms api is about generating forms (ie: output), it's not about specifying field types. It allows completely optional validation of these inputs, but it has no actual knowledge of 'this is an integer, or this is a date/time value" That's one of the first things that's going to change when 4.8 opens, at which point implementing integer, float and date/time fields is going to be one of our primary concerns.
What's the point of having an API if it doesn't do everything for you automatically? Does core want my patch or what?! :)
Ummm. Because we had to choose an implementable chunk of the functionality, given the time constraints we had (and yet still managed to completely overrun our schedule), it just wasn't possible to implement the second phase of the forms API (also arguably one of the first phases of CCK too). Upload your patch and let the code speak for itself.
Actually, while i'm on the soapbox... I wanted to propose another element for the FormAPI, '#decess' or in other words, the opposite of '#process'. First of all, it allows the API to de-process a field. E.g put the three fields (month, day, year) in $form_values back together into an ISO 8601 date string so modules don't have to do it. Additionally, it should allow modules to override the API's decess function to give them flexibility on format of the date string.
You can use #after_build for that. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Thanks for the input again Adrian. I've hit a potential policy snag and thought it wise to discuss before continuing. I'd like to hear from anyone with 2 cents. :) At present, readonly form fields are limited to only <input> tags. So our poor <select> doesn't have the ability to join its elite counterparts. Why it is the readonly attribute is being used in the input tags rather than just showing the data without using a form element tag? My reasoning is this: if a form element is used, including hidden, it opens up that form to abuse through edited forms. In addition, would it not be better to have a uniform readonly element generated? I realise this would then prevent those fields from being sent back to the server. However, in the end it is more secure. Module changes required are relatively trivial since they have ready access to values currently in the database. Let 'em rip! -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/
Hi, The hook_form_alter() is an extremely powerful hook. If you only want the fields on this page to not be true form elements then what you can do is just change most or all the '#type' attributes to markup and just have the data being displayed. You may need to alter some of the other fields but this shouldn't be too hard. You could also make readonly equivalents of each of the elements so that you can theme them to look like what they are meant to look like. Gordon. On Wed, 2006-02-01 at 14:46 +1100, Sammy Spets wrote:
Thanks for the input again Adrian. I've hit a potential policy snag and thought it wise to discuss before continuing. I'd like to hear from anyone with 2 cents. :)
At present, readonly form fields are limited to only <input> tags. So our poor <select> doesn't have the ability to join its elite counterparts.
Why it is the readonly attribute is being used in the input tags rather than just showing the data without using a form element tag?
My reasoning is this: if a form element is used, including hidden, it opens up that form to abuse through edited forms. In addition, would it not be better to have a uniform readonly element generated?
I realise this would then prevent those fields from being sent back to the server. However, in the end it is more secure. Module changes required are relatively trivial since they have ready access to values currently in the database.
Let 'em rip!
participants (10)
-
Adrian Rossouw -
Bèr Kessels -
Gordon Heydon -
John VanDyk -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Rob Thorne -
Robert Douglass -
Sammy Spets