June 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Last access time reports the epoch instead of 'never'
by deekayen 15 Jun '05

15 Jun '05

Issue status update for http://drupal.org/node/24766 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: minor Assigned to: deekayen Reported by: puregin Updated by: deekayen Status: patch I could see how the timestamp might be negative if the DB record were a page you wanted to back-date, but here we're talking about a triggered action. I think it would make about as much sense for this to be negative as it would to see something in your Apache logs date back to 1834. Besides, if the timestamp could be less than 0, you're taking about a whole new issue of the validity of using epoch to store time instead of a date/timestamp, because then deekayen Previous comments: ------------------------------------------------------------------------ June 10, 2005 - 12:32 : puregin As site admin, I create a user. When I look at the user admin page immediately afterwards, the user shows up with a 'last access' time of '35 years 24 weeks ago'. Could we report 'Never' instead of the epoch, if the last access time is older than the user account? I seem to recall a similar report, but I couldn't find it after searching through the issues for user.module, and issues in general. Djun ------------------------------------------------------------------------ June 14, 2005 - 02:01 : deekayen Attachment: http://drupal.org/files/issues/wrong_last_access.png (6.13 KB) I verified this on WinXP/PHP5.1. Screenshot attached. ------------------------------------------------------------------------ June 14, 2005 - 02:22 : deekayen Attachment: http://drupal.org/files/issues/epochuser.patch (1.17 KB) Attached patch shows "never" instead of epoch on new users with 0 as last visited value in the DB ------------------------------------------------------------------------ June 15, 2005 - 00:16 : puregin The patch fixes the problem, thanks. Are there other places in Drupal where this kind of message might occur? Is it possible for the timestamp to be negative under any circumstances (if so, perhaps the test should be $account->access <= 0 rather than $account->access == 0) Regards, Djun

1 0

[drupal-devel] [feature] Profile field visiblity should vary by role
by fago 15 Jun '05

15 Jun '05

