Publish container not working for user with write access & getting no success notification when creating a new version/ publishing a container

[tsteur]

• have a user with write and publish live permission

• With this user, edit a container that has custom templates
• Edit a tag (that doesn't have custom templates)
• Create a new version and publish release
• The version is created but there's no feedback that a new version has been created/published.
• I try to click again...
• Then I get an error that "The name is already in use" meaning the publish worked before.
• I open the screen with "Changes since last version" and can see that no changes actually have been published

• Neither do the published versions if an environment assigned (likely explains why the changes since last version always shows up)

This works as a super user. But for a user with write access.
Expected: Get a notification on success, close the modal, assign the correct environment, actually publish the container, (optionally reload the list of published versions to show the newly published version if that page was open previously

[snake14]

Thank you for taking the time to create this issue @tsteur . Can you please confirm that the changes were in fact not published. It appears that the changes were actually published, but the Matomo Configuration variables are showing as different (note the date is almost 2 years ago when there have been many releases since). I'm guessing that a migration didn't run correctly and it's showing as different because there's a new field which wasn't added to the previous version.

When I tested in my local instance, I didn't see the success notification, but the version was published as expected and the changes list was empty afterward.

We definitely need to look into why the success notification doesn't display. We might also want to look into an improvement related to the comparison issue as this keeps popping up when migrations are skipped or don't run correctly.

[tsteur]

@snake14 the publishing worked nicely with super user access. It was publishing with the write user but to no environment. So when I tried to publish to live again a 2nd time, it would show the same changes again.
By the looks the updates are executed. To be safe, I re-ran all updates and tested again and same issue

Published, then version without environment was released:

Then I click on publish again a 2nd time and same changes show up again

It seems the version entry is created, but not the release entry.

Looking at the request information there is an error:

Stack trace below. Looking at this stack trace and then the data there is Matomo tracking into site 3 configured, but this user does not have access to site 3 while the super user does have access to site 3. So publishing fails for this user. The container is configured in idSite 1. We use 1 container to track the data into 2 sites.

"You can't access this resource as it requires 'view' access for the website id = 3. #0 piwik/core/Access.php(564): Piwik\Access->throwNoAccessException('You can't acces...') #1 piwik/core/Piwik.php(608): Piwik\Access->checkUserHasViewAccess(Array) #2 piwik/plugins/SitesManager/API.php(296): Piwik\Piwik::checkUserHasViewAccess(3) #3 piwik/core/Site.php(79): Piwik\Plugins\SitesManager\API->getSiteFromId(3) #4 piwik/plugins/TagManager/Template/Variable/MatomoConfigurationVariable.php(87): Piwik\Site->__construct('3') #5 [internal function]: Piwik\Plugins\TagManager\Template\Variable\MatomoConfigurationVariable->Piwik\Plugins\TagManager\Template\Variable\{closure}('3', Object(Piwik\Settings\Setting)) #6 piwik/core/Settings/Setting.php(249): call_user_func(Object(Closure), '3', Object(Piwik\Settings\Setting)) #7 piwik/core/Settings/Setting.php(227): Piwik\Settings\Setting->validateValue('3') #8 piwik/plugins/TagManager/Model/Variable.php(118): Piwik\Settings\Setting->setValue('3') #9 piwik/plugins/TagManager/Model/Variable.php(81): Piwik\Plugins\TagManager\Model\Variable->formatParameters('MatomoConfigura...', Array) #10 piwik/plugins/TagManager/API.php(978): Piwik\Plugins\TagManager\Model\Variable->addContainerVariable('1', '71', 'MatomoConfigura...', 'Matomo Configur...', Array, false, Array, '') #11 [internal function]: Piwik\Plugins\TagManager\API->addContainerVariable('1', 'LllRPzcS', '71', 'MatomoConfigura...', 'Matomo Configur...', Array, false, Array, '') #12 piwik/core/API/Proxy.php(256): call_user_func_array(Array, Array) #13 piwik/core/Context.php(29): Piwik\API\Proxy->Piwik\API\{closure}() #14 piwik/core/API/Proxy.php(347): Piwik\Context::executeWithQueryParameters(Array, Object(Closure)) #15 piwik/core/API/Request.php(274): Piwik\API\Proxy->call('\\Piwik\\Plugins\\...', 'addContainerVar...', Array) #16 piwik/core/API/Request.php(591): Piwik\API\Request->process() #17 piwik/plugins/TagManager/API/Import.php(152): Piwik\API\Request::processRequest('TagManager.addC...', Array) #18 piwik/plugins/TagManager/Model/Container.php(260): Piwik\Plugins\TagManager\API\Import->importContainerVersion(Array, '1', 'LllRPzcS', 71) #19 piwik/plugins/TagManager/API.php(1180): Piwik\Plugins\TagManager\Model\Container->createContainerVersion('1', 'LllRPzcS', 34, '12', '') #20 [internal function]: Piwik\Plugins\TagManager\API->createContainerVersion('1', 'LllRPzcS', '12', '', 34) #21 piwik/core/API/Proxy.php(256): call_user_func_array(Array, Array) #22 piwik/core/Context.php(29): Piwik\API\Proxy->Piwik\API\{closure}() #23 piwik/core/API/Proxy.php(347): Piwik\Context::executeWithQueryParameters(Array, Object(Closure)) #24 piwik/core/API/Request.php(274): Piwik\API\Proxy->call('\\Piwik\\Plugins\\...', 'createContainer...', Array) #25 piwik/plugins/API/Controller.php(46): Piwik\API\Request->process() #26 [internal function]: Piwik\Plugins\API\Controller->index() #27 piwik/core/FrontController.php(645): call_user_func_array(Array, Array) #28 piwik/core/FrontController.php(169): Piwik\FrontController->doDispatch('API', false, Array) #29 piwik/core/dispatch.php(33): Piwik\FrontController->dispatch() #30 piwik/index.php(25): require_once('/Users/thomasst...') #31 {main}"

[snake14]

Thank you for the additional information @tsteur . It looks like the site permission is why we haven't run into this before. We'll have to look into the best way to fix publishing a container which tracks to a site that the publisher doesn't have access to.

[Stan-vw]

Just checking if I understand this correctly. The problem is:

1. Container is published but not on the right environment, meaning it doesn't have the intended effect
2. No success notification is shown (might be as a result of number 1)
3. This is relevant for Write users with Live Publish capability, for sites that the user does not have access to

If that's accurate and exhaustive, my question is: why should a user be able to publish to a website they don't have access to? I'm not really understanding this UX logic, I would imagine they shouldn't see this container in the first place.

[tsteur]

If that's accurate and exhaustive, my question is: why should a user be able to publish to a website they don't have access to? I'm not really understanding this UX logic, I would imagine they shouldn't see this container in the first place.

To clarify, the container is associated with a site the user can access. In Matomo, it's common to track data across multiple sites using a single container rather than setting up and loading separate containers for each site. This configuration means that while the container is set up in a site the user has access to, the user editing the container may not have permissions for all sites referenced by the container.

Because the user is only configuring a Matomo variable (specifically, setting an idSite) and cannot gain unauthorized access through this action, a permission check in this context is unnecessary.

[snake14]

Thanks @tsteur . That makes sense. I believe that the permission error is being thrown when the code is checking if the ID belongs to a valid site, but the Site class also checks permission at the same time. Maybe we can use a try/catch which only cares about whether the site exists and ignores potential permission errors in this specific case.