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
These have already been totally replaced by flattened flows.
There are a few left that will get deleted when the remaining
flat flows go in.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134077510
The reason field is 1:1 mapped to skus in billing reports. Need to add a new reason for EAP for this type of billing event for reporting to work correctly. Also map that reason to the correct SKU.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134005364
When custom effective date is passed in the check command, the response should
contain that date as an acknowledgemant that the check is performed at a time
different from now.
Also when the fee(s) returned contains a validDateRange (i. e. EAP fees that
are only valid during a certain period), the response will contain a notAfter
field which is the date after which the quoted fee(s) are no longer valid. (i.
e. the earliest of the end dates of all fees that would expire.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133989775
These were historically separate due to the old flow
structure, but now they should be one exception.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133984858
It is replaced by loadByForeignKey(), which does the same thing that
loadByUniqueId() did for contacts, hosts, and domains, and also
loadDomainApplication(), which loads domain application by ROID. This eliminates
the ugly mode-switching of attemping to load by other foreign key or ROID.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133980156
Also pull out a small bit of common functionality across contact and host checks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133977324
It's best to be consistent and use the same thing everywhere. "clientId" was
already used in more places and is shorter and no more ambiguous, so it's the
logical one to win out.
Note that this CL is almost solely a big Eclipse-assisted refactoring. There are
two places that I did not change clientIdentifier -- the actual entity field on
Registrar (though I did change all getters and setters), and the name of a
column on the exported registrar spreadsheet. Both would require data
migrations.
Also fixes a few minor nits discovered in touched files, including an incorrect
test in OfyFilterTest.java and some superfluous uses of String.format() when
calling checkArgument().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133956465
Also make minor javadoc tweaks to domain transfer flows
to match what we are changing in contact/host flows.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133955677
Rename existingResource flows variable to be specific to EPP resource type and replace some explicit checks with helper methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133774229
Also consolidates the DNS refresh functionality in AsyncFlowUtils that was
being used by HostUpdateFlow into AsyncFlowEnqueuer.
TESTED=I threw together some batch scripts to create dozens of contacts on
alpha and then request their deletion, and the [] ran fine and
successfully deleted them in batches.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133714691
Currently EapFee is a separate class that has no inheritance from either
BaseFee and Fee. With this CL its functionality is merged into the Fee class
and the type of the fee can be identified by the FeeType enum in the Fee class.
Future custom fees can follow the same pattern.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133627570
We almost certainly had intended to record a String representation of the
numeric Code all along, but a bad toString() method on the enum resulted
in the wrong thing happening. This is more evidence of why overriding
toString() on enums is bad.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133583683
Added support to specify custom effective date to run the fee check command.
Such functionality is useful for TLDs with creation price as a function of
time, such as those with EAP. However the implementation is not limited EAP or
create price check. Any fee check can specify a date, as long as its XML schema
supports a date.
Currently conforming to fee extension v12, subject to schema changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133420255
There's so little meat here that there's not much
reason to break this cl up any further
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133171754
This allows handling of N asynchronous deletion requests simultaneously instead
of just 1. An accumulation pull queue is used for deletion requests, and the
async deletion [] is now fired off whenever that pull queue isn't empty,
and processes many tasks at once. This doesn't particularly take more time,
because the bulk of the cost of the async delete operation is simply iterating
over all DomainBases (which has to happen regardless of how many contacts and
hosts are being deleted).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133169336
The RFCs are ambiguous.
5733 (contacts):
3.2.4. EPP <transfer> Command
...the
<transfer> command MUST contain a <contact:transfer> element that
identifies the contact namespace. The <contact:transfer> element
contains the following child elements:
...
- A <contact:authInfo> element that contains authorization
information associated with the contact object.
However, the xsd explicitly marks it as optional:
<complexType name="authIDType">
<sequence>
<element name="id" type="eppcom:clIDType"/>
<element name="authInfo" type="contact:authInfoType"
minOccurs="0"/>
</sequence>
</complexType>
The language in 5731 (domains) is [] The only example given in both is for a transfer request, which is the one flow that obviously requires the authInfo.
We had decided that for transfer approve and reject, which are done by the losing client, requiring the authInfo is silly because it's available to that registrar from an <info> and there's no extra security in having them present it (although if they do present it we validate it). The question about cancel was whether the gaining client, which had to present the authInfo in the original transfer request, needs it again for cancel.
I can't come up with any reason this would be beneficial, and I'm making the decision: authInfo is not required on transfer cancel.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133168739
Other flows to come. This removes the need for
most of the flows to inject the command at all.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133163030
Although the delta implies that this is actually adding code, it's
better than it looks, because some of the stuff in ContactFlowUtils
is duplicating more generic methods in ResourceFlowUtils, which
can be deleted when the domain and host flows are cut over.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133149104