Issue status update for http://drupal.org/node/14149 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: ejort Reported by: sushi76 Updated by: fago Status: patch the profile node sounds good. i think it's also good to have the possibility to define profile fields for different roles only, so that every role has its own profile. i've done recently a site, where i needed very extended profiles - so i wrote a profile.module based on the drupal profile.module which does this and a lot of other customized stuff.. i also introduced profile-fields, which can be edited only by user with "administer users", as mentioned here. i think, you might run into same problem i did: i already mentioned this issue [1] i'm using this patch, i posted there, on this site. otherwise a user could just inject data, with the same name as admin-only-field, in the user-data field, which will be loaded in the user object by user_load(). further profile_load_profile won't overwrite the value.. [1] http://drupal.org/node/21515 fago Previous comments: ------------------------------------------------------------------------ December 9, 2004 - 19:38 : sushi76 Currently there are only these three Options Private field, content only available to privileged users. (Admin users) Public field, content shown on profile page but not used on member list pages. (Everyone, but not in the member list) Public field, content shown on profile page and on member list pages. (Everyone, everywhere) It should be possible to set the visibilty of profile fields by user roles. ------------------------------------------------------------------------ March 6, 2005 - 21:40 : tulula I agree! If visibility is set by roles OR if the option is left up to the user to display their info at their discretion vs Admin at level of setting up profile fields. ------------------------------------------------------------------------ June 6, 2005 - 06:03 : ejort I agree that it should be possible to set visibility per role. There is profile data on my site that I want my organisation's committee members to see, but nobody else, there's information that I want only authenticated users to see, but not anonymous users etc. More than that, I think we should be able to set field editability by role also. There is data on my site that only certain people should be able to edit. If we get to this point then this would be a superset of the functionality discussed in the PROFILE_HIDDEN updates [2] thread, but would be much more flexible. [2] http://drupal.org/node/21219 ------------------------------------------------------------------------ June 10, 2005 - 09:07 : ejort Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.… (12.97 KB) Hi, Here's a patch which implements role based edit / access permissions for profile fields. It allows you to give permissions to each role (and for each field) to: * access a field (for all accounts) * access a field for your own account * edit a field for your account Users with permission 'administer users' can access / edit all fields, and users must have enough permission to edit/access a profile for these extra permissions to come into effect. I believe this allows for more flexibility than the existing profile.module method of PROFILE_PRIVATE and in HEAD PROFILE_HIDDEN. You can eg: * hide some fields from anonymous users, while allowing other roles to still view that info * have fields viewable by only the admin and user who owns the account (like PROFILE_PRIVATE * have fields viewable by some roles, but only editable by the admin * have fields hidden from all except the admin, and editable only by the admin * it will make you more attractive to the opposite sex etc. I'm developing this because I need it for one of my sites, hence, unfortunately this patch is against the 4.6 profile.module. If people think this is a valuable feature for HEAD I can roll a patch against that. Cheers, Eric ------------------------------------------------------------------------ June 10, 2005 - 10:13 : Bèr Kessels I am not too sure about this. A typical profile contains between five and 10 fields, but twenty fields is not unheard of. This patch will flood the permissions screen unnneccesary. I would opt for the hard way: An advanced profile module, or CRM module, or so. hat module could implemen,t all sorts of advanced levelled permissions. In order to maintain a high level of usability in core, we should try to minimize options and checkboxes. I know from flexinode, which adds similar dynamic permissions, that the interface for permissions is really not up to this big amount of permissions. I really think such things should not be in core. Buty that all said, it /is/ a handy feature :) ------------------------------------------------------------------------ June 10, 2005 - 10:53 : ejort Yes, unfortunately it can add a large number of permissions to the permissions page. I did consider trying to place the permission selections on each fields edit page instead (similar to the visibility settings), but as a certain eminent author recently wrote* [3]: "please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages " :-) I think that the PROFILE_PRIVATE and PROFILE_HIDDEN (and the PROFILE_PUBLIC_*) settings are currently doing just that, implementing an alternate permissions system which addresses a few use cases, but is ultimately not particularly flexible. Is there any chance that the permissions sections can benefit from some collapsible goodness to alleviate the flooding? I think it's a shame to reduce the systems flexibility because it may create 'too many' permissions settings, especially as it is generally a set once and forget proposition. Perhaps we should look at the underlying UI problem? *That would be Bér :-) [3] http://drupal.org/node/22565#comment-32248 ------------------------------------------------------------------------ June 10, 2005 - 14:27 : Bèr Kessels Ejort, I know i wrote that. However, this is a little bit different. am not saying you should make a new system for changing the apperance of profile fields. I am only saying that having per-profile-field permissions is: * way OTT for the big mayority of users * extremely cluttering for the permission page (which, essetially is a problem in that interface, not in your "feature") ------------------------------------------------------------------------ June 14, 2005 - 16:22 : ejort I don't agree that this is extremely off topic for most users. A large number of people using drupal in any business setting will likely find the extra flexibility invaluable (and the use cases popping up in discussions for regarding PROFILE_HIDDEN show that the current approach doesn't cover enough of the possibilities). I've worked on multiple jobs where I had to create contact lists and employee profiles where basic information was accessible to the public (name, work email, profile text), certain details (direct phone numbers) were only visible to internal company employees, other data (mobile phone numbers) were visible only to team leaders, other data (next of kin contact details) were only visible to an admin, and the user wasn't allowed to edit certain items (such as the public profile text). I've had similar needs come up across several jobs, but then again I wrote the patch so of course I needed it! :-) I also believe that the permissions page problem isn't too large an issue. The permissions are created in response to the admin creating profile fields (3 per field, 'access', 'access own', 'edit'), so the page has no extra permissions by default. This also isn't an interface that is accessed on a daily basis, and there is a good visual separation of the sections so it is easy to skim past the longer profile section if that's not what you're interested in. Of course, this is all just my opinion, and I'm a biased observer :-) ------------------------------------------------------------------------ June 14, 2005 - 16:37 : Bèr Kessels I know its a handy feature, that will be used in some cases. But then it should nbe in an advanced-profile.module. Not in core. ------------------------------------------------------------------------ June 14, 2005 - 17:12 : judah I would have to disagree with you ber on this one. I have posted some comments on the Hidden Profile update mentioned above. The permission system *should* be apart of core. These shouldn't be broken out into another advanced module. There *shouldn't* be a node_privacy_by_role. This is unheard of in other systems. I have worked on many other cms solutions and permissions is always a part of the design. Should we plaster them on every feature? No. But we should not so easily dismiss this issue. Node privacy by role and field privacy by role should be considered more closely as a core function rather than where it is now. IMHO. Having said that I do understand the need to break things or branch things too. So it is up to you designers to consider this. Assuming this patch gets approved I would suggest you make the role assignment options available on the profile edit page if it's not already. ------------------------------------------------------------------------ June 14, 2005 - 22:09 : killes(a)www.drop.org judah: Drupal has the benefit that we can use any node access scheme we like by using another module. @all: I think the best thing would eb to make profiles nodes and wait for cck for field based permissions. ------------------------------------------------------------------------ June 15, 2005 - 12:19 : Bèr Kessels I think an interim solution would be to: * make profiles nodes * use Flexinode if one wished for profiles . otherwise use a dediceated node for this * add per field permissions to flexinode. ------------------------------------------------------------------------ June 15, 2005 - 15:14 : Boris Mann I think that profile does indeed need to be re-vamped at some point, and making it a node is likely the right way to go -- then we can benefit from all the field-level work that is going on as we head towards CCK. This is a good interim patch, and should likely be applied to HEAD until someone comes up with the one true profile node -- following our motto to commit things a little earlier so that they can get some testing and use, rather than waiting forever. I know we have a need for it right now as well, and so will help keep this up to date. The one issue is the UI for permissions. It should probably be a separate screen, rather than access control. I would put it directly in the per-field edit screen (e.g. admin/setting/profile/edit/1) or be a permission tab (e.g. admin/setting/profile/permissions).

1 0

[drupal-devel] [feature] Profile field visiblity should vary by role
by Boris Mann 15 Jun '05

15 Jun '05

