Posted by bdietz on November 11, 2008 at 11:10pm
| Project: | Availability Calendars |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | nicholas.alipaz |
| Status: | closed (fixed) |
Issue Summary
I have set permissions to 'edit own availability calendars' but the 'edit' option is not showing up when user's create a node type with the availability calendar enabled. Any ideas as to why this is not working properly?
Comments
#1
Do you see the actual availability calendars on the node you're trying to edit the availability of, but not the edit links for each month? Does it work for you as an admin?
#2
I got the same issue, but it is on version 5.
Edit own avaialbility calendar does not work for users. (edit links not showing)
It works for admin.
and if I change the permission of users to edit all availability calendars, it works.
Thank you
#3
I've just tried this out, and can confirm that the 'edit own availability calendars' permission isn't working. I'll try to get a fix for it soon.
#4
#5
Any updates on this ...or any idea what should be done for a possible resolution?
#6
I've not worked on it yet, sorry, and there isn't really a workaround other than to allow all users with a certain role edit all the availability calendars on a site.
#7
Hi Geodaniel,
Do you think there will be a solution soon for this ? It would be great if this module could let each user edit their own calendar even if they have the same role.
#8
This would make the functionality awesome if we could get this to work. A specific user needs the ability to edit their own calendars. Currently it is edit all users calendars or edit no calendars.
- Maybe option A is to present the calendar in the same form (as when viewing the node) while in edit-node-mode, showing the edit links only while editing the node. This way a user is only able to edit their own content.
- Maybe option B is to use the "node" user access code. Maybe something similar to this would work for AC.
/**
* @defgroup node_access Node access rights
* @{
* The node access system determines who can do what to which nodes.
*
* In determining access rights for a node, node_access() first checks
* whether the user has the "administer nodes" permission. Such users have
* unrestricted access to all nodes. Then the node module's hook_access()
* is called, and a TRUE or FALSE return value will grant or deny access.
* This allows, for example, the blog module to always grant access to the
* blog author, and for the book module to always deny editing access to
* PHP pages.
*
* If node module does not intervene (returns NULL), then the
* node_access table is used to determine access. All node access
* modules are queried using hook_node_grants() to assemble a list of
* "grant IDs" for the user. This list is compared against the table.
* If any row contains the node ID in question (or 0, which stands for "all
* nodes"), one of the grant IDs returned, and a value of TRUE for the
* operation in question, then access is granted. Note that this table is a
* list of grants; any matching row is sufficient to grant access to the
* node.
*
* In node listings, the process above is followed except that
* hook_access() is not called on each node for performance reasons and for
* proper functioning of the pager system. When adding a node listing to your
* module, be sure to use db_rewrite_sql() to add
* the appropriate clauses to your query for access checks.
*
* To see how to write a node access module of your own, see
* node_access_example.module.
*/
/**
* Determine whether the current user may perform the given operation on the
* specified node.
*
* @param $op
* The operation to be performed on the node. Possible values are:
* - "view"
* - "update"
* - "delete"
* - "create"
* @param $node
* The node object (or node array) on which the operation is to be performed,
* or node type (e.g. 'forum') for "create" operation.
* @param $account
* Optional, a user object representing the user for whom the operation is to
* be performed. Determines access for a user other than the current user.
* @return
* TRUE if the operation may be performed.
*/
function node_access($op, $node, $account = NULL) {
global $user;
if (!$node || !in_array($op, array('view', 'update', 'delete', 'create'), TRUE)) {
// If there was no node to check against, or the $op was not one of the
// supported ones, we return access denied.
return FALSE;
}
// Convert the node to an object if necessary:
if ($op != 'create') {
$node = (object)$node;
}
// If no user object is supplied, the access check is for the current user.
if (empty($account)) {
$account = $user;
}
// If the node is in a restricted format, disallow editing.
if ($op == 'update' && !filter_access($node->format)) {
return FALSE;
}
if (user_access('administer nodes', $account)) {
return TRUE;
}
if (!user_access('access content', $account)) {
return FALSE;
}
// Can't use node_invoke(), because the access hook takes the $op parameter
// before the $node parameter.
$module = node_get_types('module', $node);
if ($module == 'node') {
$module = 'node_content'; // Avoid function name collisions.
}
$access = module_invoke($module, 'access', $op, $node, $account);
if (!is_null($access)) {
return $access;
}
// If the module did not override the access rights, use those set in the
// node_access table.
if ($op != 'create' && $node->nid && $node->status) {
$grants = array();
foreach (node_access_grants($op, $account) as $realm => $gids) {
foreach ($gids as $gid) {
$grants[] = "(gid = $gid AND realm = '$realm')";
}
}
$grants_sql = '';
if (count($grants)) {
$grants_sql = 'AND ('. implode(' OR ', $grants) .')';
}
$sql = "SELECT COUNT(*) FROM {node_access} WHERE (nid = 0 OR nid = %d) $grants_sql AND grant_$op >= 1";
$result = db_query($sql, $node->nid);
return (db_result($result));
}
// Let authors view their own nodes.
if ($op == 'view' && $account->uid == $node->uid && $account->uid != 0) {
return TRUE;
}
return FALSE;
}
#9
If
http://localhost/availability-calendars/4/2009/05/edit?destination=node/4is a page for user A, user B can type in this address and edit user A calendar, even when permissions are not granted to edit any calendars.
Anonymous users are unable to edit so they are poperly blocked.
#10
I have chaned a few bits of code and it works for me now. Seems to work both on 5 and 6
CHanged few lines on availability_calendars.module file
function theme_availability_calendars_month($node, $year, $month, $startofweek, $booked) {
//++++++ Extra Line ++++++++
global $user;
if (user_access('edit availability calendars')) {
//++++++ Extra Line ++++++++
if (user_access('edit own availability calendars') && ($user->uid == $node->uid)) {
$output .= ' '. l('edit', 'availability-calendars/'. $node->nid .'/'. date('Y/m', mktime(0,0,0,$month,1,$year)) .'/edit', NULL, 'destination=node/'. $node->nid);
//++++++ Extra Line ++++++++
}
}
#11
please post as patch against latest 5.x version if you want the changes included. I cannot maintain 5.x, but will commit a patch for you if it's tested and works, really people should have upgraded by now, but that is a different discussion.
#12
#13
Hi,
I have no idea how to comit it as I do not have permissions.
It defenitely works and also there are many people who have not upgraded to 6 as they worry about breaking their website ( Many new modules for 6 are incomplete or in beta)
#14
http://drupal.org/patch/create
Create a patch and I will commit it.
#15
I've been waiting for this to happen for some time now.. would be great if it could be implemented :) I can't use this module till then since everyone can edit each other calendar.
#16
Here is the patch for 6 . This patch makes sure only owners can edit the calendar ( If you set permissions). Few people has confirmed it works.
#17
Hopefully, I can have time to test next month. Sorry for delay, thanks for work on it.
#18
Has this moved at all?
I've seen no new changes to the stable release since September 09 and to the dev release since October 09.
I'm looking for this kind of functionality for my site to help me determine when members are available for events on a monthly basis.
#19
It has not moved.. but the solution above does work. The solution has not been yet implemented / applied by the module maintainer...
#20
Attached patch implements the 'edit' links on the node view for 'edit own availability calendars' - note this patch also adds some higher order css specificity to the background-colours in the table for themes that implement tr.odd/tr.even
#21
You also need this patch as the 'edit own calendars' is not implemented securely, ie there is no difference between the 'edit calendars' and 'edit own calendars' without this patch
#22
Can we get these patches condensed down to one? I am getting a little confused as to which of these are dependent on eachother.
--
Los Angeles Web Design and development for Drupal.
#23
Having trouble running these patches.
#10 is unclear - not sure exactly what to change
#16 doesn't seem to be a correctly made patch
#21 seems to have the same purpose #16 and has some overlapping code as but has many differences
What to do?
#24
Subscribing, this has to be fixed to be functional for me.
#25
Oh dear, YADDM (Yet Another Dead Drupal Module), well perhaps the attached patch on current dev will help kick it out of the long grass.
It sorts out the permissions issue in #21, adds the suggested css in #20, hilights 'today' in the calendar with css and does a bit of tidying up.
#26
tested patch against 6.x-1.x-dev getting these...
* warning: include_once(./sites/all/modules/availability_calendars/availability_calendars.module) [function.include-once]: failed to open stream: Permission denied in C:\TWAMPd\htdocs\includes\bootstrap.inc on line 611.
* warning: include_once() [function.include]: Failed opening './sites/all/modules/availability_calendars/availability_calendars.module' for inclusion (include_path='.;../app/bin/PEAR;../../app/bin/PEAR;../../../app/bin/PEAR;../../../../app/bin/PEAR;../../../../../app/bin/PEAR') in C:\htdocs\includes\bootstrap.inc on line 611.
#27
Either the file does not have read permissions, is not there or has been renamed in some way. Check them and it should work.
#28
Thanks Hutch. The module file and css somehow had no permissions, maybe after update. Set to read perms and errors gone. Tested, works well.
#29
...get 'invalid pane id' in the 'settings' modal in Panels for Availability Calendar, Key and Legend widgets.
A panel node is being used for display of node type 'X'.
#30
Hi Hutch,
Your patch actually works (#26)--as I am able to allow each user to edit their own availability calendars but I get this error on all my pages, 2 times:
warning: Missing argument 1 for availability_can_edit() in /Users/Cale/Sites/acquia-drupal/sites/all/modules/availability_calendars/availability_calendars.module on line 24.
thus, I am unable to use this module if I can't get rid of this error. Any suggestions?
#31
Fixed.
In order to remove warning message, I went to 'edit content type' (content type selected for Availability Calendar) and disabled "Availability Calendar" checkbox.
Then, I re-enabled Availability Calendar and it removed the message.
Works. Thank you :)
#32
Thanks for the patch, I have gone through most of the changes and committed them to the 6.x branch.
CSS:
I did not commit the css changes aside from the today theming as I don't see the ultimate reason for the specificity. The extra specificity could also cause some sites to lose there styling if they upgrade to a new release of the module.
Module Changes:
It is my understanding that it is not typically a good thing to do a bunch of code cleanup/whitespace removal for a patch that is supposed to add functionality, unless you are doing cleanup within the sections of the code you are changing.
Also, I am not really sure why the today class is added into this issue's patch, separate patches should really have a separate issue.
Nonetheless, here is what I have done:
http://drupal.org/cvs?commit=471652
#33
Automatically closed -- issue fixed for 2 weeks with no activity.