@peterbo opened this Issue on February 15th 2011 Contributor

A site admin should be able to disable referrer tracking in the settings menu.

  • a super admin can disable referrer tracking for the whole piwik instance
  • a site admin can disable ref tracking for a single site within a piwik instance
    What does make more sense?

Disabling referrer tracking causes:

  • remove referrer parameters from the tracker
  • UI: disable referrer Widget / menu entry / plugin for the piwik instance / single website
@robocoder commented on February 15th 2011 Contributor

Why? (isn't it already possible to deactivate the Referers plugin)?

@peterbo commented on February 16th 2011 Contributor

Good Point Anthon, didn't think of a solution which is so easy. ;) For me, this would be enough and we would not need another level of functionality -> CLOSED.

@mattab commented on February 17th 2011 Member

Disabling the Referers will not prevent the referer from being saved in the Goal table and Visit table, so it still requires a new setting to disable referer logging completely (ie. remove the urlref and _ref parameters)

@peterbo commented on February 17th 2011 Contributor

After having a talk again with the person in charge of the piwik study (regarding privacy concerns), we should assure that piwik won't store any referer information after the plugin has been disabled.

@robocoder commented on February 17th 2011 Contributor

I would like to roll all the privacy recommemdations (#2094 and #2095) and existing features (AnonymizeIP, OptOut, and DoNotTrack) into a single Privacy plugin, consolidating all the related settings into a single Admin screen.

@peterbo commented on February 24th 2011 Contributor

Good idea. That would increase the usability, comfort and consistency of the privacy configuration by far. +1

@mattab commented on February 24th 2011 Member

we should do this for 1.2, as it is very simple

@mattab commented on March 26th 2011 Member

vipsoft, OK for having a single Privacy plugin, with its own Settings page in Piwik. Also we have to expose the anonimize "number of bytes to remove" via the UI rather than the config file. Should we create a ticket?

@robocoder commented on March 26th 2011 Contributor

Yes, we should have a ticket that consolidates the specs for the new plugin.

With respect to #1552 (admin submenus), where would this fit in the proposed menu hierarchy?

Should we block on #1713 (config class refactoring)? We should remove AnonymizeIP from an existing config.ini.php during the update.

@mattab commented on March 27th 2011 Member

included this requirement in the new ticket at #2233

for the config file, 1713 is not required because the config file value is used for BC until the UI itself was used to configure. The UI, once it has been submitted once and the value found in option table, is overriding the config file value (I wrote this in the ticket), this is how we handled previous config file to UI conversions.

This Issue was closed on March 27th 2011
Powered by GitHub Issue Mirror