Issue status update for http://drupal.org/node/14149 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: ejort Reported by: sushi76 Updated by: Boris Mann Status: patch I think that profile does indeed need to be re-vamped at some point, and making it a node is likely the right way to go -- then we can benefit from all the field-level work that is going on as we head towards CCK. This is a good interim patch, and should likely be applied to HEAD until someone comes up with the one true profile node -- following our motto to commit things a little earlier so that they can get some testing and use, rather than waiting forever. I know we have a need for it right now as well, and so will help keep this up to date. The one issue is the UI for permissions. It should probably be a separate screen, rather than access control. I would put it directly in the per-field edit screen (e.g. admin/setting/profile/edit/1) or be a permission tab (e.g. admin/setting/profile/permissions). Boris Mann Previous comments: ------------------------------------------------------------------------ December 9, 2004 - 10:38 : sushi76 Currently there are only these three Options Private field, content only available to privileged users. (Admin users) Public field, content shown on profile page but not used on member list pages. (Everyone, but not in the member list) Public field, content shown on profile page and on member list pages. (Everyone, everywhere) It should be possible to set the visibilty of profile fields by user roles. ------------------------------------------------------------------------ March 6, 2005 - 12:40 : tulula I agree! If visibility is set by roles OR if the option is left up to the user to display their info at their discretion vs Admin at level of setting up profile fields. ------------------------------------------------------------------------ June 5, 2005 - 21:03 : ejort I agree that it should be possible to set visibility per role. There is profile data on my site that I want my organisation's committee members to see, but nobody else, there's information that I want only authenticated users to see, but not anonymous users etc. More than that, I think we should be able to set field editability by role also. There is data on my site that only certain people should be able to edit. If we get to this point then this would be a superset of the functionality discussed in the PROFILE_HIDDEN updates [1] thread, but would be much more flexible. [1] http://drupal.org/node/21219 ------------------------------------------------------------------------ June 10, 2005 - 00:07 : ejort Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.… (12.97 KB) Hi, Here's a patch which implements role based edit / access permissions for profile fields. It allows you to give permissions to each role (and for each field) to: * access a field (for all accounts) * access a field for your own account * edit a field for your account Users with permission 'administer users' can access / edit all fields, and users must have enough permission to edit/access a profile for these extra permissions to come into effect. I believe this allows for more flexibility than the existing profile.module method of PROFILE_PRIVATE and in HEAD PROFILE_HIDDEN. You can eg: * hide some fields from anonymous users, while allowing other roles to still view that info * have fields viewable by only the admin and user who owns the account (like PROFILE_PRIVATE * have fields viewable by some roles, but only editable by the admin * have fields hidden from all except the admin, and editable only by the admin * it will make you more attractive to the opposite sex etc. I'm developing this because I need it for one of my sites, hence, unfortunately this patch is against the 4.6 profile.module. If people think this is a valuable feature for HEAD I can roll a patch against that. Cheers, Eric ------------------------------------------------------------------------ June 10, 2005 - 01:13 : Bèr Kessels I am not too sure about this. A typical profile contains between five and 10 fields, but twenty fields is not unheard of. This patch will flood the permissions screen unnneccesary. I would opt for the hard way: An advanced profile module, or CRM module, or so. hat module could implemen,t all sorts of advanced levelled permissions. In order to maintain a high level of usability in core, we should try to minimize options and checkboxes. I know from flexinode, which adds similar dynamic permissions, that the interface for permissions is really not up to this big amount of permissions. I really think such things should not be in core. Buty that all said, it /is/ a handy feature :) ------------------------------------------------------------------------ June 10, 2005 - 01:53 : ejort Yes, unfortunately it can add a large number of permissions to the permissions page. I did consider trying to place the permission selections on each fields edit page instead (similar to the visibility settings), but as a certain eminent author recently wrote* [2]: "please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages " :-) I think that the PROFILE_PRIVATE and PROFILE_HIDDEN (and the PROFILE_PUBLIC_*) settings are currently doing just that, implementing an alternate permissions system which addresses a few use cases, but is ultimately not particularly flexible. Is there any chance that the permissions sections can benefit from some collapsible goodness to alleviate the flooding? I think it's a shame to reduce the systems flexibility because it may create 'too many' permissions settings, especially as it is generally a set once and forget proposition. Perhaps we should look at the underlying UI problem? *That would be Bér :-) [2] http://drupal.org/node/22565#comment-32248 ------------------------------------------------------------------------ June 10, 2005 - 05:27 : Bèr Kessels Ejort, I know i wrote that. However, this is a little bit different. am not saying you should make a new system for changing the apperance of profile fields. I am only saying that having per-profile-field permissions is: * way OTT for the big mayority of users * extremely cluttering for the permission page (which, essetially is a problem in that interface, not in your "feature") ------------------------------------------------------------------------ June 14, 2005 - 07:22 : ejort I don't agree that this is extremely off topic for most users. A large number of people using drupal in any business setting will likely find the extra flexibility invaluable (and the use cases popping up in discussions for regarding PROFILE_HIDDEN show that the current approach doesn't cover enough of the possibilities). I've worked on multiple jobs where I had to create contact lists and employee profiles where basic information was accessible to the public (name, work email, profile text), certain details (direct phone numbers) were only visible to internal company employees, other data (mobile phone numbers) were visible only to team leaders, other data (next of kin contact details) were only visible to an admin, and the user wasn't allowed to edit certain items (such as the public profile text). I've had similar needs come up across several jobs, but then again I wrote the patch so of course I needed it! :-) I also believe that the permissions page problem isn't too large an issue. The permissions are created in response to the admin creating profile fields (3 per field, 'access', 'access own', 'edit'), so the page has no extra permissions by default. This also isn't an interface that is accessed on a daily basis, and there is a good visual separation of the sections so it is easy to skim past the longer profile section if that's not what you're interested in. Of course, this is all just my opinion, and I'm a biased observer :-) ------------------------------------------------------------------------ June 14, 2005 - 07:37 : Bèr Kessels I know its a handy feature, that will be used in some cases. But then it should nbe in an advanced-profile.module. Not in core. ------------------------------------------------------------------------ June 14, 2005 - 08:12 : judah I would have to disagree with you ber on this one. I have posted some comments on the Hidden Profile update mentioned above. The permission system *should* be apart of core. These shouldn't be broken out into another advanced module. There *shouldn't* be a node_privacy_by_role. This is unheard of in other systems. I have worked on many other cms solutions and permissions is always a part of the design. Should we plaster them on every feature? No. But we should not so easily dismiss this issue. Node privacy by role and field privacy by role should be considered more closely as a core function rather than where it is now. IMHO. Having said that I do understand the need to break things or branch things too. So it is up to you designers to consider this. Assuming this patch gets approved I would suggest you make the role assignment options available on the profile edit page if it's not already. ------------------------------------------------------------------------ June 14, 2005 - 13:09 : killes(a)www.drop.org judah: Drupal has the benefit that we can use any node access scheme we like by using another module. @all: I think the best thing would eb to make profiles nodes and wait for cck for field based permissions. ------------------------------------------------------------------------ June 15, 2005 - 03:19 : Bèr Kessels I think an interim solution would be to: * make profiles nodes * use Flexinode if one wished for profiles . otherwise use a dediceated node for this * add per field permissions to flexinode.

