Hightail has expressed a desire to stop recruiting users through Filelink. Their contract allows them to do that with 3 months notice. Business arrangements still seem to be underway, but until further notice, I believe we want to do the following: 1) Remove Hightail from the list of Filelink providers offered for users to set up 2) Remove the ability for users of the Hightail free account to upgrade to the paid account.
4 years ago
Attachment #8507114 - Attachment is obsolete: true
Comment on attachment 8507115 [details] [diff] [review] Freeze current set of Hightail users. r=? This patch: 1) Blacklists Hightail from the list of providers one can add to Filelink 2) Removes both upsell options when uploading a file > 50MB, or exceeding quota. We simply show error messages in either of those cases. I'm... I have no idea who should review this. Maybe Magnus? I only tested this patch on OS X, I'm afraid.
Attachment #8507115 - Flags: review?(mkmelin+mozilla)
Also, I was unable to run the cloudfile Mozmill tests by themselves. jcranmer, have we completely lost mozmill-one capabilities? My objdir is a sibling folder to my srcdir, and I ran this from my objdir: make SOLO_TEST=cloudfile mozmill-one and got: unset PYTHONHOME && cd ./_tests/mozmill && MACOSX_DEPLOYMENT_TARGET= \ /Users/mikeconley/Projects/objdir-tb/_tests/mozmill-virtualenv/bin/python runtest.py \ --test=/Users/mikeconley/Projects/comm-central/mozilla/../mail/test/mozmill/cloudfile \ --binary=../../dist/Daily.app/ \ --symbols-path=/Users/mikeconley/Projects/objdir-tb/dist/crashreporter-symbols \ --plugins-path=/Users/mikeconley/Projects/objdir-tb/dist/plugins \ Using profile dir: /Users/mikeconley/Projects/objdir-tb/_tests/mozmill/mozmillprofile Could not find the Mozilla runtime.
(Resolved over IRC)
Comment on attachment 8507115 [details] [diff] [review] Freeze current set of Hightail users. r=? Review of attachment 8507115 [details] [diff] [review]: ----------------------------------------------------------------- Sorry for the delay, this looks good to me. r=mkmelin with the below fixed ::: mail/locales/en-US/chrome/messenger/cloudfile/Hightail/fileExceedsLimit.dtd @@ +1,5 @@ > <!-- This Source Code Form is subject to the terms of the Mozilla Public > - License, v. 2.0. If a copy of the MPL was not distributed with this file, > - You can obtain one at http://mozilla.org/MPL/2.0/. --> > <!ENTITY fileExceedsLimit.title "Hightail"> > +<!ENTITY fileExceedsLimit.thatsBigFile "Sending files larger than 50 MB is not supported."> you need to bump the localization key here. Also, should it be ... for non-premium accounts. ?
Attachment #8507115 - Flags: review?(mkmelin+mozilla) → review+
I took care of the review comments and pushed this: https://hg.mozilla.org/comm-central/rev/178ea58ee705
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 38.0
Target Milestone: Thunderbird 38.0 → Thunderbird 36.0
Note that we'll need a solution for uplift that doesn't require string changes...
Hey Magnus - any ideas on how we could satisfy Hightails requirements here without any string changes?
I don't know their specifics, but I imagine they don't care if we leave the update option in for ESR. They probably just don't want to pay for it. If that's the case, then we could just leave it as is. Otherwise, we could just hard-code the English strings we want and don't read them from the .dtd. Sure, that's not so nice for localized builds, but the dialog is rare and I don't see anything but English on the Hightail site, so...
Hey jb - do you agree with Magnus that Hightail wouldn't care if we keep the update option in the ESR?
(In reply to Philipp Kewisch [:Fallen] from comment #8) > I took care of the review comments and pushed this: > > https://hg.mozilla.org/comm-central/rev/178ea58ee705 >> +<!ENTITY fileExceedsLimit.thatsBigFile3 "Sending files larger than 50 MB is not supported for non-premium accounts."> For nl, we localized this as "Sending files larger than 50 MB is only supported for Premium accounts."> … in order to eliminate a double negative. How about doing so for en-US as well in a future revision? Note the capital P for Premium as well.
ni? mconley for comment 13.
Created attachment 8531930 [details] [diff] [review] hightail-wording.diff Actually, I did write that. I'm fine with changing the wording. Since it doesn't change the meaning I've left the entity name as is.
Attachment #8531930 - Flags: review?(mkmelin+mozilla)
Any reason why the follow-up hasn't been checked in for more than a cycle? It obviously *has* to check in for *this* cycle to correct the label for 38.x. No offense to anybody, but the checkin-needed service got lousy recently... Also, @mconley: Is the needinfo for jb per comment #12 still needed?
Assignee: nobody → mconley
Follow-up fix landed - https://hg.mozilla.org/comm-central/rev/ac74e4621c49 And adjusted my c-n query to include fixed bugs.
status-thunderbird36: --- → fixed
tracking-thunderbird32: ? → ---
tracking-thunderbird33: ? → ---
tracking-thunderbird34: ? → ---
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #12) > Hey jb - do you agree with Magnus that Hightail wouldn't care if we keep the > update option in the ESR? Hey, (beat me for the late reply - no excuses) HighTail will honor its agreement until 6/30/2015 but appreciate we close it earlier. The agreement will be terminated at that date. Looking at where we are, it should be possible for TB users to upgrade at any time, however, upgrades after that date are not covered by the agreement. I think we can maintain the upgrade option if it simplifies life for our users.
The resolution of this IIUC is that we will not be attempting to fix this in esr31, so I am removing the tracking. Thunderbird 38 has the fix which will hit before June 30 anyway.
tracking-thunderbird_esr31: ? → -
Clearing obsolete request.
You need to log in before you can comment on or make changes to this bug.