Exclude roles from tracking

http://drupal.org/node/261997

The path filed works like ALL visibility fields in core. This is the reason and we had your variant in past and nobody have understood it. This is why it has been removed in Google Analytics and the stuff change to work in a common way that everyone knows. I explained this more than once in GA queue. You can find the reasons over there.

This will not change until core will change. If you can get such a patch in core the module will follow core.

You must search in 5.x issues. The problem is to follow the postings is not easy as you must keep in mind how bad/broken the module was before 5.15. If you understood how it worked you may understand the questions. For example the module have not tracked anything by default. People have not understood (and me too) what the checkboxes are doing and asked very often how to configure the module to make it working/tracking anything. It was a mess to get it working. I cleaned up all this UI stuff, re-wrote many things and after this change the userinterface was understandable and worked how people expected it. The cases have dropped to zero. You are the first within ~2 years and this is also the reason why don't think it's important.

#248075: Tracking based on user and role specific settings
#258981: Documentation patch
#260367: Roles Opt-Out Sample PHP Script With Path Settings Functionality Preserved

#232841: role authenticated user selected
#134422: Allow certain roles to NOT be tracked

Always keep in mind - over 110.000 installations understand the current logic without asking how it works. Your code change will never go in as it simply flips the current logic - leaving 120.000 installations standing in the rain with an upgrade path. If something can go on it is a VERY GOOD user interface change that does not bring up one question to 1.000.000 people and have update hooks implemented if required and tests. You should carefully check out the code how roles, user and path logic interact. This is no trivial task.

The job is not done by writing exclude for add and flipping variables. You have not understood the issues. E.g Tod asks how he is able to get the module up and running. Usability was a mess in past. Others in the case confirmed the change is good. It may be best if you install 5.x 1.2 and try to understand how it worked and than try to understand how many possibilities you have with the current versions.

Only for the reason that I made a big mistake and have not implemented an upgrade path in past doesn't mean that I make such faults again. Finding users complaining about a missing upgrade path doesn't mean they do not understand the current UI. The number of installations have also grown by ~110.000 users from ~2000 and issues are nearly zero since the UI changes. Find one top 10 module with 4 open issues.

Please allow me to jump in.

First, thanks very much for the Google Analytics module. It is very useful.

My experience as a user of Drupal and Google Analytics is that configuration of Google Analytics would be more intuitive with the feature request as suggested by Ovocean if the patch in #2 works and I don't think it would reflect adversely with the user interface found elsewhere in Drupal.

The problem is well described in the opening post of this issue and I agree it is an obstacle to ease of administration. It would be far easier to do as suggested, since tracking can be on for all users, allowing selecting which roles to exclude.

Yes, there is a workaround, the php as linked to in #1. We have been using this for some time since we found it and were grateful for it. But it is a more advanced technique not suitable for ordinary administrators.

I must admit I don't fully understand the significance of the phrase "preserve the standard path filter functionality" and therefore don't understand why the user interface or user experience should be limited by it.

It would also be nice to be able to exclude user 1 from tracking.

As a side note, in the process of upgrading from 6.x-2.2 to 6.x-3.x-dev I found the php code caused errors in watchdog related to user 1.

Thanks,

Izzy

You can exclude user 1 and ever other user you'd like for years.

"You can exclude user 1 and ever other user you'd like for years."

I presume you mean using the role permissions and or the php to exclude roles and assign a role to user 1.

Yes, it has been possible to do this for years. It's more a question of what is the best way to make that available.

Thanks,

Izzy

NO. enable users are able to opt out and go to the user page, uncheck tracking. Every user with opt out permission can do this. You should spend 3 minutes with reading descriptions to understand the module or take a look to the screencasts. They are made for you.

hass, Yes, thank you I do understand granting user permissions to specific roles to configure opt out.

And I have read much of the documentation on this module in the two years I have used it. And have been able to use the workarounds provided to achieve the required results.

Thanks very much for all your work. But I find your remarks unnecessarily condescending. I've certainly spent way more than 3 minutes readings descriptions, issues and tutorials on this module.

Izzy

See http://www.brianstevenson.com/drupal/screencasts/installing-googleanalytics and you know how to opt out user 1. Reading and confuguring Drupal would have solved the issue, too. All interfaces in drupal works this way. If you are able to configure one you can all.

What are you not understanding regarding opt out?

My use case was similar to ovocean, I needed to exclude some roles from tracking, namely the administrator and developer. I thought it would have been nice if the UI check boxes had the option to exclude by role but they did not. I did not want individual users to do this. I installed the php script and that seems to do the job.

I wasn't entirely clear, with the php script in use, do the user permissions for all roles need to be set to "use php for track visibility" or is this just for the roles that need to be able to administer google analytics?

Thanks,

Izzy

The page A beginner's guide to using snippets may be a good starting point for you and PHP snippets can also help.

@hass

Thank you those are useful links and confirm what I am doing.

I am still not entirely clear on the user permission settings.

I initially presumed the item permitting users to "use php for tracking visibility" only needed to be checked for developers or administrators to make the necessary configuration changes. But on seeing the beginners video I wondered if this permission must be checked for all roles?

Thanks for your responses and patience,

Izzy

As i know this permission is only required for admins for configuration.

D7 first, than backport.

+	$visibility = variable_get('googleanalytics_vis_roles', 0);

There is a tab.

We also need tests.

Needs work for tests, tab and D7.

Not to take anything away from the clarifications on using php to track visibility provided by hass, which were helpful.