1 0

[drupal-devel] [feature] Profile field visiblity should vary by role
by Bèr Kessels 15 Jun '05

15 Jun '05

Issue status update for http://drupal.org/node/14149 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: ejort Reported by: sushi76 Updated by: Bèr Kessels Status: patch I think an interim solution would be to: * make profiles nodes * use Flexinode if one wished for profiles . otherwise use a dediceated node for this * add per field permissions to flexinode. Bèr Kessels Previous comments: ------------------------------------------------------------------------ December 9, 2004 - 19:38 : sushi76 Currently there are only these three Options Private field, content only available to privileged users. (Admin users) Public field, content shown on profile page but not used on member list pages. (Everyone, but not in the member list) Public field, content shown on profile page and on member list pages. (Everyone, everywhere) It should be possible to set the visibilty of profile fields by user roles. ------------------------------------------------------------------------ March 6, 2005 - 21:40 : tulula I agree! If visibility is set by roles OR if the option is left up to the user to display their info at their discretion vs Admin at level of setting up profile fields. ------------------------------------------------------------------------ June 6, 2005 - 06:03 : ejort I agree that it should be possible to set visibility per role. There is profile data on my site that I want my organisation's committee members to see, but nobody else, there's information that I want only authenticated users to see, but not anonymous users etc. More than that, I think we should be able to set field editability by role also. There is data on my site that only certain people should be able to edit. If we get to this point then this would be a superset of the functionality discussed in the PROFILE_HIDDEN updates [1] thread, but would be much more flexible. [1] http://drupal.org/node/21219 ------------------------------------------------------------------------ June 10, 2005 - 09:07 : ejort Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.… (12.97 KB) Hi, Here's a patch which implements role based edit / access permissions for profile fields. It allows you to give permissions to each role (and for each field) to: * access a field (for all accounts) * access a field for your own account * edit a field for your account Users with permission 'administer users' can access / edit all fields, and users must have enough permission to edit/access a profile for these extra permissions to come into effect. I believe this allows for more flexibility than the existing profile.module method of PROFILE_PRIVATE and in HEAD PROFILE_HIDDEN. You can eg: * hide some fields from anonymous users, while allowing other roles to still view that info * have fields viewable by only the admin and user who owns the account (like PROFILE_PRIVATE * have fields viewable by some roles, but only editable by the admin * have fields hidden from all except the admin, and editable only by the admin * it will make you more attractive to the opposite sex etc. I'm developing this because I need it for one of my sites, hence, unfortunately this patch is against the 4.6 profile.module. If people think this is a valuable feature for HEAD I can roll a patch against that. Cheers, Eric ------------------------------------------------------------------------ June 10, 2005 - 10:13 : Bèr Kessels I am not too sure about this. A typical profile contains between five and 10 fields, but twenty fields is not unheard of. This patch will flood the permissions screen unnneccesary. I would opt for the hard way: An advanced profile module, or CRM module, or so. hat module could implemen,t all sorts of advanced levelled permissions. In order to maintain a high level of usability in core, we should try to minimize options and checkboxes. I know from flexinode, which adds similar dynamic permissions, that the interface for permissions is really not up to this big amount of permissions. I really think such things should not be in core. Buty that all said, it /is/ a handy feature :) ------------------------------------------------------------------------ June 10, 2005 - 10:53 : ejort Yes, unfortunately it can add a large number of permissions to the permissions page. I did consider trying to place the permission selections on each fields edit page instead (similar to the visibility settings), but as a certain eminent author recently wrote* [2]: "please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages " :-) I think that the PROFILE_PRIVATE and PROFILE_HIDDEN (and the PROFILE_PUBLIC_*) settings are currently doing just that, implementing an alternate permissions system which addresses a few use cases, but is ultimately not particularly flexible. Is there any chance that the permissions sections can benefit from some collapsible goodness to alleviate the flooding? I think it's a shame to reduce the systems flexibility because it may create 'too many' permissions settings, especially as it is generally a set once and forget proposition. Perhaps we should look at the underlying UI problem? *That would be Bér :-) [2] http://drupal.org/node/22565#comment-32248 ------------------------------------------------------------------------ June 10, 2005 - 14:27 : Bèr Kessels Ejort, I know i wrote that. However, this is a little bit different. am not saying you should make a new system for changing the apperance of profile fields. I am only saying that having per-profile-field permissions is: * way OTT for the big mayority of users * extremely cluttering for the permission page (which, essetially is a problem in that interface, not in your "feature") ------------------------------------------------------------------------ June 14, 2005 - 16:22 : ejort I don't agree that this is extremely off topic for most users. A large number of people using drupal in any business setting will likely find the extra flexibility invaluable (and the use cases popping up in discussions for regarding PROFILE_HIDDEN show that the current approach doesn't cover enough of the possibilities). I've worked on multiple jobs where I had to create contact lists and employee profiles where basic information was accessible to the public (name, work email, profile text), certain details (direct phone numbers) were only visible to internal company employees, other data (mobile phone numbers) were visible only to team leaders, other data (next of kin contact details) were only visible to an admin, and the user wasn't allowed to edit certain items (such as the public profile text). I've had similar needs come up across several jobs, but then again I wrote the patch so of course I needed it! :-) I also believe that the permissions page problem isn't too large an issue. The permissions are created in response to the admin creating profile fields (3 per field, 'access', 'access own', 'edit'), so the page has no extra permissions by default. This also isn't an interface that is accessed on a daily basis, and there is a good visual separation of the sections so it is easy to skim past the longer profile section if that's not what you're interested in. Of course, this is all just my opinion, and I'm a biased observer :-) ------------------------------------------------------------------------ June 14, 2005 - 16:37 : Bèr Kessels I know its a handy feature, that will be used in some cases. But then it should nbe in an advanced-profile.module. Not in core. ------------------------------------------------------------------------ June 14, 2005 - 17:12 : judah I would have to disagree with you ber on this one. I have posted some comments on the Hidden Profile update mentioned above. The permission system *should* be apart of core. These shouldn't be broken out into another advanced module. There *shouldn't* be a node_privacy_by_role. This is unheard of in other systems. I have worked on many other cms solutions and permissions is always a part of the design. Should we plaster them on every feature? No. But we should not so easily dismiss this issue. Node privacy by role and field privacy by role should be considered more closely as a core function rather than where it is now. IMHO. Having said that I do understand the need to break things or branch things too. So it is up to you designers to consider this. Assuming this patch gets approved I would suggest you make the role assignment options available on the profile edit page if it's not already. ------------------------------------------------------------------------ June 14, 2005 - 22:09 : killes(a)www.drop.org judah: Drupal has the benefit that we can use any node access scheme we like by using another module. @all: I think the best thing would eb to make profiles nodes and wait for cck for field based permissions.

