@robocoder opened this Issue on August 9th 2010 Contributor

Superuser can define what a non-superuser can or can't do. Examples:

  • can change password
  • can change email address
  • can add/modify/delete sites (who already has at least admin access to one or more sites)
  • can add/modify/delete other users
  • can use token_auth with REST API
  • ...

(Some of this might overlap/conflict with the existing access sytem.)

Can be applied to an individual user or all users.

@anonymous-piwik-user commented on November 10th 2011

Attachment: Patch for SitesManager plugin. Now simple Administrators can add new sites to track.
SitestManagerPatch.txt

@gka commented on August 9th 2010 Contributor

By now it is only possible to allow or deny full viewing access to sites. Is it possible to limit the viewing access to certain plugins? This would be very helpful for anybody who likes to embed a single widget on a public page. Maybe we can introduce auth tokens that are limited to certain plugins?

@robocoder commented on August 9th 2010 Contributor

IIRC widget-specific access was discussed in #283.

@robocoder commented on July 31st 2011 Contributor

See Zend_Acl.

@mattab commented on November 3rd 2011 Member

Proposed settings to add in Piwik core:

  • Allow Admin users to create websites default
  • Allow Admin users to create other users default
  • Allow Admin users to see all other users (and assign permission) default - see #2028

See also #1148

@anonymous-piwik-user commented on November 10th 2011

Hello from Codax team, Russia. We'have just posted the patch for core for the 'SitesManager' plugin.

So it allows Admin users to create websites they wish to track.

Check out the attached file.

@anonymous-piwik-user commented on January 27th 2012

Hi,
I just want to support a more detailed permission system in which an admin is able to restrict view access.
In my case I want to deny view access to 'Ecommerce & Goals' for a specific user.

@robocoder commented on August 19th 2012 Contributor

Idea:

  • add an access table that defines menu layout and access to controllers (and optionally, individual actions):
class Access {
    int id;
    string name; (either plugin or plugin+controller)
    string action;
    string label; (for menu items)
    Access parent;
    priority int; (for ordering menu items)
    string authorization; (user defineable via a GUI)
} 
  • subscribe to FrontController.dispatch event; hook will pass through the request if authorization string is undefined (backward compatibility); returns 403 if authorization string is defined and user doesn't have authorization
  • core/Menu/* - check authorization before adding menu/submenu items
  • some of the existing checks would move into the Access table; remaining programmatic checks, such as Piwik::checkUserIsSuperUserOrTheUser(), will still have final say (for BC)
  • an Authorization service to encapsulate the isAuthorized() logic

administrative UI should manage:

  • access table
  • role assignment and hierarchy
  • menu access preview (by user or role)
@sebastianpiskorski commented on July 3rd 2015 Contributor

+1 on this one

Powered by GitHub Issue Mirror