May 2008 - Development - lists.drupal.org

Re: [development] User Status [WAS: User last access]
by David Timothy Strauss 04 May '08

04 May '08

I couldn't care less about the SQL92 standard (or any other SQL standard). What I care about is: * What we do is space efficient on MySQL * What we do is fast on MySQL * What we do works on other databases SQL92 doesn't answer any of those questions for me. Consequently, I have a few goals if we implement status bits for user accounts: * Not having one byte per bit * Not having O(n) searches for common bit-status user queries, if we have such queries * Ability to run on other databases, without significant regard to performance or space efficiency "Make the common case fast." <http://en.wikipedia.org/wiki/Amdahl%27s_law> ----- "Ivan Sergio Borgonovo" <mail(a)webthatworks.it> wrote: > On Sat, 3 May 2008 19:12:46 +0000 > "David Strauss" <david(a)fourkitchens.com> wrote: > > > But they probably support another bit-based format. > > The smallest thing you can find in SQL92 I think is boolean. > As said most DB support bit packing and some have aggregate functions > over boolean fields. > > char doesn't look as a good choice because on UTF8 may have some > overhead, it is ordered according to locale and in need it misses > interesting aggregate functions. > I don't know SQL standards and enough implementations to know if you > can avoid both problems in most DB. > Some DB let you define collation and encoding on a field base... some > don't even let you define the encoding/collation on a table base. > > The smallest SQL92 int is 2 bytes (smallint) someone may think it is > too large but it is very well handled by modern CPU and is not > affected by locale nor encoding... if you've more statuses... > > -- > Ivan Sergio Borgonovo > http://www.webthatworks.it

3 3

Re: [development] User Status [WAS: User last access]
by David Timothy Strauss 04 May '08

04 May '08

A bitmask isn't a column type; it's an operation to perform on a column to extract a bit. Bitmasking is handled by functions, and MySQL can't index the results of functions. That's why I say MySQL can't index bitmasks. You can put an index on the bitfield/int column, but it's useless for the majority of lookups.* *The index could function for conjunctive (AND) conditions beginning with the leftmost bit and not skipping any bits, but the query would have to be carefully constructed. ----- "Earnie Boyd" <earnie(a)users.sourceforge.net> wrote: > > -----Original Message----- > > From: Earnie Boyd <earnie(a)users.sourceforge.net> > > > > Date: Sat, 03 May 2008 09:59:43 > > To:development@drupal.org > > Subject: Re: [development] User Status [WAS: User last access] > > > > > > Quoting Larry Garfield <larry(a)garfieldtech.com>: > > > >> > >> A) Make status have a lot of different states with int/consts. > >> B) Make status a bitmask field (compact but harder to query). > >> C) Break status out into a series of is_foo fields (possibly a lot > of > >> needless data). > >> > > > > I like option B for this. > > > > Quoting David Strauss <david(a)fourkitchens.com>: > > > Remember that MySQL cannot truly index bitmasks. Consider a series > of > > CHAR(0) columns, which would take the same space but be indexable. > > > > I was thinking more of an integer field used as a bitmask. > > Earnie -- http://for-my-kids.com/ > -- http://give-me-an-offer.com/

1 0

Re: [development] User last access
by Hans Salvisberg 04 May '08

04 May '08

Michelle Cox wrote: > I've had so many complaints with advanced profile > because accounts where the user never logged in are only accessible to > admins. Which is a pain because they show up in the user list and then > people get a 403 when they try to visit the profile. Newly created users should not show up in publicly visible user lists until they've actually accessed the site. I think that's how it used to work before the patch. Hans

2 1

User last access
by Earnie Boyd 04 May '08

04 May '08

In testing my changes for the advuser module (D-5) I notice that if I as administrator edit a user, then the Last Access column changes from Never to just a few seconds ago for that user. How important would a patch to resolve this be? I'm willing to chase it if there is enough interest. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

9 17

Journal: Track your changes.
by Daniel F. Kudwien 03 May '08

03 May '08

Hi friends, Journal module will be enhanced to allow developers to manage a list of hacks and patches that have been applied to a Drupal site. I'm posting this announcement to devel list, because I guess that many devs are concurrently working on multiple projects, and have created and/or applied various patches to these sites. The goal is to track all customizations, so there is finally an answer to the question whether Drupal core and contributed modules can be updated easily when a new version is released. d.o. issue: http://drupal.org/node/254303 To make this feature rock, I could imagine a project_issue and update(_status) module integration: 1) project_issue: Periodically query d.o with a list of issue numbers and update their status in Journal's patch list. 2) update(_status): Add a warning to a module's entry, if there's a patch recorded in Journal that is not of status 'fixed'. Thus, I'd like to specifically ask the maintainers of project_issue and update(_status), whether these features would be supported by them. Daniel

4 3

Re: [development] User last access
by Hans Salvisberg 03 May '08

03 May '08