1 0

[drupal-devel] [bug] Forum module's use of if in Postgresql
by igrcic 15 Jun '05

15 Jun '05

Issue status update for http://drupal.org/node/23499 Project: Drupal Version: 4.6.0 Component: forum.module Category: bug reports Priority: normal Assigned to: patrickslee Reported by: cchamilt Updated by: igrcic Status: patch Dont know about you guys but that patch doesnt work for me in drupal 4.6.1!? Im using PostgreSQL. Instead im using following function that works just fine if(integer,text,text) BEGIN IF $1 THEN RETURN $2; END IF; IF NOT $1 THEN RETURN $3; END IF; END; igrcic Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 04:32 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45. ------------------------------------------------------------------------ May 24, 2005 - 22:07 : patrickslee Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached. ------------------------------------------------------------------------ May 24, 2005 - 22:28 : adrian There is an IF function defined in the database.pgsql function. On what page is this happening, as what might be happening is that the type isn't being picked up correctly. It's defined as IF(anyelement, anyelement, text) returns anyelement. IIRC. What I have seen happen is that it wants the text field to return integer, or vice versa. ------------------------------------------------------------------------ May 24, 2005 - 22:32 : patrickslee I found the definition in database.pgsql. It is like this: CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; So it is actually wanting boolean. ------------------------------------------------------------------------ May 24, 2005 - 22:43 : patrickslee So my patch will work, and we can make it easier by replacing the IF function to: IF(l.last_comment_uid 0 AND l.last_comment_uid NULL, cu.name, l.last_comment_name) BTW there is another place in forum.module use IF like this. ------------------------------------------------------------------------ May 24, 2005 - 22:45 : patrickslee Oops... my <>s are stolen. IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ May 25, 2005 - 05:20 : cchamilt Yes that line works great. Thanks for your help! ------------------------------------------------------------------------ May 25, 2005 - 05:52 : patrickslee This patch shows another problem. The last post user will always show "Anonymous" or whatever you defined. Looking for solution... ------------------------------------------------------------------------ May 25, 2005 - 06:00 : patrickslee Use this line instead: IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) Don't forget there are two places in forum.module need to be changed. ------------------------------------------------------------------------ May 25, 2005 - 06:10 : patrickslee Oh what have I done! I changed nothing! IF(l.last_comment_uid <> 0 AND l.last_comment_uid IS NOT NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ May 25, 2005 - 10:12 : adrian perhaps we could also just add more wrapper functions for the specific types ? create or replace function IF (integer, anyelement, anyelement) returns anyelement as ' SELECT if (($1 0) AND NOT nullvalue($1), $2, $3); ' LANGUAGE 'sql'; Or something. ------------------------------------------------------------------------ May 25, 2005 - 10:41 : plj '' was missing. So what adrian actually means is this: CREATE OR REPLACE FUNCTION IF (integer, anyelement, anyelement) RETURNS anyelement AS ' SELECT if (($1 <> 0) AND NOT nullvalue($1), $2, $3); ' LANGUAGE 'sql'; I applied that and now forums work -- no module patches. PostgreSQL 7.4.7. ------------------------------------------------------------------------ May 25, 2005 - 10:45 : plj Sheesh. I meant that '<>' was missing. Gotta learn to use that preview button... ------------------------------------------------------------------------ May 25, 2005 - 21:53 : patrickslee Is nullvalue() a function? I cannot find it in neither postgres manual nor mysql manual. Use "IS NOT NULL" would be better as it is more standard-compatible. SO we have this: CREATE OR REPLACE FUNCTION IF (integer, anyelement, anyelement) RETURNS anyelement AS ' SELECT IF(($1 <> 0) AND $1 IS NOT NULL, $2, $3); ' LANGUAGE 'sql'; Looks we have a satisfying fix here. Is this fix going to be committed in CVS for next release? ------------------------------------------------------------------------ May 26, 2005 - 00:26 : adrian hostmaster=# \df nullvalue List of functions Result data type | Schema | Name | Argument data types ------------------+------------+-----------+--------------------- boolean | pg_catalog | nullvalue | "any" But it doesn't matter to me =) ------------------------------------------------------------------------ May 26, 2005 - 19:21 : Dries Can you guys provide a patch? I don't have a PostgreSQL setup to test it against. Will commit to DRUPAL-4-6 and HEAD. ------------------------------------------------------------------------ May 26, 2005 - 20:29 : patrickslee Attachment: http://drupal.org/files/issues/database.pgsql_3.patch (363 bytes) Here you have it.