I have applied the patch in #20 to 6.x-3.x-dev without difficulty. This patch does not change the default functioning but provides the additional option to exclude specific roles. I think this patch makes the UI more intuitive for those who need to exclude certain roles.

The option "add to selected roles only" may need to be modified to remove the word 'only' to be in-keeping with the explanation provided below the check boxes.

Thanks,

Izzy

@Ovocean
I completely agree with you and with your patch. Actually I was planning to do same but for 6.x-3.0.

Just another brief comment on the patch.

Below the check boxes for roles, in the explanatory comment, it may be helpful to include "To exclude user1 assign an excluded role to user1."

Although, I still lean towards having a check box for user1 for simplicity.

Thanks,

@izmeez: Why are you still refusing to read and follow #13?

@hass I have read #13. It is again based on assigning permissions to a role in order to exclude user1. I understand the way YOU choose to do things. I have dealt with this myself for more than two years that I have been using this module, using the instructions in the various documentation. While I appreciate the module and find it very useful, I really do not understand your persistence in denying there may be ways to improve it. I do not understand your rigidity. YES, I have user1 excluded and have done so for over two years. I am just suggesting ways to make this clear in relationship to this patch.

I appreciate the module and find it very useful ALSO.

And I have read #13,but I agree with @izmeez about "having a check box for user1 for simplicity".

Also in module install for new sites the "exclude user1" check box should be checked by default.

Roles are groups of users and user 1 is only a single user and not a group. We do not write special cases only for user1 or any other user. The way how it's possible to exclude single users is perfect. The is no need to mix groups with users logic. This will not happen.

Hi, All
I think discussion is healthy thing for all of us.

@hass
when I agreed/proposed to add a check box for user1 I didn't say where it should be done. Actually I think the best place for that check box is under "User specific tracking settings"

Also the option "Do not track users by default, but let individual users to opt in." will give each other user the ability to disable tracking from himself to speed up page loading (I know it can be managed by "Permissions" ) But I think why make it complex while no need at all.

@Monzer Emam: Users cannot control whether they are tracked or not. may not the best default and we may be able to change this to Track users by default, but let individual users to opt out.. This is something I'm changing myself on really every of my sites. The reason for the current default is the default blocks visibility setting where the first radio is the default. Excluding user 1 or other individual users from tracking is something that will mostly be done on small sites (and path based exclusion too). Others may use a role or track only anonymous users. Bigger sites may not care about the few "user 1" clicks and this is also not wrong as these are clicks on your site. With the second item selected by default we may show the opt out checkbox in user settings and less beginners may find it quicklier without reading. The permissions behind are only logic - not every user should have permission to opt out and there are good examples why and when this makes sense. The permissions may look a bit strange if it comes to Do not track users by default, but let individual users to opt in., but it's only a logic consequence (nevertheless You may not need it) and will also catch all edge cases we could ever think about. I see no reason to remove functionality - edge case or not - we will find someone who will request these edge case. :-)

@Ovocean: We cannot help someone who have shown in more than one issue that he may not understand software or code at all and that he cannot read documentation and/or view screencasts. If he would - he would have opened a editor, have analyzed the code, found what he is doing wrong and than reported a usability issue - if it would really exists - maybe with an example how it could be made better. Cluttering translatable strings with unrelated descriptions is really the wrong way. I'm still trying to get a very small idea how someone can think that a "role" is a "user" - except you have upgraded from 5.x-1.3. I'm open to all possible usability issues, but not if people refuse to read setting "names" and their "descriptions" and cannot explain what they do not understand or what is not working and what they have configured as non-default. Sometimes you have very good and helpful reports and more often not so good or very bad. A module cannot be easier than GA - enter a Web Property ID and press Save and you are done! Yes, someone can missconfigure this module, but this cannot prevented at all if others like to have some good features. As always - reading is required - you will always have such users that cannot read or are doing everything wrong that can be done wrong.

In general I will not commit code that will clutter clean logic nor will I commit code that makes code unmaintainable as I need to maintain it on the end of the day. Open Source and Community is great, but there are mostly leachers that cannot develop code and I do not like to make code, descriptions or documentation illogical and unmaintainable only to make one person happy in a short view and confuse thousands of others. You cannot make everyone happy. I'm fine with 98.7% or more.

You may have missunderstood something - I'm not against new features - only for an intuitive and clean user interface for all features and not for making things more complex than they should be. And always keep in mind that you are also able to make text BOLD and it's nevertheless not read... this module is really much more fool-proof than hundreds of other modules.

PS: You patch could have already been committed, but without proper tests... How about not wasting time with OT complaining?

@hass, I like your module but I'm tired of your attitude. I think it gets in the way of people trying to contribute to the discussion and further understanding and improvements. Maybe someday I can buy you a beer and we can both see that we're really all trying to contribute for the common good.

@hass: Thanks for your time and your answers.And regarding your answer in #34
- I agree with you and since this issue is about roles I will make a new issue for user1 with new idea.
- Also I agree with you at #3 , But I hope you agree to agree with me to by pass "This will not change until core will change. If you can get such a patch in core the module will follow core."
As yes core should change And I will submit issue in this regards.

But for our module I propose a change like the image attached.

- may be @Ovocean patch need changes/test as just looked at the code and didn't read it fully or test it.

But is the new concept itself accepted from your side - still you are the one who will maintain the code end of day :).

I'm fine with the #24 patch, but I'd like to see automated tests for this.

.

.

Next release date is scheduled for 5. Jan 2011. Any chance to get tests?

Re-adding ignored patch

Previous patch will fail. Re-roled.

And fixed the description bug

CNW for tests.

Committed updated patches with tests.

[deleted]