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

...

...

* 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-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-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/

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/

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

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

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? :)

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

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!