1 0

[drupal-devel] [bug] Last access time reports the epoch instead of 'never'
by puregin 15 Jun '05

15 Jun '05

Issue status update for http://drupal.org/node/24766 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: minor Assigned to: deekayen Reported by: puregin Updated by: puregin Status: patch The patch fixes the problem, thanks. Are there other places in Drupal where this kind of message might occur? Is it possible for the timestamp to be negative under any circumstances (if so, perhaps the test should be $account->access <= 0 rather than $account->access == 0) Regards, Djun puregin Previous comments: ------------------------------------------------------------------------ June 10, 2005 - 11:32 : puregin As site admin, I create a user. When I look at the user admin page immediately afterwards, the user shows up with a 'last access' time of '35 years 24 weeks ago'. Could we report 'Never' instead of the epoch, if the last access time is older than the user account? I seem to recall a similar report, but I couldn't find it after searching through the issues for user.module, and issues in general. Djun ------------------------------------------------------------------------ June 14, 2005 - 01:01 : deekayen Attachment: http://drupal.org/files/issues/wrong_last_access.png (6.13 KB) I verified this on WinXP/PHP5.1. Screenshot attached. ------------------------------------------------------------------------ June 14, 2005 - 01:22 : deekayen Attachment: http://drupal.org/files/issues/epochuser.patch (1.17 KB) Attached patch shows "never" instead of epoch on new users with 0 as last visited value in the DB

1 0

[drupal-devel] [bug] path: help text mentions conf.php
by puregin 15 Jun '05

15 Jun '05

Issue status update for http://drupal.org/node/24397 Project: Drupal Version: cvs Component: path.module Category: bug reports Priority: minor Assigned to: deekayen Reported by: pz Updated by: puregin Status: patch I've sent a note to Kieran, who's in the middle of updating help texts, to be aware of this when he comes to look at path.module. Thanks, Djun puregin Previous comments: ------------------------------------------------------------------------ June 6, 2005 - 06:31 : pz Help text for path.module mentions conf.php which no longer exists, should probably be settings.php (or sites/default/settings.php) instead. ------------------------------------------------------------------------ June 14, 2005 - 01:43 : deekayen Attachment: http://drupal.org/files/issues/oldconf.patch (2.08 KB) attached patch changes conf.php reference to sites/default/settings.php

1 0

[drupal-devel] [bug] Category selection does not work with Movable Type blogapi
by baudolino 15 Jun '05

15 Jun '05

Issue status update for http://drupal.org/node/24030 Project: Drupal Version: 4.6.1 Component: blogapi.module Category: bug reports Priority: normal Assigned to: walkah Reported by: mrmachine Updated by: baudolino -Status: fixed +Status: patch This is not fixed until a decision about whether to commit this patch is made. Reverting this to patch status. baudolino Previous comments: ------------------------------------------------------------------------ May 31, 2005 - 18:38 : mrmachine Using a blog client (linux - either Drivel or BlogTK) and the Moveable Type api, you can retrieve categories and select one for your post, but once the post is submitted, it fails to allocate the category - making the use of a blog tool pretty useless. ------------------------------------------------------------------------ May 31, 2005 - 18:45 : laura s I use ecto, set to MoveableType API,but so far I'm not able to repeat this problem. Could it be the client? I was also able to set Drupal's BlogAPI to the MetaWeblog setting and it seemed to work fine -- even with ecto set to MoveableType API. You might be able to try that as a workaround. ------------------------------------------------------------------------ June 2, 2005 - 08:04 : mrmachine I tried ecto on my son's Windows box, and yes - it does set categories correctly ... too bad there's no linux version but anyway, i tried changing Drupal's blogapi to Metaweblog, and kept Drivel and BlogTK set to Moveable Type API. It didn't work for Drivel, but it did for BlogTK ... thanx for the hint! ------------------------------------------------------------------------ June 5, 2005 - 10:36 : fflewddur I've been trouble-shooting this issue using w.bloggar on Windows and Drivel on Linux. w.bloggar is able to post using the Movable Type API, but the category selection only works if you click "Post", not "Post and Publish". Drivel, by default, publishes all posts, which is why the category never shows up when using Drivel with Drupal. To post entries with categories to an official Movable Type implementation, the client must first post the entry, then call mt.setPostCategories, and then call mt.publishPost. The mt.publishPost call is what seems to be confusing Drupal, as it doesn't appear to differentiate between a post that has been published with one which has. Movable Type does not publicly display posts which have not been published; it considers them as drafts which the author has not yet finished. Thus, Movable Type servers require the mt.publishPost call. I have Ethereal traces of several example posts to Drupal using both w.bloggar in "post" and "post and publish" mode, as well as Drivel. If you think they'd be useful in debugging, let me know and I'll forward them on to you. Cheers, Todd ------------------------------------------------------------------------ June 8, 2005 - 23:57 : mrmachine has anyone had a chance to look at this since Todd debugged it? ------------------------------------------------------------------------ June 13, 2005 - 16:56 : mrmachine can someone have a look at this? ------------------------------------------------------------------------ June 13, 2005 - 20:05 : walkah Attachment: http://drupal.org/files/issues/blogapi-publish-post.patch (634 bytes) having a look - it seems that mt.publishPost may well have been wiping the term info set by setCategory. As I only have ecto available to me currently, I can't test this patch... but if I understand the debugging work correctly - this should fix it. (the difference being ecto and MarsEdit - the two that I have access to currently - don't call publishPost). please confirm this fixes things... thanks. (I'll test more when I'm home again at the end of the week). ------------------------------------------------------------------------ June 14, 2005 - 19:06 : mrmachine beauty! this has fixed it for me! thanx shayne

