Using SC Verson: 3.2.11
Keeping it simple I have added only one user group to the standard Joomla grouping. Calendar Person.

I have only one calendar with Front end event management access level selected for Super Users and Calendar Person. Allow User front end set to Yes.

There are two users on the system.
One user is the Super User (SU) the other is Calender Person (CP). Both users can see the calendar and the Add Event and Manage Events links below the calendar.

Expected behavior: Eithor SU or CP can add and manage events from the front end.
Actual behavior: Neithor SU nor CP can add or manage events from the front end.

What I've found: Both SU and CP must both belong to all groups that are selected on the calendar access listing on the backend. i.e. in this case the SU must be made a Calendar Person group and the CP must be made a Super User. Not a good situation.

I expect that ANY single group selected in the calendar access check boxes will allow users within that group front end calendar add and maintenance capability.

I believe that this is caused by the following block of code located in the various default.php view files for adding and managing the events.

foreach($userGroups as $key=>$value)
{

if (!in_array($userGroups[$key],$access) ){
	$mainframe->redirect(JURI::root(),'access denied','error');

break;
}
}

Dear Phil,

The user groups should be able to function independently, so we guess there is a problem with Spider Calendar installed to your website. It could be caused by permission limitations or conflicts.

Could you please contact us to [email protected] and provide temporary admin access to your website? We'll fix the problem on your product as soon as possible.

Please mention the URL to your forum post in the e-mail subject.
Thank you.

Not to worry. I've fixed it to my satisfaction by replacing the code above where it was required.

However, if any other people get this far and believe that the premise above is correct, I will provide the code and its locations in this thread.

Regards,
Phil

Dear Phil,

Thank you very much for sharing this information. I will set the topic to resolved, so the users facing same problem will easily find it.

Have a great day!

Hi Phil could you help by letting me know the code that you have changed as i am having the same issue.

Thanks

Dear Michael,

If Phil could share his implementation, that would be really great. But alternatively, you can contact us to [email protected] and let us to take a look at this problem, providing a solution to it.

Feel free to let us know!
Thanks.

Micheal,

I'm happy to assist you in this feature addition. Let me know if you have any problems.
First: backup your original files. That's good practice.

The following code will provide the capability discussed in the thread above. i.e. If you allow a specific group or groups to have access to the calendars on the front end of the site, that group or groups will have access. They don't have to belong to all groups with access.

The code change is in each of the following three files on the site side of the component:
Names and approximate line number in each file.
views/add_event/tmpl/default.php ~ Line 69
views/edit_event/tmpl/default.php ~ Line 75
views/show_events/tmpl/default.php ~ Line 79

Procedure: Search for and comment out this block of code in each of the files:

foreach($userGroups as $key=>$value) {
    if (!in_array($userGroups[$key],$access) ){
	$mainframe->redirect(JURI::root(),'access denied','error');
        break;
    }
}

// PRS Added 16 lines.  This is for SHOW-ADD-EDIT capabilities on front end.
$hasAccess = 0; // Start with no access
// access is an array of the groups that are allowed to add and manage the events.
// Test to see if the current user is within one of the groups.
foreach($access as $value1){
    foreach($userGroups as $value2){
        if($value1 == $value2){
            $hasAccess = 1;
        }
        else{
            continue;
        }
        }
    }
if( $hasAccess != 1){
	$mainframe->redirect(JURI::root(),'access denied','error');
}

Thanks Phil, that worked a treat, i don't suppose you would know what code would need to be changed to allow all members to edit all events and not just their own.

Mike

Mike,

Sorry! I didn't need it enough to code it or pay developer.
I asked that question two years ago.
See: web-dorado.com/forum/spider-calendar-joo...ow-does-it-work.html

So I guess they haven't changed that yet. I haven't had the need to go any further with it. It's another one of those philosophical areas. Do you allow anyone to make any changes to any events on the front end or only to events that they create themselves?

They indicated that they could make that change for me, but I'm sure it would be an added charge. They may already have the code and they charge each person that wants it rather than add that functionality into the product. It would certainly enhance the product to have the capability. I could envision having a couple of selections on the back end to allow flexibility on the front end. Each user that would be allowed to make changes on the front end would have a flag set for one or all. Let the wishful thinking continue. Maybe the design team will respond.

Good luck and regards,
Phil

Thanks for the reply, would be a nice feature but may have to wait.

Dear Michael and Phil,

I have reported the issues to our development team. Hopefully they will resolve them soon.
Thank you for letting us know!

Dear Michael and Phil,

This problem is confirmed to be a bug within Spider Calendar. Its fix will be included in the next release of the extension.

Thanks again for reporting the issue to us!