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 appears to be standard RDAP practice when returning result sets for domain, nameserver and entity searches to give only summary data for each result item. Any information that can be gleaned from the object itself is included, but related resources are not included. For a domain, for instance, the domain information is included, but nameservers, entities and events (which come from history entries) are suppressed. In their place, there is a standard boilerplate remark in the object indicating that only summary data is included, and that the user should query the item directly to get the full data. Note that summary data is used only for searches; direct queries for an item will still return full data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133973835
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
Because we cannot weed out deleted domains in the query itself, the RDAP code must pull all domains with matching names, then throw out the deleted domains. So we don't know how many domains to fetch up front to fill up the desired maximum result set size. This CL adds a loop to attempt to fetch addition domains if the first fetch did not yield enough, while giving up after a while to avoid bogging down the system.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133420297
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
This removes the countless lines of the form "[null, []]" in registry_tool diffs
that are an artifact of the way we handle nulls in Objectify.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133409440
It is a bad idea to override toString() on enums to return something other than
the actual name of the enum.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133318012
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
This allows us to inject an optional once, in FlowRunner, and
inject a non-null value in the flows (not done yet, after this
goes in).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133130485
There was very little meat in the contact hierarchy and it
flattened quiet easily.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133080191
Command allows for both one-off creation and bulk import of assignees via file (the latter will be used for the initial import from Play Store).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133048360
The exceptions created for generic problems with the flags extension (invalid flag, etc.) should be in a common location, so they can be used by all interested TLDs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133040831
This factors out a huge chunk of boilerplate that
would otherwise be in every single flow.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133014837
By duplicating rather than moving them, I can keep both versions
around while I port the flows over to the new flat form.
I could have made these g4 moves from the original sources, but
there's barely anything in these files and it didn't really seem
like it was adding anything useful.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132999387