1 0

[drupal-devel] [feature] Profile field visiblity should vary by role
by killes 14 Jun '05

14 Jun '05

Issue status update for http://drupal.org/node/14149 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: ejort Reported by: sushi76 Updated by: killes(a)www.drop.org Status: patch judah: Drupal has the benefit that we can use any node access scheme we like by using another module. @all: I think the best thing would eb to make profiles nodes and wait for cck for field based permissions. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ December 9, 2004 - 20:38 : sushi76 Currently there are only these three Options Private field, content only available to privileged users. (Admin users) Public field, content shown on profile page but not used on member list pages. (Everyone, but not in the member list) Public field, content shown on profile page and on member list pages. (Everyone, everywhere) It should be possible to set the visibilty of profile fields by user roles. ------------------------------------------------------------------------ March 6, 2005 - 22:40 : tulula I agree! If visibility is set by roles OR if the option is left up to the user to display their info at their discretion vs Admin at level of setting up profile fields. ------------------------------------------------------------------------ June 6, 2005 - 07:03 : ejort I agree that it should be possible to set visibility per role. There is profile data on my site that I want my organisation's committee members to see, but nobody else, there's information that I want only authenticated users to see, but not anonymous users etc. More than that, I think we should be able to set field editability by role also. There is data on my site that only certain people should be able to edit. If we get to this point then this would be a superset of the functionality discussed in the PROFILE_HIDDEN updates [1] thread, but would be much more flexible. [1] http://drupal.org/node/21219 ------------------------------------------------------------------------ June 10, 2005 - 10:07 : ejort Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.… (12.97 KB) Hi, Here's a patch which implements role based edit / access permissions for profile fields. It allows you to give permissions to each role (and for each field) to: * access a field (for all accounts) * access a field for your own account * edit a field for your account Users with permission 'administer users' can access / edit all fields, and users must have enough permission to edit/access a profile for these extra permissions to come into effect. I believe this allows for more flexibility than the existing profile.module method of PROFILE_PRIVATE and in HEAD PROFILE_HIDDEN. You can eg: * hide some fields from anonymous users, while allowing other roles to still view that info * have fields viewable by only the admin and user who owns the account (like PROFILE_PRIVATE * have fields viewable by some roles, but only editable by the admin * have fields hidden from all except the admin, and editable only by the admin * it will make you more attractive to the opposite sex etc. I'm developing this because I need it for one of my sites, hence, unfortunately this patch is against the 4.6 profile.module. If people think this is a valuable feature for HEAD I can roll a patch against that. Cheers, Eric ------------------------------------------------------------------------ June 10, 2005 - 11:13 : Bèr Kessels I am not too sure about this. A typical profile contains between five and 10 fields, but twenty fields is not unheard of. This patch will flood the permissions screen unnneccesary. I would opt for the hard way: An advanced profile module, or CRM module, or so. hat module could implemen,t all sorts of advanced levelled permissions. In order to maintain a high level of usability in core, we should try to minimize options and checkboxes. I know from flexinode, which adds similar dynamic permissions, that the interface for permissions is really not up to this big amount of permissions. I really think such things should not be in core. Buty that all said, it /is/ a handy feature :) ------------------------------------------------------------------------ June 10, 2005 - 11:53 : ejort Yes, unfortunately it can add a large number of permissions to the permissions page. I did consider trying to place the permission selections on each fields edit page instead (similar to the visibility settings), but as a certain eminent author recently wrote* [2]: "please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages " :-) I think that the PROFILE_PRIVATE and PROFILE_HIDDEN (and the PROFILE_PUBLIC_*) settings are currently doing just that, implementing an alternate permissions system which addresses a few use cases, but is ultimately not particularly flexible. Is there any chance that the permissions sections can benefit from some collapsible goodness to alleviate the flooding? I think it's a shame to reduce the systems flexibility because it may create 'too many' permissions settings, especially as it is generally a set once and forget proposition. Perhaps we should look at the underlying UI problem? *That would be Bér :-) [2] http://drupal.org/node/22565#comment-32248 ------------------------------------------------------------------------ June 10, 2005 - 15:27 : Bèr Kessels Ejort, I know i wrote that. However, this is a little bit different. am not saying you should make a new system for changing the apperance of profile fields. I am only saying that having per-profile-field permissions is: * way OTT for the big mayority of users * extremely cluttering for the permission page (which, essetially is a problem in that interface, not in your "feature") ------------------------------------------------------------------------ June 14, 2005 - 17:22 : ejort I don't agree that this is extremely off topic for most users. A large number of people using drupal in any business setting will likely find the extra flexibility invaluable (and the use cases popping up in discussions for regarding PROFILE_HIDDEN show that the current approach doesn't cover enough of the possibilities). I've worked on multiple jobs where I had to create contact lists and employee profiles where basic information was accessible to the public (name, work email, profile text), certain details (direct phone numbers) were only visible to internal company employees, other data (mobile phone numbers) were visible only to team leaders, other data (next of kin contact details) were only visible to an admin, and the user wasn't allowed to edit certain items (such as the public profile text). I've had similar needs come up across several jobs, but then again I wrote the patch so of course I needed it! :-) I also believe that the permissions page problem isn't too large an issue. The permissions are created in response to the admin creating profile fields (3 per field, 'access', 'access own', 'edit'), so the page has no extra permissions by default. This also isn't an interface that is accessed on a daily basis, and there is a good visual separation of the sections so it is easy to skim past the longer profile section if that's not what you're interested in. Of course, this is all just my opinion, and I'm a biased observer :-) ------------------------------------------------------------------------ June 14, 2005 - 17:37 : Bèr Kessels I know its a handy feature, that will be used in some cases. But then it should nbe in an advanced-profile.module. Not in core. ------------------------------------------------------------------------ June 14, 2005 - 18:12 : judah I would have to disagree with you ber on this one. I have posted some comments on the Hidden Profile update mentioned above. The permission system *should* be apart of core. These shouldn't be broken out into another advanced module. There *shouldn't* be a node_privacy_by_role. This is unheard of in other systems. I have worked on many other cms solutions and permissions is always a part of the design. Should we plaster them on every feature? No. But we should not so easily dismiss this issue. Node privacy by role and field privacy by role should be considered more closely as a core function rather than where it is now. IMHO. Having said that I do understand the need to break things or branch things too. So it is up to you designers to consider this. Assuming this patch gets approved I would suggest you make the role assignment options available on the profile edit page if it's not already.

