1. 13 Feb, 2019 1 commit
  2. 29 Jan, 2019 1 commit
    • Denver Gingerich's avatar
      bump beta exit as next months busy - last: 16f2d9b7 · 8675c62e
      Denver Gingerich authored
      Recent efforts have focused on other features like international
      texting (see ffa99c71 for details) and the next few months are not
      likely to allow for much further progress on the payments situation so
      bump the guess again to get a more realistic possible beta exit date.
  3. 31 Oct, 2018 2 commits
  4. 31 Jul, 2018 1 commit
  5. 30 May, 2018 1 commit
  6. 30 Mar, 2018 1 commit
    • Denver Gingerich's avatar
      bump beta exit likely final time; last was 0ccd23bc · f385818f
      Denver Gingerich authored
      We now have a payment processor (hooray!) but that's a fairly recent
      development so there is still much coding to do to get the processor
      integrated (including some general recurring billing logic that hasn't
      been written yet).
  7. 19 Mar, 2018 7 commits
  8. 14 Mar, 2018 1 commit
    • Denver Gingerich's avatar
      set start day for a number's usage stats at signup · 51de6216
      Denver Gingerich authored
      In order for the "Show Monthly Usage" command of jmp-fwdcalls to work
      correctly, it needs to know when a given number was last registered so
      that it doesn't show stats from possible previous registrations when
      it returns the stats to the current user of a given JMP number.  As a
      result, we need to set the date that the number was registered as part
      of the registration process, which is what this change does (setting
      the value of usage_start_day-[JMP_number] to today's date - ideally
      this would be a TAI date, but for now we're just using UTC because it
      is close enough for our purposes, and adding ./tai as a dependency (as
      we did for jmp-fwdcalls and sgx-catapult) seems like a bit much; note
      that the server's timezone must be UTC as we still need a fix here).
      For further details on how usage_start_day-[JMP_number] is used, see
      jmp-fwdcalls@5b1481b8 .
      With this change to jmp-register, all subsequent registrations will
      have the correct information for the "Show Monthly Usage" command, but
      if some users registered before this change was deployed, then their
      usage_start_day-[JMP_number] values MUST be set manually.
  9. 31 Jan, 2018 1 commit
    • Denver Gingerich's avatar
      bump beta exit one(?) more time; last was c20a09ed · 0ccd23bc
      Denver Gingerich authored
      Getting an account at a suitable payment processor has proven to be
      more difficult than anticipated - we haven't been able to start the
      core development work because we don't have an account yet (and thus
      we don't know which API we will ultimately be using, as we can't say
      for sure which of our options will pan out).  Things are looking up
      with one processor, though, so we should be out of the woods soon.
  10. 28 Nov, 2017 1 commit
    • Denver Gingerich's avatar
      port requests now via form, linked from main page · 7dc5e79a
      Denver Gingerich authored
      This change adds a porting form that users can now use instead of
      manually delivering the porting information through the JMP support
      avenues.  The user needn't interact with JMP support at all now, as
      the port will happen "automatically" once they submit the porting
      In order to make this happen, the porting form delivers the parameters
      from the user to the JMP administrator via email, using a hack similar
      to the one in 11a0c5d4 where $notify_receiver_email is abused for this
      purpose (we should have separate variables for each type of email
      address, but for convenience we are just using one for now).  The form
      code also constructs a URL that includes these user-entered form
      parameters so that the URL can be visited by the JMP administrator to
      view the completed Letter of Authorization, with all of the requisite
      values populated.  The URL's base address is specified in the new
      $porting_form_url variable in the jmp-register settings file - the
      contents of the page/code at that URL are beyond the scope of
      jmp-register, since the form is carrier-specific.  The administrator
      will need to provide their own porting page that populates its
      values based on the GET parameters sent by porting3 if they wish to
      take advantage of the porting form.  Normally this page would then be
      submitted to the administrator's carrier, either via API, or through a
      support ticket or similar.
      The #existing section of the main jmp-register page now links directly
      to the new porting wizard, as does the "bring your own number" link in
      the Signup section.
      It is up to the administrator of the jmp-register instance to submit
      the Letter of Authorization once they receive the email sent by the
      porting3 page, and then follow up with the JMP user once a FOC date
      has been established.  Additional manual steps are required in order
      to switch the user's JMP number once the port completes - such steps
      are beyond the scope of jmp-register for now.
  11. 27 Oct, 2017 2 commits
    • Denver Gingerich's avatar
      bump beta exit yet again, as in cdfeb803, by 3 mths · c20a09ed
      Denver Gingerich authored
      New payment and plan options are still not ready, so we'll need to
      delay leaving beta a little longer.  Given that there aren't a lot of
      other items to worry about between now and then (such as conferences
      and the like), this should be attainable.  We'll see!
    • Denver Gingerich's avatar
      Debian 9 does not need register4 gem version pins · 34264e90
      Denver Gingerich authored
      Since we now test and run jmp-register primarily on Debian 9, we can
      update the Gemfile for register4 (the only Ruby component in
      jmp-register) to note that newer versions of the gems we previously
      pinned now work fine (at least with the version of Ruby shipped with
      Debian 9 - version 2.3.3).
  12. 21 Oct, 2017 1 commit
    • Denver Gingerich's avatar
      for iOS recommend Tigase Messenger, not ChatSecure · d9c70c42
      Denver Gingerich authored
      ChatSecure has been non-optimal for a while now, primarily because it
      does not support receiving messages from contacts not in the user's
      roster (see https://github.com/ChatSecure/ChatSecure-iOS/issues/844
      for details).  We recently found that Tigase Messenger does support
      this, and generally works at least as well as ChatSecure in other
      areas (especially in that it is free and open source software) so it
      makes sense to switch our recommendation.
      Tigase Messenger's support for Push works best with Tigase's own
      server extension, which one can use by picking the tigase.im server
      when creating an account.  This is not ideal (especially since Push
      without the extension seems to work not quite as well as ChatSecure),
      but it's more important that non-roster messages get through for now.
      In the future we can modify the signup page to recommend a tigase.im
      JID when using Tigase Messenger, if they haven't fixed Push by then.
  13. 15 Sep, 2017 2 commits
    • Denver Gingerich's avatar
      main page uses dismail.de instead of jabjab.de now · 731d39fe
      Denver Gingerich authored
      As a follow up to 7faa6c21, the main page now recommends dismail.de
      just like the suggested servers page.  We waited to commit this one
      because we didn't have a logo ready when 7faa6c21 was committed, but
      thanks to the dismail.de admin, who graciously created such a logo for
      us to use, we can now include it in this commit.
    • Denver Gingerich's avatar
      dismail.de now preferred on suggested servers page · 7faa6c21
      Denver Gingerich authored
      Recently jabjab.de started silently ignoring messages from contacts
      not in its users' rosters so it is no longer suitable as a preferred
      or even suggested server.  As a result, we are replacing it with
      dismail.de, which does support such messages and intends to continue
      supporting them for the foreseeable future.
      While we're at it, also rearrange the page so that the servers are
      listed in their order on https://gultsch.de/compliance_ranked.html as
      that makes the order a bit less arbitrary.  Additionally, remove
      jabberzac.org since it apparently no longer supports MAM.  So now our
      suggested list is down to 8 servers, from 10 before this change.
  14. 06 Sep, 2017 1 commit
    • Denver Gingerich's avatar
      add new (hidden) one-time payment option, upgrade0 · a2ba1700
      Denver Gingerich authored
      The new upgrade0 page provides users with a one-time payment option.
      It is a slightly modified version of upgrade2 (which handles the
      subscription payment options) and directs users to upgrade3 just like
      upgrade2 does.  The text has been updated to mention that the upgrade3
      text might not be fully accurate for the one-time payment being done
      here, and to generally say that this is a one-time payment being made,
      not a subscription.  A new PayPal tags setting has been added,
      $paypal_tags_one_year, similar to the exists settings for the
      subscription options, which holds the tags needed to display the
      appropriate PayPal button for the one-time (and one year) payment.
      Note that the PayPal staging URL for the form was not used here, since
      a staging button for one-time payment has not been setup yet.  This
      should be fixed eventually, but is not a huge deal for a hidden page.
      This new page is not intended to be linked from the rest of the JMP
      site at least until upgrade3 has been updated to reflect that a
      one-time payment may have been used.  It is only to be used for
      payments where the user has already been made aware that this is a
      custom payment option that is not normally provided.
  15. 28 Aug, 2017 1 commit
  16. 23 Aug, 2017 1 commit
  17. 26 Jul, 2017 1 commit
  18. 29 Jun, 2017 1 commit
  19. 26 Jun, 2017 1 commit
  20. 23 Jun, 2017 3 commits
  21. 20 Jun, 2017 1 commit
    • Denver Gingerich's avatar
      simplify front page, make apps easier to find/get · 7d34dcc0
      Denver Gingerich authored
      This change primarily simplifies the main page, so that a first-time
      visitor doesn't have to wade through a wall of text before getting to
      the Signup section, and so that the Signup section is much easier to
      follow (now a simple 3-step process!).  Links to the apps and servers
      that users are likely to use with JMP are now very prominent (and have
      their own icons, which are also included in this commit).
      Multiple sections of the FAQ have been updated, mostly to include some
      of the text that originally existed above the FAQ, but simultaneously
      with their own simplifications so that the overall size of the FAQ
      section did not grow (much).  The most substantial overhaul was to Q2
      (the #jabber section), with Q1 (#features), Q9 (#calling), and Q10
      (#voicemail) also receiving significant updates.
      In particular, we are now recommending Movim as the way to update the
      voicemail settings (in the #voicemail section), since it now supports
      ad-hoc commands, rather than Gajim, which doesn't easily run on macOS.
      Perhaps the biggest high-level change is that iOS apps are now listed
      alongside Android apps whenever they are mentioned.  Previously it was
      difficult for an iOS user to find the appropriate app to use.  We now
      recommend ChatSecure and Linphone for XMPP and SIP, respectively, as
      we have found that they work reasonably well in testing.
      This commit does not include any "functional" changes to the signup
      flow - all of the register* pages work exactly as they did before, but
      with added/simplified text in some cases (on register2 and register4).
  22. 15 Jun, 2017 1 commit
  23. 12 Jun, 2017 1 commit
    • Denver Gingerich's avatar
      ask user to add support JID if first verify fails · 7d9da9d9
      Denver Gingerich authored
      Some servers (and some clients, ie. using Gajim's "Ignore events from
      contacts not in the roster" setting, which is off by default) will not
      receive messages from JIDs that are not in the user's roster.  As a
      result, the verification message might not be received by the user who
      is attempting to signup for JMP.
      So we add some text to the page where we ask for the verification code
      that tells the user to first add the support JID to their roster
      before retrying.  This should improve the registration process for a
      select number of users.
      See #12 for more details on this issue.  We won't close it yet because
      there should probably still be some text to explain to the user that
      their experience will be severely limited if their client or server is
      configured this way, since they won't be able to receive text messages
      or voicemail from phone numbers that are not in their roster.
  24. 09 Jun, 2017 3 commits
    • Denver Gingerich's avatar
      offer numbers from internal inventory when desired · 125fea23
      Denver Gingerich authored
      Prior to this commit, jmp-register only ever offered or suggested
      numbers to prospective users that were currently available in the main
      (unpurchased) inventory provided by Catapult.  No caching or other
      non-realtime handling of this inventory was done.
      Here we add an option for the jmp-register administrator to include a
      specific set of numbers (that they own already in their Catapult
      account) to prospective JMP users, in addition to the numbers that are
      already offered from Catapult's main (unpurchased) inventory.
      In particular, we update both the area code search (register1) and
      number suggester (num_find.php) to include numbers from the specified
      list when appropriate.  The logic is as follows:
      * the last number suggested by the number suggester will be replaced
        by a "fancy" number if (a) the suggester is returning two or more
        numbers in total, (b) the prospective user has at least one area
        code from $fancy_area_code_neighbours in their number list already,
        and (c) the suggester is able to find a "fancy" number from the
        administrator's list that is not used by JMP yet after checking at
        most three random numbers in the list to see if they're used by JMP
      * when a user searches for numbers in area code 212, register1 will
        return up to $fancy_max numbers from the administrator's "fancy"
        number list ($fancynums[0]) that are not used by JMP yet
      Note that there is still the usual race where a user may pick a number
      at the start of registration that is no longer available by the time
      they've verified their JID.  This is handled with an error message and
      an option to start again (and select a different number), regardless
      of which type of number the user attempted to acquire, "fancy" or not.
      As implemented, only one set of "fancy" numbers can currently be
      specified.  The eventual goal is to allow multiple sets, each with its
      own distinct set of neighbouring area codes.  Each area code in the
      list of neighbouring area codes ($fancy_area_code_neighbours) would
      then point at the index of the list of "fancy" numbers it's adjacent
      to inside of $fancynums.  Currently the code assumes that there is
      only one such list ($fancynums[0]) and the values of the keys in
      $fancy_area_code_neighbours are unused (responsible administrators
      should set all those values to 0 for forward compatibility).
      register1 currently assumes that the "fancy" numbers are in area code
      212 (per the bullet point above).  For now, additional area codes
      would need to be added manually to the logic in register1 (in addition
      to being added to fancynum-jmp.php per the README file).
      This commit was made possible by 9f39ccdc and e8dc5c07.  Thanks to
      9f39ccdc, it is a purely additive commit.  e8dc5c07 allowed users to
      register numbers already in the administrator's Catapult account, but
      until this commit such numbers were not shown/selectable in the UI and
      the user would have to edit the query string (ie. the number parameter
      of the register2 URL) in order to register such a number.
    • Denver Gingerich's avatar
      can now add non-JMP number in Catapult acct to JMP · e8dc5c07
      Denver Gingerich authored
      Previously the only way to register a number with JMP through
      jmp-register was to buy a new number from Catapult and then assign it
      to JMP.  This makes it difficult for a user to attach a number that is
      already part of the Catapult account to JMP (the user/admin would need
      to execute several manual steps instead).
      Now, if the number was not able to be purchased from Catapult, we will
      see if it exists in our account already instead of returning an error
      immediately.  If it exists and is not used by JMP yet, then we let the
      user register it.
      There are a few use cases for this, one being to allow users to "buy"
      numbers from an internal inventory rather than from Catapult's list of
      available numbers.  More on that in future commits.
      This commit is almost purely additive, aside from a comment change and
      control flow swap.
    • Denver Gingerich's avatar
  25. 07 Jun, 2017 1 commit
  26. 06 Jun, 2017 1 commit
  27. 31 May, 2017 1 commit
    • Denver Gingerich's avatar
      remove $sgx_url as $fwdcalls_url has its value now · ab80ad28
      Denver Gingerich authored
      When jmp-fwdcalls!1 was
      merged, we noted in the commit (0f23484) that "There is only one
      callback URL for both calls and SMS now."  This is the requisite fix
      for jmp-register to reflect that change - since jmp-fwdcalls invokes
      sgx-catapult now, and also handles its callbacks, the two URLs are now
      the same and thus we only need/can have one of them; delete the other.