Neil Drumm wrote: > When admins do > things, stuff should happen, those users need to show up. I don't think so. I run some community websites and we create accounts for community members (which creates invitation emails in the process). Last access must remain Never until there has been an access, and the accounts must not show up in public view (e.g. "Who's New") until they have accepted the invitation, because they might choose not to join the website at all. > The way we store this is by overriding the access time. Users creating > their account get a time of 0, which means the account registration is > not finished and the user page does not go live. Admins creating > accounts get a timestamp. The account registration of admin-created accounts is NOT finished until the user has logged in for the first time. We might even argue that it's not finished until the user has successfully changed their password. Most users succeed in clicking the link (if they want to), but a sizable portion fail at changing their password and need additional hand-holding. > A couple options: > * Make admin-created users get a access time bump, but not admin-edited Please, no. Mis-using the access time for something other than access is an ugly hack. I can see that your intended behavior could be useful at times, but it should be an option at best, off by default. Typically, such functionality is delegated to a contrib module... > * Remove the column overriding and make an is_active column or > somesuch. Bonus points for merging with the status column. Yes, that would be a good solution. Hans

1 0

Re: [development] User last access
by Hans Salvisberg 02 May '08

02 May '08

Earnie Indeed, this is an incredible bug. For example if you have a spammer and you block him, then you'll trash "last access" — it'll show the time when you blocked him instead of when he last accessed... Or when an administrator creates a user, the user's "last access" is immediately set. There's no reasonable way anymore to list those users who have never accessed the site. "Never" is immediately trashed, as you've found out. There are people who think it should work that way for dubious reasons, who have managed to introduce this misbehavior into D5 and D6, and they won't even acknowledge that it's a bug! see http://drupal.org/node/202909 http://drupal.org/node/171117 I'd be extremely grateful, if you managed to get this fixed!!! Hans Earnie Boyd wrote: > In testing my changes for the advuser module (D-5) I notice that if I > as administrator edit a user, then the Last Access column changes from > Never to just a few seconds ago for that user. How important would a > patch to resolve this be? I'm willing to chase it if there is enough > interest.

2 1

How Trellon gave back to Drupal (April 2007)
by Morbus Iff 02 May '08

02 May '08

http://www.trellon.com/ As a well-known Drupal shop, Trellon continually strives to contribute back to the Drupal community in any way it can. Sometimes, we're just too busy, other times, we're just plain ol' lazy and, more often than not, Morbus is complaining about quality or apoptosis or whatever. By keeping track of what we give back, however, we hope to more clearly see how much we are, or aren't, helping Drupal help ourselves. This month saw the release of two modules: http://drupal.org/project/teleport "This module is intended for administrators who have to jump around to specific pages while managing Drupal sites. It's a hotkey- activated launcher utility inspired by Quicksilver. A configurable hotkey (Ctrl-T by default) brings up the dialog. Type in any part of the title or path of the page and an autocompleted list of possibilities will pop up. Unlike many other dynamic search modules, Teleport searches titles and paths of system pages as well as node titles." http://drupal.org/project/evoca_ms "EMS (Evoca Media Services) allows web sites to add user-generated audio content using any telephone, a Flash Recorder, and uploading audio files and then delivers that audio content using customizable Flash Players or downloads, which are delivered back through a Web Service." We also did a small project with the webform.module, which allowed us to submit a healthy number of patches. A good amount were committed: Typos and other random comments http://drupal.org/node/238958 pagebreak gets saved as submitted_data http://drupal.org/node/239336 Users editing webform link doesn't exist http://drupal.org/node/219181 Store saved sid in form values for additional processing http://drupal.org/node/240455 Increase webform_component.name to 255 http://drupal.org/node/241319 Change description from textfield and remove limit http://drupal.org/node/241577 And a few are still under discussion, testing, and rework: form is still displayed even if max number exceeded http://drupal.org/node/239751 No permission for 'take webform' http://drupal.org/node/239343 Limit to submissions, strange default behaviour http://drupal.org/node/240449 Patch adding save draft feature http://drupal.org/node/226907 Allow back and next buttons to customised http://drupal.org/node/241523 webforms filter system for descriptions doesn't work with tinymce correctly http://drupal.org/node/243322 incorrect file extensions are displayed by file upload http://drupal.org/node/247131 Until next month, superfriends, Develop Drupal Daringly! http://www.trellon.com/ -- Morbus Iff ( take your rosaries off my ovaries ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus

4 6

RFC: drupal as a moving target
by Ivan Sergio Borgonovo 02 May '08

02 May '08

There are things that should be considered obsolete on the drupal handbook as the OOP policy and the security policy... and a "myth" that the community seems to be proud of: Drupal is a moving target and we aren't scared to break the API. Drupal is now a mature project and people start to rely on it for projects that have a longer life span than the release process of Drupal. Still there are parts of Drupal that aren't still mature enough to provide a "stable" API and freezing them there would hurt the project. I did a rough estimate (sed -e '/5\.[xX]/' | wc) on http://ftp.drupal.org/files/projects/ this doesn't take into account multiple versions, features that moved to core, etc... But the result is indicative: D5: 372 D6: 76 I did read: http://drupal.org/handbook/version-info and http://drupal.org/node/65922 In the face of the current status of Drupal project and on the above data isn't it the time to adjust the above policy a bit? I think that many core dev grew up with Drupal and now have to babysit projects based on Drupal that have a longer lifespan than a Drupal release cycle, so it shouldn't be a problem to actually reflect this in a public policy that will help others to make their plans too. Weren't we saying that Drupal value resides in being a framework rather than a finished product? What is the value of a moving framework for devs? What about the development process and focusing on improving the aspects that will contribute in offering a mature *stable* API... or does this sound as a blasphemy? I saw that the later document got an important revision (August 2007) when life-cycle moved from 6-12 months to 12-24. -- Ivan Sergio Borgonovo http://www.webthatworks.it

29 58