1 0

[drupal-devel] [bug] request_uri() broken if in subdir
by Robin Monks 14 Jun '05

14 Jun '05

Issue status update for http://drupal.org/node/10917 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: killes(a)www.drop.org Updated by: Robin Monks Status: patch I spent some more time testing, and this broke some (perhaps all) configuration forms. It appears the / is needed after all. Perhaps killes will have better luck understanding this, the / is needed IMHO. Robin Robin Monks Previous comments: ------------------------------------------------------------------------ September 17, 2004 - 19:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/requi.patch (678 bytes) We asumme the $_SERVER[REQUEST_URI] would contain only the url from the point of Drupal's directory on. This is true only iff you run from the root of your site. If you are in a subdir, the function request_uri() will be unusable if we want to construct a valid url from $base_url and request_uri() (what we do in a number of places). The attached patch fixes this by using basename(). ------------------------------------------------------------------------ September 17, 2004 - 19:45 : killes(a)www.drop.org The patch doesn't suffice if your access only the base_url of your Drupal site in a subdir. Putting on hold. ------------------------------------------------------------------------ September 17, 2004 - 21:39 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request.patch (761 bytes) ok, I think I got it. The distinction between apache and non-apache servers went away to keep it simple. ------------------------------------------------------------------------ September 18, 2004 - 00:19 : killes(a)www.drop.org Apparently the action in forms depends on the bug that I found, ie it needs request_uri to contain the full url (from documentroot on). ------------------------------------------------------------------------ September 18, 2004 - 00:53 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request_0.patch (2.46 KB) This new patch fixes the problem with forms. request_uri() also does not start with a leading slash anymore. Ask Steven for why this is good. http://acko.net/dumpx/relative.html is apparently a clue I don't get. ------------------------------------------------------------------------ September 18, 2004 - 01:04 : Steven Explanation: People are going to stick relative_uri() into links. These links are resolved relative to the $base_url which is put into the <head> tag. However, if a link URI starts with a / then it is relative to the root of the site, even if the base tag uses a path with a subdirectory. Example: <html> <base href="http://www.test.com/subdir1/"> <body> test [1] test [2] </body> </html> The first link resolves to http://www.test.com/subdir2, the second resolves to http://www.test.com/subdir1/subdir2. Thus, it is more meaningful to not have a leading slash, as this will avoid possible bugs with subdirs (which often do not get caught because the tester uses a site without a subdir) and hints at the callee that this is a relative URI too. [1] http://drupal.org//subdir2 [2] http://drupal.org/subdir2 ------------------------------------------------------------------------ March 13, 2005 - 18:38 : Chris Johnson Patch no longer applies completely to bootstrap.inc: Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/bootstrap.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/bootstrap.inc,v |retrieving revision 1.28 |diff -u -F^f -r1.28 bootstrap.inc |--- includes/bootstrap.inc 16 Sep 2004 07:17:54 -0000 1.28 |+++ includes/bootstrap.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file bootstrap.inc using Plan A... Hunk #1 succeeded at 273 (offset 83 lines). Hunk #2 succeeded at 292 (offset 83 lines). Hunk #3 failed at 446. 1 out of 3 hunks failed--saving rejects to bootstrap.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/common.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/common.inc,v |retrieving revision 1.390 |diff -u -F^f -r1.390 common.inc |--- includes/common.inc 16 Sep 2004 16:12:21 -0000 1.390 |+++ includes/common.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file common.inc using Plan A... Hunk #1 succeeded at 988 (offset -90 lines). done ------------------------------------------------------------------------ June 14, 2005 - 11:21 : Robin Monks Attachment: http://drupal.org/files/issues/request_uri.broken.if.in.subdir.patch (2.6 KB) Here is that patch re-rolled for latest CVS HEAD. Since killes hasn't been active in this bug lately, I hope he won't mind my reassigning this to myself. Robin ------------------------------------------------------------------------ June 14, 2005 - 11:22 : Robin Monks I've also tested this to work on CVS HEAD. Robin ------------------------------------------------------------------------ June 14, 2005 - 13:33 : moshe weitzman did you test this on non apache servers? the comment that you removed is crystal clear about a need for 2 different cases. it is OK to 'make it simpler' as long as you don't remove compatibility with other web servers. I am primarily concerned with IIS. ------------------------------------------------------------------------ June 14, 2005 - 14:42 : Robin Monks I took great care to ensure I didn't remove any support needed for other servers. I also tested this patch to work on Xitami on Win32. Robin

1 0