Closed Bug 960078 Opened 10 years ago Closed 10 years ago

Call to Set_Storefront_Data API

Categories

(Marketplace Graveyard :: Integration, defect, P1)

Product:
Marketplace Graveyard
Component:
Integration
Version:
Avenir
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2014-01-21

People

(Reporter: dkassack, Assigned: robhudson)

References

Details

(Whiteboard: [qa-]) 

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Safari/537.36




Expected results:

Mozilla has several ratings posted on the Marketplace and the IARC system has not received a call to the Set_Storefront_Data API.  This is supposed to be done for every posted rating.

https://marketplace.firefox.com/app/whos-that-pokemon?src=search

https://marketplace.firefox.com/app/kanatrainer?src=search

https://marketplace.firefox.com/app/zmaps?src=search
Sorry if I did something incorrectly, this is my first bug post.
Component: Firefox Operations → Integration
Product: Tracking → Marketplace
Version: --- → Avenir
You did well. :)
Assignee: nobody → kngo
To be clear, the SET_STOREFRONT_DATA call should be triggered in the following situations:
1) a new app with a rating is released
2) app is pulled from the marketplace (call with blank Rating Release Date)
3) already released app has the following storefront information updated:
 a) rating change (rating category, descriptors, interactive elements). Also when rating pulled.
 b) title change
 c) company name change
 d) target region added/deleted resulting in addition/deletion of rating type, i.e. ESRB, PEGI, CLASSIND, etc.  For example, if an app release only in US, expands the regions to include UK, Greece and Italy, there should be a call to SET_STOREFRONT_DATA for the PEGI rating entry.
Blocks: 929812
Assignee: kngo → robhudson.mozbugs
Priority: -- → P1
The 3 apps mentioned in comment 0 were already published and approved prior to the IARC ratings going live.

I confirmed that we are calling SET_STOREFRONT_DATA at app approval time.

I think the bug here is that we're not calling SET_STOREFRONT_DATA in some of these other cases. For the referenced apps the case would be that the developer added a rating to their already approved app.

