If you're not having this trouble but your colleague is, a very common issue is sessions on www/no-www or HTTP/HTTPS URLs. CiviCRM's base URL is hard-coded in the settings file, and while you can follow relative links around the site for a while, some links will be generated from that URL.
Let's say you have a site that's accessible at http://www.example....
You didn't specify which CMS you're using but between your CMS permissioning and Civi ACLs, that should be possible. See here for some info: http://book.civicrm.org/user/initial-set-up/permissions-and-access-control/
Just a thought to consider though... if you want to present particular sets of data to your board members in a simplified way, creating Views ...
This is a bug already reported at https://issues.civicrm.org/jira/browse/CRM-15371.
Managing tags needs its own permission rather than requiring "administer CiviCRM" permission. Anyone interested in getting started on core programming will likely find this a good one to begin with.
As far as the end-of-year giving statements are concerned, this has been available in CiviCRM since 4.4, but not documented in the user and admin guide.
It is documented in the 4.6 version of the guide which will be published soon. (The publishing software we were using has stopped working, so we are working hard to get it ready to publish via a different ...
I assume you are seeing this as an anonymous visitor to the site and it fuctions properly if you are logged in. If this is the case, I think you'll need to add anonymous users as able to see the information for these public profiles. In CiviCRM go to Administer > User and Permissions > Permissions (Access Control). Select the 'Wordpress Access Control'.
These are the Unix/Linux permissions I tend to set my permissions for CiviCRM directories in Drupal 7:
chmod 555 sites/default
chmod 644 sites/default/settings.php
chmod 644 sites/default/civicrm.settings.php
chmod 770 sites/default/files
chmod 755 sites/default/files/civicrm
I generally have the ownership set to the hosting account username and the group ...
A few years after the question was asked ... the answer is yes!
Financial ACL's were added a while back but the docs have not been updated yet.
Go to Administer > CiviContribute > CiviContribute Component Settings, and tick Enable Access Control by Financial Type.
Go to your CMS permissions to grant access to each financial type by role.
Will permissions for non-civicrm related permissions "stick"? If not I've seen this problem before when there are too many roles/permissions on the form. Drupal commons installs a lot of modules, so its possible. You should either edit permissions for the roles individually, so for authenticated user for instance goto admin/people/permissions/2
I believe ...
There is an extension that does exactly what you're looking for:
Relationship Permissions as ACLs
The release on the extensions page only does 1 thing (setting permissioned relationships to actually give acl permissions to those contacts, which CiviCRM does not do by default) but if you download the extension directly from github, it has the feature you ...
Yes, that checkbox must be checked. (The one reflecting the specific "direction" you wish.
I don't think you can configure this to occur automatically, however since you have custom code, it should be possible to add the permission automatically using an API call (the parameter name I believe is is_permission_a_b or is_permission_b_a).
Here's an API call:
Currently the event needs to be active to use (preview) it.
If you have an event listing page, you can uncheck Public event. That way users only see the event if you create a link to it. You should be safe in temporarily making it active for testing.
This is the same Question/Answer as: Testing event registration
Two bits are required for anonymous users to be able to access URLs like:
Permissions: make online Contributions
Administer -> CiviContribute -> IATS Payments Settings
Check the box: Enable self-service to recurring contribution Contact Billing ...
I followed @xavier's answer, but I'm posting what I did in case it's useful to others.
See the code below. The '25' is a magic number for this Custom Field, and can be found using the CiviCRM API Explorer. The foreach loop finds the right result among those returned (even though I specify Custom Field '25' I get results for other fields).
What you want
You want the webserver to have read-only access to all the files and dirs or the site can't function.
You want the webserver to have read-write access to all the files it's expected to manage, e.g. everything under sites/default/files
You want the webserver to have read (r) and search (x) access to all directories under your webroot (with the ...
There are a number of reasons they could be getting this error and you're not. Here are the tests to try:
There could be something on your colleague's computer (e.g. a browser plugin) that's affecting the URL being generated. Though unlikely, you'll potentially save yourself a lot of grief by testing this first! To test, use your computer with his login.
You could also utilize Drupal Webforms or a CiviCRM profile to let your staff (or donors) enter donations and just provide the CiviCRM or external ID (without seeing any contact information).
On the issue of year-end statements, there may be good news. We developed an extension that generates donation receipts for your tax authorities - including anual bulk ...
IMHO it seems like you really need a consultant for this stuff. Hopefully an organization of your size (400 chapters with an unknown # of people per chatper) has budget for help.
But let me offer a few bits of advice:
the "corresponded Organisation Group" as you put it CAN be a smart group, thus people (not admins) can self-select their own groups when ...
Do you mean an account is required to even fill in your page, or that filling in the page creates an account?
If the former then it sounds like a permission issue such as Anon not having access to the following
CiviCRM: profile listings and forms
CiviCRM: access all custom data.
These Permissions are usually part of default permissions afaik
Unfortunately I don't think this is possible through the UI. As far as I know the ACLs for custom fields only have a combined view/edit permission - it's both, or nothing. Similarly I don't think it's possible to hide address data out of the box.
If you wanted to stop them viewing the custom fields altogether, you could turn off their access to custom data, ...
Are you sure the two computers access the same address? It's a common mistake to have both www.yourdomain.org and yourdomain.org (without the www) that display the same pages.
Unfortunately, connecting to one doesn't automatically connect to the other, even if they look exactly the same. It's the same with the protocol, so login on http:://yourdomain.org ...
I can't really see the use case where "Edit All Contacts" should be required for adding a tag. I think this is something that should be changed. So the solution is to submit a patch or ask a developer to do so.
Now, I'm not part of the CiviCRM core team - but I do submit patches like this one on behalf of my clients. I'm pretty slammed, but I'll make you ...
Make sure that the folder /var/www/vhosts/examplesite.com/httpdocs/wp-content/plugins/files/civicrm/ is writable to the webserver user.
The simplest solution is to set the permissions on that folder to be read/write for ALL users.
A better solution is to configure the permissions so that they are open to your user account and the webserver alone, but not ...
You can try following:
Go to Administer-> Customize data and Screens-> Navigation Menu and select Mailing.
From mailing option, do right click and edit on 'From Email Address'.
In the next window, you can choose permission to that particular menu under 'Mailing'.
After choosing permission for menu, assign that permission to the role you want.
With this ...
"edit message templates" is a separate permission in CiviCRM 4.6 (see screenshot below), so you'll get this functionality by upgrading.
Upgrading is also a good idea, since version 4.5 isn't a "Long Term Support" version of CiviCRM and thus doesn't receive security updates.
The errors in your log that you note are not a problem, they are CiviCRM doing a little security check for you (and succeeding).
I've seen this occasionally on my servers, and especially on my staging server. I believe that the cause is indirectly related to the errors you are seeing, in that:
If you're logged in, CiviCRM does a fair amount of these checks ...