Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

getUserPreference bug: "defaultReport" preference is "false" by default #3781

Closed
tsteur opened this issue Feb 27, 2013 · 7 comments
Closed

getUserPreference bug: "defaultReport" preference is "false" by default #3781

tsteur opened this issue Feb 27, 2013 · 7 comments
Assignees
@diosmosis
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Milestone
2.0.3

Comments

@tsteur
Copy link
Member

tsteur commented Feb 27, 2013

Hi,

I'm using the method "UsersManager.getUserPreference" via API to request a user's "defaultReport" preference. Depending on this I'll either display the "All Websites Dashboard" or the selected Website when a user opens the mobile app. Same behavior as in Piwik.

My problem:
After a fresh Piwik installation the API returns:

{value: false}

but should be:

{value: "1"}

Because Piwik behavior is to open first website after a fresh install and the value "Dashboard for a specific website -> FIRST WEBSITE" is selected by default in "User settings". Once I press "save" in "User settings" the API returns the correct value:

{value: "1"}

Is it possible to return the ID of the first website by default? Otherwise I'd have to implement a lot of stuff to workaround this and I'd have to do a lot of requests to make sure a website will be loaded.

API should always return either 'MultiSites' or an ID of a website.
@diosmosis
Copy link
Member

In 0e35cd6: Fixes #3781, make sure getUserPreference returns valid default value when option is not set in the DB.

@diosmosis
Copy link
Member

In 95dc8d9: Refs #3781, fixing build.

@diosmosis
Copy link
Member

In 5879fbd: Refs #3781, fixing build, revert last change and add getSuperUserLogin to Piwik_Access (so FakeAccess can mock it). Modified PDFReports to use Piwik::getSuperUserLogin instead of accessing config directly.

@diosmosis
Copy link
Member

In 24c2aa7: Refs #3781, revert change to unrelated integration test.

@tsteur
Copy link
Member Author

tsteur commented Jul 30, 2013

Is this really fixed? I just did a fresh install of Piwik and I'm still getting the response:

{value: false}

At least when using the Superuser. We also had such an issue in the current Piwik Mobile 2 beta test.

@tsteur
Copy link
Member Author

tsteur commented Oct 30, 2013

In 99a5f06: refs #3781 fix superuser default preference is not returned by default, probably also fixes some login issues in Piwik Mobile as it is requesting the getSitesIdWithAtLeastViewAccess to verify whether someone has access to at least one website

@tsteur
Copy link
Member Author

tsteur commented Oct 30, 2013

In 43fd0f0: refs #3781 fix test, defaultReport cannot return the website in case there is no website

@tsteur tsteur added this to the 2.0.3 - Piwik 2.0.3 milestone Jul 8, 2014
sabl0r pushed a commit to sabl0r/piwik that referenced this issue Sep 23, 2014
@tsteur
refs matomo-org#3781 fix superuser default preference is not returned…
99a5f06 
… by default, probably also fixes some login issues in Piwik Mobile as it is requesting the getSitesIdWithAtLeastViewAccess to verify whether someone has access to at least one website
sabl0r pushed a commit to sabl0r/piwik that referenced this issue Sep 23, 2014
@tsteur
refs matomo-org#3781 fix test, defaultReport cannot return the websit…
43fd0f0 
…e in case there is no website
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@diosmosis diosmosis

Labels
Bug For errors / faults / flaws / inconsistencies etc.
Projects
None yet
Milestone
2.0.3
Development

No branches or pull requests
2 participants
@diosmosis @tsteur