I suspect 3a-d are not accounted for.
Thanks Rob.  Is there anything that can be done for this?  Many legacy (already released) apps are going to be rated by the 4/15 deadline.  It will be important for those to be included in our data.
(In reply to David Kassack from comment #5)
> Thanks Rob.  Is there anything that can be done for this?  Many legacy
> (already released) apps are going to be rated by the 4/15 deadline.  It will
> be important for those to be included in our data.

Yes. I'm going to focus on the one I consider most common first, which is an app getting a content rating when the app is public.

Then work on the other scenarios after that.
David: Should we be concerned if we inadvertently call SET_STOREFRONT_DATA multiple times for the same app? What happens on the IARC side of things?

In our code whenever we make this call we use the current day for "release_date". We should probably update that to use the app approval date instead. I think when this was written the focus was that this is called when the app is approved.
SET_STOREFRONT_DATA can be called as often as you like.  If the unique SubmissionID/RatingSystem/Platform/Storefront record is found, it is updated.  Otherwise, a new record is added with the sent info.

And, yes, the "release_date" value refers to the date when the app was first made available on the marketplace.
Rob,

Every unique pairing of app and storefront has a single release record in the system. If the SET_STOREFRONT_DATA web service is called multiple times, the release date is overwritten by each subsequent call. This allows for any corrections that need to be made and allows for a blank date to be sent to "unreleased" an application. So,multiple calls won't cause any specific issues, but we will have the most recently sent date as the release date.

I hope that clarifies.

Christine
This will catch already approved apps who get a content rating:
https://github.com/mozilla/zamboni/commit/2c98ab2 

I'll continue to work on the other use cases before closing this bug and update as I go. Thanks.
Rob, it sounds like you're making quick work of this, we appreciate it. Is there something we can do about getting the calls made for the apps that already have ratings on the Marketplace?
(In reply to Christine McCarthy from comment #11)
> Rob, it sounds like you're making quick work of this, we appreciate it. Is
> there something we can do about getting the calls made for the apps that
> already have ratings on the Marketplace?

Given a list of apps we could call SET_STOREFRONT_DATA manually for now until these patches land on our production machine next Tuesday.
(In reply to Rob Hudson [:robhudson] from comment #12)
> (In reply to Christine McCarthy from comment #11)
> > Rob, it sounds like you're making quick work of this, we appreciate it. Is
> > there something we can do about getting the calls made for the apps that
> > already have ratings on the Marketplace?
> 
> Given a list of apps we could call SET_STOREFRONT_DATA manually for now
> until these patches land on our production machine next Tuesday.

I can provide a list from our database of all of the submissions made since go live including Submission IDs and Titles. Some of them look like tests, some like duplicates. And as our ratings department has looked around, they've only found a subset of these to be showing any rating at all on the Marketplace at this time. But we have no way on our end of knowing which applications are "released" in the sense of actively displaying ratings without visiting each one. Would the full list help you?
(In reply to Christine McCarthy from comment #13)
> I can provide a list from our database of all of the submissions made since
> go live including Submission IDs and Titles. Some of them look like tests,
> some like duplicates. And as our ratings department has looked around,
> they've only found a subset of these to be showing any rating at all on the
> Marketplace at this time. But we have no way on our end of knowing which
> applications are "released" in the sense of actively displaying ratings
> without visiting each one. Would the full list help you?

I think, more simply, we can run a script to call SET_STOREFRONT_DATA on all apps that have a rating and are public. They may get called on apps who have already called it but it sounds like that's not a problem
(In reply to Rob Hudson [:robhudson] from comment #14)
> (In reply to Christine McCarthy from comment #13)
> > I can provide a list from our database of all of the submissions made since
> > go live including Submission IDs and Titles. Some of them look like tests,
> > some like duplicates. And as our ratings department has looked around,
> > they've only found a subset of these to be showing any rating at all on the
> > Marketplace at this time. But we have no way on our end of knowing which
> > applications are "released" in the sense of actively displaying ratings
> > without visiting each one. Would the full list help you?
> 
> I think, more simply, we can run a script to call SET_STOREFRONT_DATA on all
> apps that have a rating and are public. They may get called on apps who have
> already called it but it sounds like that's not a problem

Based on the web service log in the database, there hasn't been any call to SET_STOREFRONT_DATA yet, so as far as we know, all apps still need a call. Is there a way we can, maybe daily, make sure a call is made for any new apps between here and the patch on Tuesday?
Rob, I know you are planning to make a manual call to SET_STOREFRONT_DATA for all of the current apps with a rating public. Since those calls haven't been made yet (I encourage you to begin making them as soon as possible) I wanted to warn you that some of the Rating Boards have been actively checking the Marketplace for your ratings and have begun issuing rating changes where they feel necessary. Since these changes are being issued on products that have not been "released" (by the SET_STOREFRONT_DATA call), the GET_RATING_CHANGES call will not report them. However, when the SET_STOREFRONT_DATA call is made, the response XML will contain the change. I encourage you to watch for these differences, make the appropriate changes, and re-call SET_STOREFRONT_DATA to indicate the the product is now released the with the correct information. In general, we recommend that Storefronts watch for the return data from SET_STOREFRONT_DATA to indicate any possible changes that need to be made, though they should be few and far between when the SET_STOREFRONT_DATA call is being made at the time of release. Thanks!
(In reply to Christine McCarthy from comment #16)
> Rob, I know you are planning to make a manual call to SET_STOREFRONT_DATA
> for all of the current apps with a rating public. Since those calls haven't
> been made yet (I encourage you to begin making them as soon as possible) I
> wanted to warn you that some of the Rating Boards have been actively
> checking the Marketplace for your ratings and have begun issuing rating
> changes where they feel necessary. Since these changes are being issued on
> products that have not been "released" (by the SET_STOREFRONT_DATA call),
> the GET_RATING_CHANGES call will not report them. However, when the
> SET_STOREFRONT_DATA call is made, the response XML will contain the change.
> I encourage you to watch for these differences, make the appropriate
> changes, and re-call SET_STOREFRONT_DATA to indicate the the product is now
> released the with the correct information. In general, we recommend that
> Storefronts watch for the return data from SET_STOREFRONT_DATA to indicate
> any possible changes that need to be made, though they should be few and far
> between when the SET_STOREFRONT_DATA call is being made at the time of
> release. Thanks!

Hi Christine,

Thanks for the note. We did run a big batch yesterday. There were roughly 184 apps that got picked up and called SET_STOREFRONT_DATA. Did they come through?

Just so I understand... If we miss the response from SET_STOREFRONT_DATA with changes we'll still pick those changes up via GET_RATING_CHANGES, correct? I'll have to verify but I don't think we are calling SET_STOREFRONT_DATA if we find changes in GET_RATING_CHANGES, however.

This bug is getting big. I may spin off a few new bugs to this.
Rob, I am not showing any SET_STOREFRONT_DATA calls in our log and I don't have any release dates in our system. Are you storing the responses from the calls? Maybe we need to debug an error message?

Regarding the GET_RATING_CHANGES call: You can, at any time, make a call to this service with any start and end dates you wish. I noticed that your daily calls use the previous day to the current day (which makes good sense). Here's the situation: If the app that was changed on the 14th isn't released when the call is made on the 15th, GET_RATING_CHANGES will not report the change. If the service is never called for the 14th again (as the call on the 16th will be for the 15th), the change on the 14th will never be reported, even after it is released on a later date. So in the case where a Rating Board has made a change prior to the SET_STOREFRONT_DATA call releasing the product (by a period of a day or more), you may miss the change in GET_RATING_CHANGES. If, for this manual move, you want to run a GET_RATING_CHANGES call after all of the SET_STOREFRONT_DATA calls, with dates encompassing all of the time since go-live, you should get all changes at that point. I hope that clarifies.

Regarding calling SET_STOREFRONT_DATA again when changes are found: The data you submit when SET_STOREFRONT_DATA is called is stored and used to create a difference report which allows the Rating Boards to reach out to you if the report indicates that you are displaying an incorrect rating/descriptor/title/etc. By sending a second call updating our information when you've acknowledged and implemented a rating change, you clear that difference from the report.

Sorry this has gotten complicated. We are actively reviewing the conversations we're having here and updating our documentation to help make this easier in subsequent implementations with other storefronts.
On a hunch, I checked our DEMO database to make sure your calls hadn't gone there. I saw 3 SET_STOREFRONT_DATA calls in the DEMO system on 1/15. But, based on what you said, I'm guessing you tried to send a larger set than that, so those probably aren't your calls. Let me know if they might be and I can give you more details.
I filed bug 961179 to handle the responses from SET_STOREFRONT_DATA better.
https://github.com/mozilla/zamboni/commit/555a10d

This commit handles when the developer updates their manifest resulting in either an app name change or a developer name change (aka "company"). Either changes will not result in a SET_STOREFRONT_DATA call.
https://github.com/mozilla/zamboni/pull/1653

This commit handles when the developer gets a rating through the GET_APP_INFO service.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2014-01-21
Can you please add some STRs to this bug or mark it as [qa-]?
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.