215.92 KB, image/png
245.78 KB, application/pdf
1.86 MB, application/pdf
797.32 KB, image/png
189.64 KB, image/png
The payment processor we're using for Basecamp will disperse money to developers via PayPal. In order to activate them for billing all we have to do is collect their PayPal ID.
Be careful with flipping existing flags here. We have a flag that disables PayPal and that hides PayPal from the frontend. We need to continue hiding PayPal like that because we are not using PayPal on the frontend for payments
Assignee: nobody → cvan
Target Milestone: --- → 2012-10-11
Assignee: nobody → amckay
Target Milestone: 2012-10-18 → 2012-10-25
from cvan: > we should add back the Payments step to submission > - payment type (free w/ in-app, paid up front, paid w/ in-app, my own payment system) > - price tier (and list the tier for each region as listed in mkt/constants/regions.py) > - ask for PayPal ID for bango > ask bram if you have questions about UX > after this you'll probably want to look at Bango implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=795103
> we should add back the Payments step to submission I disagree with that. Assigning to bram for mocks.
Assignee: amckay → bram
+1, let's let the UX mocks drive this
Writing down my thoughts for things I am going to do tomorrow: First, revamp the done page of the app submission flow so that it reflects the choice use had made. If user selected “paid”, then we say “now you can set up your payment”. If user selected “free”, then we say “sit back and relax!” The edit page sidebar should have the menu item that reads as follows: - Listing (under this, there will be a preview button to view listing) - Devices and payments - Authors (can we integrate this option into another page?) - Disable and delete (a better name for this?) The devices and payment page should have a free and paid tab, just like the app submission flow. We should add the option to select price tier, payment processor and in-app payment down below the device selection. Design is incoming.
Created attachment 677304 [details] app submission flow: done The “Done” step is redesigned so that it’s more informative and encourage developers to set their payment and author informations early on, rather than waiting for the review process to finish first. The design of the page might change further to incorporate more clickable buttons and readable list items. The items listed here are just starting list, formatted in a basic way.
Created attachment 677310 [details] edit app: devices and payment This is the “Devices and Payment” section of the Edit App interface. Notable things: * The page hierarchy is made consistent. The section is called “Edit App”, and the subsection, which is highlighted in the sidebar, is called “Devices and Payment” * Sidebar items have also been labeled more consistently, so it’s easier when read side by side * Device compatibility is listed by default, along with the “Free” and “Paid” tab, to reflect user’s selection on the app submission flow * User will be able to switch device compatibility and Free/Paid status around, but doing that will put the app back into the review process – so there’s a warning note about it * Price tier selection has been dramatically simplified. Rather than the Free / Premium / Free with in-app / Premium with in-app / My own payment provider radio buttons, we have one big drop-down menu that handles all prices * In-app payment can be enabled and disabled by clicking a checkbox – the mental model of an in-app payment here is a sort of “add-on” that you put on top and take out of an app * Payment account is selected the same way as you would if you’d select device compatibility ** Click the PayPal box ** The box is highlighted yellow, the other box is grayed out ** Enter an email address ** Click the authorize button How to set a free app with in-app payment: * Click the Tier drop-down menu * Select the option labeled “Free” (calling it “Tier 0” is jargony) * The price is free, but the paid option is selected above. Obviously, the app will still have payment of some form * So, the system will automatically check the “In-app payment” checkbox when user selects the “Free” label on the tier drop-down menu
Thanks bram, a few questions: - in app is next to price tier, which might imply that the two are related. That's not the case. In app payments will have to conform to carrier payment price tiers, but we don't really care what price tiers they use. The only reason we wanted to track an app using in app payments was so we can keep track of who is using in app payments and maybe show that to users. - payment account is the information we'll send to Bango, I'm not sure yet how we do that, if it's an API or an iframe. What if a paypal account already exists? - my own payment provider would be removed, not sure if that's relevant. It feels like there's a lot of stuff going on this page, will probably have more feedback when I've had time for it percolate in my brain.
Hi Bram. I like the simplification and new layout. Here are some minor points: - For in-app payments I don't think we need to collect the provider name if they decide to use their own provider. It's more like: dev_is_using_custom_provider: yes/no - As of a call with Bango today some details around paypal might change. It's possible that we will collect bank account info (or redirect to a Bango hosted page where that is collected. Ugh). Just a heads up, no decision yet. Assume paypal for now.
(In reply to Andy McKay [:andym] from comment #9) > - in app is next to price tier, which might imply that the two are related. > That's not the case. In app payments will have to conform to carrier payment > price tiers, but we don't really care what price tiers they use. The only > reason we wanted to track an app using in app payments was so we can keep > track of who is using in app payments and maybe show that to users. That was also my first thought
Not on-device - removing nom.
blocking-basecamp: + → ---
> - in app is next to price tier, which might imply that the two are related. > That's not the case. In app payments will have to conform to carrier payment > price tiers, but we don't really care what price tiers they use. The only > reason we wanted to track an app using in app payments was so we can keep > track of who is using in app payments and maybe show that to users. I had thought previously that in-app payment and price tier are related. They feel intuitively related, like one is supposed to think of them in order: first you decide whether your app is free or paid, then you decide if you want in-app or not. But maybe they are not related in the backend? > - For in-app payments I don't think we need to collect the provider name if > they decide to use their own provider. It's more like: > dev_is_using_custom_provider: yes/no > > - As of a call with Bango today some details around paypal might change. > It's possible that we will collect bank account info (or redirect to a Bango > hosted page where that is collected. Ugh). Just a heads up, no decision yet. > Assume paypal for now. Do we have a list of fields that Bango and PayPal would require, so I can prototype an interface that will suit it? I assumed that user would be able to connect with PayPal by simply entering his email address. The process looks a little something like this: * User enters his PayPal email address * A PayPal-hosted popup window will appear and authenticate that user with PayPal * User enters his PayPal password * User clicks a button that would authorize PayPal to receive money from Bango * The popup window closes * The manage payment page refreshes, the email field is filled in and blocked, indicating that the account is hooked up
(In reply to Bram Pitoyo [:bram] from comment #13) > > - in app is next to price tier, which might imply that the two are related. > > That's not the case. In app payments will have to conform to carrier payment > > price tiers, but we don't really care what price tiers they use. The only > > reason we wanted to track an app using in app payments was so we can keep > > track of who is using in app payments and maybe show that to users. > > I had thought previously that in-app payment and price tier are related. > They feel intuitively related, like one is supposed to think of them in > order: first you decide whether your app is free or paid, then you decide if > you want in-app or not. But maybe they are not related in the backend? price tiers are for buying your app. So: first you decide if it's free or paid, if it's paid, what price tier do you sell it at? In-app payments are different
Created attachment 679059 [details] edit app: devices and payment - design variations Design variations on the devices and payment step. When evaluating the layouts, consider: * Do we want to link to articles about price tiers, in-app payments, etc.? * Do we want to inform users that support for other payment providers is coming? * Will big text size aid comprehension or just clutter up space? * Can we expect that user is going to know what he wants to do at this point, so we don’t have to be very verbose and hand-holding?
I'm not a fan of lots of different font sizes myself. Other opinions may vary. It might worth noting that other actions may cause the app to go back into the rereview queue, for example altering from free to paid, or vice versa. Perhaps the form should see if the changes would trigger a rereview and show a confirmation dialog at that point?
The varying font sizes are disorienting for me too. But this looks good. And are we removing upsell?
Bram, thanks for showing off the iterations. I'll email you some thoughts and leave it to you to make the final decision.
Created attachment 679979 [details] edit app: devices and payment I choose to go with this option, where: * Text sizes don’t vary a lot * They have hierarchy, so you know the order of information to look for * Emphasis is marked bold * Captions and help links are set smaller than the rest of the text (In reply to Andy McKay [:andym] from comment #16) > Perhaps the form should see if the changes would trigger a rereview and show > a confirmation dialog at that point? There’s a red button up there that will alter device compatibility and payment type. It will mirror the tab we use in the submission flow (where we have “free” and “paid” with a list of devices underneath). Clicking on this red button will allow developer to change his paid app back into free. Free here means “totally free”, because “free with in-app payment” is still considered “paid”. There’s a caption to the left of that red button that says that the app will go back into the review queue if developer clicks it. So I feel like this covers that situation. However, you may be thinking of the case where developers alter the price for promotion. For example, an app will start out free for the first one week, and then the price will move up to $0.99. In this case, would the app need to go to a re-review? Or, because the app status is already marked as “paid”, it doesn’t need to be reviewed again? (In reply to Chris Van Wiemeersch [:cvan] from comment #17) > And are we removing upsell? Could you clarify what you mean by upsell? I might’ve missed it on the old interface.
Depends on: 810283
Depends on: 810286
FYI, we just had a meeting with the payment provider about what the sign up process will be like. We will likely need to extend this UI, I'll let you know when we have more info.
(In reply to Bram Pitoyo [:bram] from comment #13) > Do we have a list of fields that Bango and PayPal would require, so I can > prototype an interface that will suit it? So far, this is what Bango needs us to collect in addition to PayPal email: - administrative email - support email (we already have this) - financial email -- where finance related communication goes - vendor name - company name - address: line 1, line 2, city, state, post code, country - phone - fax (optional) - VAT number (optional) - preferred payout currency. Options: USD, EUR, GBP I just got wind of this as I checked out the API calls. Some of these we probably already collect. If we think we don't need some of these we could ask Bango about them. Also note that we may require bank account details instead of (or in addition to) paypal. There is still a lot of details to work out about that. We should assume PayPal for now, at least to get started.
Per bug 807871 - which I'm making now part of this bug - please remove the "Device Types" checkboxes from "Edit Listing" since they're already covered on this "Devices and Payments" page.
(In reply to Kumar McMillan [:kumar] from comment #21) > So far, this is what Bango needs us to collect in addition to PayPal email: There are a lot of fields here. Maybe we should adapt the design of the Edit Details step to use in this page? I also wonder if Bango will be able to get some of the information from PayPal? For example, I know that PayPal does address verification, and note user’s phone number. That way, user will only need to fill in currency, VAT number, fax, vendor and company names, and the various email addresses. The other thing that will be nice to have here is an example of how other vendors have implemented Bango’s payment system. For example, both Google Play Store and Facebook are powered by Bango. Can we see an example or screenshots of what the developer payment setup flow looks like in these environments?
I think for now, we'll have to collect all the fields I listed above. Otherwise, we'll have to wait for custom dev from Bango to adjust their API
Thanks for confirming, Kumar. This is what I need to start designing.
Created attachment 681898 [details] payment form UX Attached is a low fidelity mockup of how the payment forms are structured and should behave. Notable things: * Form elements are revealed progressively, not all at once, in this order: 1. Price tier menu and in-app payment checkbox 2. PayPal email 3. Currency 4. The rest of the forms PS. Different countries/state and VAT are auto selected depending on the currency * After PayPal email authentication, the “Authenticate” button is replaced with an “Edit” button, with a warning text besides it * After form completion and submission, the “Submit” button is replaced with an “Edit” button, with a warning text besides it * When editing, a “Cancel” button appears to the right of the “Edit” button so user can call off the change that he is making
Hey Bram, this looks great! Thanks. I was initially confused by vendor vs. company so I asked for clarification from Bango. This is what they said: The company name – is the registered legal entity of the business Vendor name – is the trading name for the business. So for Bango it would be: Company name = Bango.Net Ltd Vendor name = Bango
Bram, we can actually skip the PayPal email authorization step. It can simply be a text box with an email. What will happen is we will submit the data on the backend using the Bango API and their API server will verify the PayPal email. If it's incorrect we'll receive an API error just like any other error such as an invalid VAT code.
Do these payment flows rely on people setting up payments again for every app? If I've already set it up once for an app, do I have to do it again every time for each app? Although its for Paypal, I think the arguments here stand bug 694699. Having to do it every time for every app sucks. In some earlier mocks we had the ability to chose an existing payments profile I've made. I'm unsure if this choice will exist with Bango, but if it does, I think we should use it as it would make life much, much easier. The QA team and the developers of the API would love you too.
(In reply to Andy McKay [:andym] from comment #29) > In some earlier mocks we had the ability to chose an existing payments > profile I've made. I'm unsure if this choice will exist with Bango, but if > it does, I think we should use it as it would make life much, much easier. > The QA team and the developers of the API would love you too. Can we confirm whether the ability to set up payment information once and use it multiple times rests with Bango, or with us? I was not aware that user can choose payment profiles in earlier mocks. They must’ve been implemented before I came into the project? Payment profile is a great feature to implement! But I wish that I would’ve seen the earlier mockups, so I could start from that rather than mocking something up from scratch. Is there a a page on the dev server that you could point me to? Structure-wise, I think that payment profile should not be placed inside the app management page, but maybe inside profile (keep in mind that user profile ≠ developer profile, so this could create confusion, and we must tread carefully).
Created attachment 683530 [details] payment form UX - 02 The payment form UX has been updated with: * More consistent button placement: always on the left side of the form * Caption on the side of every button that will trigger app re-review * Button that will trigger app re-review is marked with a different color This update does not cover: * Payment profile setup page/flow * The fact that we don’t need a separate “Authenticate” button for PayPal email Is there a Bango-powered flow in another website that I can look at as an example? My flow seems tedious to go through. Having reusable payment profile will help, but I think that the real solution is reducing the number of form text boxes. If there’s another site with a form implementation that we can learn from, it’ll help me.
Attachment #681898 - Attachment is obsolete: true
Created attachment 684309 [details] payment form UX - 03 - separate editing Based on Andy’s comment 29 and my discussion with Cvan yesterday, the payment form UX has been updated with these features: * Interface for adding and managing payment accounts * Editing price tier is separated from editing payment accounts. Meaning, both has its own “Submit” button This mockup is 1 out of 2 design variations.
Attachment #683530 - Attachment is obsolete: true
Created attachment 684310 [details] payment form UX - 03 - integrated editing This mockup is number 2 out of 2 design variations, where everything is the same as the last design variation (attachment 684309 [details]), except for this feature: Editing price tier is NOT separated from editing payment accounts. Meaning, both fields share the same button.
Created attachment 684322 [details] payment form UX - 03 - review states When the user’s edit is under review: * The edit button is disabled * The button title becomes “[button_title] saved” and rests in a disabled state * The caption to the side of the button becomes “Under review” * User can’t edit until that specific bit has been reviewed
This is a big improvement thank you. A couple of notes: * In a meeting with Bango it sounds like viewing and editing bank details is not an option. From what I gather people will just have to enter them again. * If people are giving bank details, then the paypal email address isn't used or needed at all. Using it as the key to the payment details won't work. Perhaps account nickname or something is needed (especially since people can't see the settings for that account) * It has price tier and in-app payment next to each other. I'm not sure it's clear what the price tier is for from that. Perhaps something that says "sell your app on the marketplace" header is needed. Since it's directly next to in-app payment users might guess its for that. * If the app is wanting in-app payments or to be sold on the marketplace we shouldn't let the form complete until they've added a payment source. * It looks like you can remove payment sources, which is cool. Just so you know, I don't think we can (and should) ever delete that data for legal and transactional issues. We can stop it from ever showing up on the form for a user. Not sure if that's worth noting in the UX, probably not.
Created attachment 685047 [details] payment form UX - 04 The payment form UX has been updated with these notable things: * Added help links to cover inbetween use cases, below the “Free” tab * Payment account setup and edit form is redesigned * It’s now possible to set up both PayPal and bank payment accounts * The order of fields now goes from smallest (address) to biggest (country) * Added help links for currency, company/vendor names, and financial/administrative emails Optional reading: more details can be found below. (In reply to Andy McKay [:andym] from comment #35) > * In a meeting with Bango it sounds like viewing and editing bank details is > not an option. From what I gather people will just have to enter them again. The ability to view and edit bank details has been removed. > * If people are giving bank details, then the paypal email address isn't > used or needed at all. Using it as the key to the payment details won't > work. Perhaps account nickname or something is needed (especially since > people can't see the settings for that account) I propose using a combination of account holder name + account number to identify bank account. So it would look something like: John Smith (12-XXXX-XXX345-00) To identify PayPal accounts, we can use email, as usual. > * It has price tier and in-app payment next to each other. I'm not sure it's > clear what the price tier is for from that. Perhaps something that says > "sell your app on the marketplace" header is needed. Since it's directly > next to in-app payment users might guess its for that. The header might be a good idea. I put it on the mockup. Keep in mind that the “Paid” tab is already selected at the top of this page. The tab was also selected at the start of the app submission process. But I understand that the whole thing is a bit confusing. The root cause of this problem is the fact that not every platform can have paid apps. On one hand, we have this disparity of feature. But on the other, we still want to let users know that one app can work on any device—as long as it’s free. So we needed to clarify what devices support free apps, and what devices support paid. The “Free” and “Paid” tabs were designed to help organize this. The confusing bit comes in the inbetween situations. For example: * When a free app has in-app payment. It belongs under the “Paid” tab because it is only available for Firefox OS, but then the price is “free” * When an app starts out with a promotional price of free, but is going to be made into a paid app at some point. It belongs under the “Paid” tab, because it’s going to be paid and the developer is going to accept payment eventually, but the actual price at the moment is free. To help clarify and avoid confusion, let’s put two links that will answer these two use cases on the “Free” tab, right underneath device compatibility. > * If the app is wanting in-app payments or to be sold on the marketplace we > shouldn't let the form complete until they've added a payment source. Agreed. Whenever in-app payment box is checked, the form shouldn’t complete until a payment source has been selected.
Summary: Allow developer to set up payments using PayPal → Allow developer to set up payments for Bango
I would love to get a feedback on this bug: whether the UI—which has grown more complex since v1’s mockup—have satisfied the feature requirement. The next step on this is visual design, which I can help start, too.
Hi Bram. We are ready to implement your UI in the devhub! Matt Basta is working on it this week and can ping you if he has questions. One thing to note: We will not be supporting PayPal, only bank accounts. The change here is that we will not need the radio button for PayPal, it will just default to bank account. If you'd like to update the mocks for then go ahead but I think that should be a straight forward change for Matt to make.
Assignee: bram → mattbasta
Priority: -- → P1
Target Milestone: 2012-11-22 → 2012-12-06
Matt, the docs for the Solitude API to register developers with is still in progress -- https://solitude.readthedocs.org/en/latest/topics/bango.html -- so ping Andy or me or check out the code in the resources module: https://github.com/mozilla/solitude/tree/master/lib/bango/resources The package and billing endpoints are the ones to use. Hopefully by the time you've started on the UI part we'll have some more docs for you.
https://github.com/mozilla/solitude/blob/master/samples/bango-basic.py is the best docs :)
A few questions that don't require immediate answers: - Bram: there's no phone number field for the payment account setup. Should I add one? - The "Country" field is a dropdown. Do we have a list of countries which we can populate it with? Or should I just make it a textbox?
(In reply to Matt Basta [:basta] from comment #41) > - Bram: there's no phone number field for the payment account setup. Should > I add one? Phone number does seem to be required for registration. In the API docs it is marked as optional but in our tests it is actually required. > - The "Country" field is a dropdown. Do we have a list of countries which we > can populate it with? Or should I just make it a textbox? Matt, in the appendix of the Mozilla Exporter API docs  you'll find a list of supported country codes.  https://wiki.mozilla.org/Apps/ID_and_Payments#Mozilla_Exporter_API
Another issue: upsell isn't in the mockups. To respond to your request for clarification of what upsell is: http://cl.ly/image/2R2P3K1f2n1i Basically, it links your app with another app and marks your app as the "premium" version: http://cl.ly/image/2L2b1U460d2Z
Can someone also please confirm my "personal glossary"? - package == developer - bankdetails == payment account - bango number == app Questions for andym/kumar since everyone seems to be offline: - I'm ready to pass the account details to solitude. I'm assuming they go to /bango/bank. That endpoint takes a 'seller_bango' field. Is this already generated or is this something that I'm going to have to generate when the user flips their app to Paid? - The mocks call for a list of bank accounts (both for managing the account list as well as choosing the account to tie to the app). I could be mistaken, but there doesn't seem to be an endpoint for this in Solitude. - There seems to be some discontinuity surrounding the fields for the bank account. The bank details API requires some more information (bank name/address/zip/country). - The package API requires a paypal and support email, as well. As far as the extra required fields goes, I can just add those in no problem. OTOH, how do you want me to deal with fields that are split across the package (developer) and bank details (payment account)? Should I register one package per payment account (this seems dirty)?
(In reply to Matt Basta [:basta] from comment #44) > Can someone also please confirm my "personal glossary"? > - package == developer > - bankdetails == payment account > - bango number == app Yup. At this time, we figure if you want a different package, you can set up another account. That's sub optimal, but works for the moment. > Questions for andym/kumar since everyone seems to be offline: > > - I'm ready to pass the account details to solitude. I'm assuming they go to > /bango/bank. That endpoint takes a 'seller_bango' field. Is this already > generated or is this something that I'm going to have to generate when the > user flips their app to Paid? There won't be any information in solitude. So you are going to have check that the information exists or not in solitude and populate if not. It looks like the data in that form is a combination of data of multiple calls, bank, package and product. > - The mocks call for a list of bank accounts (both for managing the account > list as well as choosing the account to tie to the app). I could be > mistaken, but there doesn't seem to be an endpoint for this in Solitude. Right. So we are assuming that a user will only have one set of Bango details at this point. When we add in more payment providers however you might be able to choose between Bango and Paypal. When I've added in a second paid app, being able to select your Bango account will avoid you having to set it up again. > - There seems to be some discontinuity surrounding the fields for the bank > account. The bank details API requires some more information (bank > name/address/zip/country). Bango is definitive. > - The package API requires a paypal and support email, as well. Yeah. We not sure what to do about PayPal. We should file bugs on these. > As far as the extra required fields goes, I can just add those in no > problem. OTOH, how do you want me to deal with fields that are split across > the package (developer) and bank details (payment account)? Should I > register one package per payment account (this seems dirty)? Yep you got it. Kumar will correct my inaccuracies ;)
(In reply to Matt Basta [:basta] from comment #43) > Another issue: upsell isn't in the mockups. > Basically, it links your app with another app and marks your app as the > "premium" version The solution you linked to seems to work well for upselling apps. I think that we should put it to the side or below the “In-app payment” checkbox. I am trying to determine if the relationship between free and premium app is one-to-one. For example, can one free app have multiple premiums? Can one premium be linked to from many free apps? Or is it exclusively one free app per one premium app? I am also trying to determine if the upsell happens both ways. For example, when user views the free app, the page will say “Premium version available”. So when user views the paid app, will we say “Free version available”?
(In reply to Andy McKay [:andym] from comment #45) > (In reply to Matt Basta [:basta] from comment #44) > > - The package API requires a paypal and support email, as well. Just assume we're not using paypal right now. If you get API errors then that's a bug in the API. You could put firstname.lastname@example.org or whatever while we're waiting for them to fix it. As for support, we already have that in Marketplace (collected from the app submission page)
Created attachment 691654 [details] devices and payment page - visual design Attached is the visual design for the page where the payment form (and the device compatibility) is located, as well as the edit mode for each.
This is what we've got right now: http://cl.ly/image/1T0j2v3z3L00 The upsell form is a little cut off, though.
Created attachment 691686 [details] add new payment account (popup window) - visual design This is the visual design for what would happen if user clicks on the “Add or manage payment accounts” link on attachment 691654 [details].
(In reply to Matt Basta [:basta] from comment #49) > This is what we've got right now: > > http://cl.ly/image/1T0j2v3z3L00 > > The upsell form is a little cut off, though. What we got right now looks fine to me! I just thought that I needed to make the edit interaction the same with the rest of the pages. But the big issue is to get the feature working rather than refining the UX. Thanks, Matt!
https://github.com/mozilla/zamboni/commit/7ed7ea869a6d3bf8028c1456446fdb32b5a9ed45 (dev reg) https://github.com/mozilla/zamboni/commit/fd3e5698deedc2b3e4172058aa8236715b9a90c0 (removes old code) Thanks Basta! There are some loose ends to tie up, more bugs on the way for that.
Assignee: kumar.mcmillan → mattbasta
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
There's a problem here in how bango products are created. The package ID is not passed to Solitude (which may also require a tweak to the zamboni model). I'll take it.
Assignee: mattbasta → kumar.mcmillan
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The model has been fixed and it's working on dev now. https://github.com/mozilla/zamboni/commit/0111a1c93345dc52d9b3c02d2e837ca6c4226c12
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → FIXED
This still isn't working with the Bango API right. I have fixes here but I'll land them after the holiday. Happy Xmas all! https://github.com/kumar303/zamboni/compare/seller-uuid
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 2012-12-20 → 2012-12-27
Fixed. https://github.com/mozilla/zamboni/commit/d5fcfd99811724530b8bf9e6f385dfd3d0ea14a8 https://github.com/mozilla/zamboni/commit/2c150cdbcc13d8fb84740e3acd5ad1592472509e
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.