I'm writing a follow-up CL that will send integrity checking data to
BigQuery, and that is made a lot easier by centralizing the BigQuery
connection logic.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=119375766
This is the tool we'll run after dumping everything in sandbox except
for Registrars, Registries, and RegistrarContacts, in order to
re-create the commit logs on said entities.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=119369873
I'm running a read-only load test right now and I was running into unacceptably low limits with only five load test queues to execute in.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=119048442
This fixes a previous issue where metrics generated on the
tools/backend modules weren't being successfully exported to BigQuery.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=119047757
This adds better comments, sane defaults for most parameters, and
improved caching of test data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118996436
There's no point in having this extra package exclusively for
[]s, especially because we already weren't being consistent and
had multiple []s in the tools/server package.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118807843
In order to set the customerId field on a payment, the customer entry
must exist in Braintree's database. This CL causes it to be created or
updated before processing the payment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118530040
Some confusion came up in #9 over the proper way to extract TLDs from
hostnames. This should hopefully alleviate that.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118417091
Removed "run_as_a_service" parameter from backup.create command in DatastoreBackupService.
This parameter can't be used externally, and is apparently no longer needed.
* DnsUpdateWriter publishes changes to NS, DS, A, AAAA records
for domains/hosts as appropriate using RFC 2136 DNS UPDATE protocol
* Static configuration separate from RegistryConfig
* Include dnsjava library as new third party dependency
to generate DNS protocol messages
* Expose /_dr/task/writeDns in RegistryTestServer
* Currently not included in BackendComponent
Original eclipse setup used the jar command from the system path
which resulted in different behavior on different systems. This
change modifies the build target to use the jar command provided
by bazel: @local_jdk//:bin/jar
The payment page has also been updated to refuse to show itself if
the registrar is not set to credit card billing terms.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117983313
1. Turn ConsoleUiServlet into an action
2. Remove AbstractUiServlet, which fixes its threading bug
3. Use type-safe soy template parameters when rendering console
A follow-up change will add a new template parameter that renders the
payment page link on the navigation bar.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117969638
We are removing all calls in preparation for deleting the method.
More information: []
Tested:
TAP --sample for global presubmit queue
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117628955
The APNIC conformance checker points out that, according to RFC 7483,
RDAP remarks should be included only as part of object classes such as
domains, nameservers and entities, not in help responses and so on.
Note that something is amiss here -- If RFC 7483 is read strictly, the
remarks boilerplate for domain, nameserver and entity search results
should appear not at the top level, as we currently do, but as part of
each constituent object. However, the conformance checker does not
seem to complain about that. So I have added this to the RDAP questions
list, and am leaving the boilerplate at the top level for now.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117557594
Ten turns out to have been set too high; that will occasionally throw
500 Backend errors from the API (presumably having to do with
rate-limiting).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117549363
RFC 7483 defines a way to attach events (such as registration, renewal, etc.) to domains, nameservers and entities. The ICANN Profile calls out particular events: registration, expiration, last changed and last update. This CL implements all the ICANN-defined events except last update (defined to be the last update time of the database), which doesn't make so much sense in our system.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117546838
This improves one of our gTech processes so they no longer have to remember to create Google Groups for a registrar after creating that registrar.
The ConfirmingCommand.verify() method is renamed to be more general purpose, so that it can do anything that follows naturally after a successful execution, such as creating Google Groups groups.
Minor refactoring is done around RegistryToolEnvironment handling for tests to make it more bullet-proof and general case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117494277
Here's an alternate approach that I think simplifies the existing
code quite a bit. Now instead of doing:
RegistryToolEnvironment.loadFromArgs(args);
RegistryToolEnvironment.get().setup();
You just do one chained call:
RegistryToolEnvironment.parseFromArgs(args).setup();
or call setup() on a known environment constant:
RegistryToolEnvironment.ALPHA.setup();
This avoids having loadFromArgs() implicitly set the active env
(but *not* do setup) and then having setup() *not* set the active
env, both of which were confusing. Now parseFromArgs() is only
responsible for parsing from args, and setup() both sets the env
as the active one and does the environment variable setup (which
also ensures that the RegistryToolEnvironment.instance field
doesn't get out of sync with the RegistryEnvironment value).
In addition, this CL adds a runCommandInEnvironment() method to
CommandTestCase and ensures that the UNITTEST environment is always
set before constructing the default command instance.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117492978
This is cleanup from [] -- when I set up the hint, these files were recreated inadvertently. All other code is already fixed to use the classes in []/inputs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117270147
This frankenclass was starting to get a little cluttered, especially once I add the ChildEntityInput/Reader.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117266882
This is cleanup relating to a naming decision that we made awhile ago
but never got around to.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117244827
java.net.IDN uses outdated IDNA2003. We've created a replacement
class that uses the modern UTS46 transitional standard via the
IDNA library. This fixes uses of IDN in the RDAP code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117243868
This CL does a very similar cleanup to Cancellation as the diffbase
does to GracePeriod - see [] It simplifes logic where we
used to overload methods to accept eitherw OneTime or Recurring billing
events refs, despite storing them in separate fields in the entity
(since BillingEvent is not a polymorphic superclass, just a Java-only
one, you can't store them as refs to BillingEvent).
That overloading was ultimately only there as a convenience/hack from
when we added Recurring events and didn't want to go back and change
everything. It obfuscates what's really going on, requires extra
casting/loss of type-safety, and relies on indirect signals (e.g. the
Billing event reason being AUTO_RENEW) to guess what the right billing
event type is. That latter aspect will likely no longer work in a
monthly billing world, and was brittle anyways (as came up in the
context of removing the AUTO_RENEW reason - see []
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117165174
This CL cleans up some old crufy logic in GracePeriod that overloaded
methods to accept either OneTime or Recurring billing events refs,
despite storing them in separate fields in the entity (since
BillingEvent is not a polymorphic superclass, just a Java-only one,
you can't store them as refs to BillingEvent).
That overloading was ultimately only there as a convenience/hack from
when we added Recurring events and didn't want to go back and change
everything. It obfuscates what's really going on, requires extra
casting/loss of type-safety, and relies on indirect signals (e.g. the
grace period type being AUTO_RENEW) to guess what the right billing
event type is. That latter aspect will likely no longer work in a
monthly billing world, and was brittle in any case.
A coming CL will rip the same logic out of Cancellation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117164286
The client ID is passed as the "customer ID" to Braintree. In order for
this to work, someone needs to go into the Braintree website beforehand,
click on "New Customer" link, and create the customer record with a
matching ID.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=116769955
