Closed (fixed)
Project:
Availability Calendars
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
11 Nov 2008 at 23:10 UTC
Updated:
13 Jan 2011 at 18:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
geodaniel commentedDo 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?
Comment #2
onesimpleman commentedI 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
Comment #3
geodaniel commentedI'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.
Comment #4
geodaniel commentedComment #5
onesimpleman commentedAny updates on this ...or any idea what should be done for a possible resolution?
Comment #6
geodaniel commentedI'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.
Comment #7
stijnparidaens commentedHi 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.
Comment #8
crutch commentedThis 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.
Comment #9
crutch commentedIf
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.
Comment #10
onesimpleman commentedI 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 ++++++++
}
}
Comment #11
nicholas.alipaz commentedplease 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.
Comment #12
nicholas.alipaz commentedComment #13
onesimpleman commentedHi,
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)
Comment #14
nicholas.alipaz commentedhttp://drupal.org/patch/create
Create a patch and I will commit it.
Comment #15
Ela commentedI'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.
Comment #16
onesimpleman commentedHere 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.
Comment #17
crutch commentedHopefully, I can have time to test next month. Sorry for delay, thanks for work on it.
Comment #18
Kristina-2 commentedHas 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.
Comment #19
Ela commentedIt has not moved.. but the solution above does work. The solution has not been yet implemented / applied by the module maintainer...
Comment #20
larowlanAttached 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
Comment #21
larowlanYou 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
Comment #22
nicholas.alipaz commentedCan 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.
Comment #23
JimNastic commentedHaving 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?
Comment #24
marcus_w commentedSubscribing, this has to be fixed to be functional for me.
Comment #25
hutch commentedOh 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.
Comment #26
crutch commentedtested 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.
Comment #27
hutch commentedEither the file does not have read permissions, is not there or has been renamed in some way. Check them and it should work.
Comment #28
crutch commentedThanks Hutch. The module file and css somehow had no permissions, maybe after update. Set to read perms and errors gone. Tested, works well.
Comment #29
crutch commented...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'.
Comment #30
calefilm commentedHi 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?
Comment #31
calefilm commentedFixed.
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 :)
Comment #32
nicholas.alipaz commentedThanks 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