This now throws errors when a non-lower-cased, non-puny-coded, or non-canonicalized host name is passed in as an input parameter.
The approach we'll take is to first notify registrars which hosts we'll be renaming, then
issue EPP host update commands to effect those renames as superuser, then push this code
live to production.
This fixes#38 on GitHub.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138441130
I added shared base classes to all of the Fee extension types that
make it possible to fully ignore the version in the flows. (You
ask for a FeeCreateCommandExtension, for example, and you get one
without having to worry about which). This is an improvement over
the old code that asked you to provide a list of possible fee
extensions and then ask for the first one in preference order.
As part of this I was able to make the Fee implementation a bit
simpler as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137992390
1) Don't do ofy().load() inside a model class (in DomainAuthInfo)
2) Move the one use of verify into the one caller in ResourceFlowUtils
3) Hosts don't support authInfo, so remove useless code
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137984809
*** Original change description ***
Remove deprecated methods with Guava 20 release
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137945126
This concludes your flow flattening experience. Please
fill out a flow flattening satisfaction survey before
exiting.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137903095
Now that the flows are flattened, the commitAdditionalLogicChanges() call, which used to come later in the flow to actually save the Datastore objects, is now happening right after the performAdditionalXXXLogic() call. So we can instead just do the saves in performAdditionalXXXLogic(), and get rid of the separate call. As a first step, this CL simply makes commitAdditionalLogicChanges() a private method that gets called internally by the extra logic manager. Later, we can move the saves into their proper position, affecting only the extra logic class itself.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137529991
This will make it much easier to detect issues with bad EPP XML (e.g. the one in the loadtest action fixed in [] based on the request logs, since otherwise the only indication of what went wrong is the EPP response returned to the client, which we don't store anywhere.
Now we'll get log messages that look like this:
google.registry.flows.EppController handleEppCommand: EPP request XML unmarshalling failed - "Syntax error at line 2, column 7: cvc-elt.1: Cannot find the declaration of element 'epp'.": (EppController.java:59)
{"clientId":"CharlestonRoad","resultCode":2001,"resultMessage":"Command syntax error","xmlBytes":"PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI\/Pgo8ZXBwLz4K"}
========================================
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp/>
========================================
google.registry.flows.EppXmlTransformer$GenericSyntaxErrorException: Syntax error at line 2, column 7: cvc-elt.1: Cannot find the declaration of element 'epp'.
at google.registry.flows.EppXmlTransformer.unmarshal(EppXmlTransformer.java:89)
at google.registry.flows.EppController.handleEppCommand(EppController.java:56)
at google.registry.flows.EppRequestHandler.executeEpp(EppRequestHandler.java:37)
at google.registry.flows.EppToolAction.run(EppToolAction.java:33)
<snip>
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137363446
Right now, DomainApplicationCreateFlow checks to make sure that the registration period is in years, but doesn't store it in the DomainApplication explicitly. Instead, when DomainAllocateFlow runs later, it goes back to the XML in the HistoryEntry to get the number of years. Corey suggests that it would be cleaner to store the number of years in the DomainApplication. This is stage one of a data migration; we store the value, but don't actually read it anywhere except in tests. If we have any outstanding domain applications, we will then need to write a scrap tool to populate the years field, after which we can start relying on the field.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137317739
This was meant for log replay and has long been ignored/useless.
As part of this, remove execution time from EppResponse since this
was the only thing consuming it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137293734
We already had methods to return just the create or just the renew price. I added more to return just the premium flag or just the fee class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136833071
The renew flow was still using PricingEngineProxy directly, meaning that it did not pick up on any TLD-specific pricing logic. Fixed this, and added tests to make sure.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136757922
There are no applications extant that predate the creationTrid field.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136047561
This is to better distinguish between an LRP "token" (the string passed along in EPP) and the datastore entity that contains the token and all metadata.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135943480
It is no longer needed since we don't do log-replay and it's
annoying to support in the flat flows.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135805088
This CL implements the TLD-specific extra flow logic for updates, with tests, based on the static helper classes of the previous CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135683537
Very few flows actually check the phase. Push the checks down to the leaf
flows so that we can remove the inherited code from ResourceFlow and replace
it with utility methods. In the process, document and test two places that
throw the exception but did not previously test it.
This introduces a temporary hack in BaseDomainCreateFlow that does something
specific for DomainApplicationCreateFlow. It will go away literally tomorrow
when I flatten that flow.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135480538
TESTED=I deployed it on alpha, renamed some hosts, and verified that
the [] ran as expected.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134991941
This will make potential issues a little nicer to debug in the future, because
the person hitting these endpoints manually will immediately know why they may
not be kicking off a [] console as might be expected.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134840223
This applies lessons learned from the async batch DNS refresh action, in
particular making testing more robust.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134833523
This CL fixes a bug introduced in [] which caused an exception to be thrown when an attempt was made to update a domain without a fee extension, even if the update was free, as it usually is. The fee extension should only be required if the update is not free.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134830250
This will replace the existing DnsRefreshForHostRenameAction.
This is stage one of a three stage migration process. It adds the new queue and
[] but doesn't call them yet. Stage two will cut over to using the new
functionality, and stage three will remove the old functionality.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134793963
This attempts to improve the organization of the helper methods in
DomainTransferRequestFlow created by the flattening in []
The primary changes are:
- new createTransferServerApproveEntities() method that now makes
all the server approve entities in one centralized place
- new createPendingTransferData() method that takes the server
approve entities and hides the slightly hacky code that parses out
the right ones to stuff into the TransferData
This seems like an overall simpler structure to me. With this change,
run() is 20 lines shorter and the flow overall is 40 lines shorter (not
counting a big blob of javadoc I added).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134315295
