The next step is to add them for domain checks as well (which is simpler
because it doesn't involve validation).
This requires the addition of a TrimWhitespaceAdapter for XML JAXB objects,
which will prove useful for other @XmlValue attributes in the future.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181526726
The extension itself isn't used for anything yet; allocation tokens can be
passed for domain creates and checks but are ignored if present. This will
be changed in a subsequent CL that adds AllocationToken entities and related
logic. Usage of this extension in any other EPP flow will throw an
UnsupportedExtensionException.
The relevant spec is https://tools.ietf.org/html/draft-gould-allocation-token-04
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181343188
Logic actually using this entity to follow in subsequent CLs introducing
the command to generate/save these entities as well as the flow logic for
considering them during domain EPP operations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181342600
Stream.concat only accepts 2 parameters. Streams.concat on the other hand
accepts any number of parameters.
Moving to Streams.concat for all uses (2 or more) makes sense for uniformity
and convenience reasons.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179716648
This removes some qualifiers that aren't necessary (e.g. public/abstract on interfaces, private on enum constructors, final on private methods, static on nested interfaces/enums), uses Java 8 lambdas and features where that's an improvement
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177182945
Unfortunately this tool isn't smart enough to deal with the assertThat
situation (which has two static imports of a function with the same name).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172000753
This was a surprisingly involved change. Some of the difficulties included
java.util.Optional purposely not being Serializable (so I had to move a
few Optionals in mapreduce classes to @Nullable) and having to add the Truth
Java8 extension library for assertion support.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171863777
Allow superusers to change the grace period and allow
superusers to change the pending delete length.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168028545
Allow superusers to change the transfer period to zero years and allow
superusers to change the automatic transfer length.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167598314
Now that the registration period has been added to DomainApplication, we
can remove this @OnLoad that was populating it for objects that were
missing the period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159464438
Memcache is already off but now it's not in the code anymore.
This includes removing domain creation failfast, since that is actually
slower now than just running the flow - all you gain is a non-transactional
read over a transactional read, but the cost is that you always pay that
read, which is going to drive up latency.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158183506
Now that transfers are always restricted to 1 year, it's unnecessary to store
extendedRegistrationYears on TransferData - it will always be equal to 1. This
simplifies logic in a few other places, e.g. RdeDomainImportAction.
I verified in BigQuery that no DomainBases exist with extendedRegistrationYears
values that aren't either null or equal to 1. At some point we should remove
the persisted fields from datastore via e.g. resaving all those domains, but
it's low priority and can wait until we have some more pressing migration.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150373897
Noticed that this is a bit out-out-date ever since these were
split into two types versus using the converters.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150352102
In fact, completely eviscerate cloneProjectedAtTime (to be removed in
a followup CL) in favor of doing the projection of transfers and the
loading of values from the superordinate domain at call sites. This
is one of the issues that blocked the memcache audit work, since the
load inside of cloneProjectedAtTime could not be controlled by the
caller.
Note: fixed a minor bug where a subordinate host created after its superordinate domain was last transferred should have lastTransferTime==null but was previously reporting the domain's lastTransferTime.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149769125
This adds a new method which will be used in an upcoming CL affecting domain
transfer logic. It also removes two older methods that are unused (they were
originally going to be used for TLD-specific logic which is now obsolete).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148928965
All domain/host names should be stored in their canonical forms (puny-
coded and lower-cased). This validation is already in the flows, but
this adds protection against bad data from other sources, e.g. admin
consoles or RDE imports.
This also removes an old work-around that temporarily suspended this
validation for superusers, because we used to have non-canonicalized
data in the system. The non-canonicalized data has since all been
cleaned up, so this work-around is no longer necessary.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146799558
DomainApplications have nothing to project, so it's a mistake to call their cloneProjectedAtTime() method. Marking it @Deprecated helps prevent such inadvertent use.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146716189
This was used in DomainInfoFlow to return a DomainResource with no
nameservers without making INACTIVE show up. It was nominally used
in DomainApplicationInfoFlow for the same reason, but that's just
an artifact of the old flow hierarchy since applications never have
INACTIVE set anyways. In either case, now that we have the DomainInfo
return object instead of returning DomainResource directly from the
flow, it's better handled within the flow.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145582317
This is probably best from a code-cleanliness perspective anyways,
but the rationale is that tightly coupling the resources to the
info responses was a straightjacket that required all status
values and fields to be directly available on the resource. With
this change, I already was able to get rid of the preMarshal()
hackery, and I will be able to get rid of cloneWithLinkedStatus()
and most of the contents of cloneProjectedAtTime() for non-domains.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144252924
This is a reasonable thing that custom code might want to do (Donuts already has
a use case).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144216929
It can always be brought back if we find an actual use case for it, but for now, it shouldn't be in the standard distribution given that it has no users.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143044153
With some code cleanup/refactoring/formatting by Ben McIlwain.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141199855
and HostResource.
DomainApplication is not transferable and has no need for this
field. HostResource needs it because it can be transferred with
a domain.
This is all in service of removing the ofy().load() inside of
host's cloneProjectedAtTime.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139346925
HostResource and DomainApplication are not transferable, (or at
least, not directly in the case of hosts) and have no need for
the TransferData field. In a flat-flow world, we can push it down
to where it's actually used.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139201423
This is the third and final phase in the migration away from ReferenceUnions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138778148
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
This is the second phase of a three phase migration to remove
ReferenceUnions. As of the end of this phase, ReferenceUnions are no longer read
from in any active code paths, but are still written to in case a rollback to
the previous version is necessary. The third and final phase will remove the
ReferenceUnions entirely.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137951076
We are adding the registration period to DomainApplication. For the moment, add an @OnLoad which, if the period is missing, populates it from the EPP XML. This can be removed once we have resaved all applications.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137723098
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
*** Reason for rollback ***
This code is fine, and I will be resurrecting it unaltered next week. It's only being rolled back for operational reasons related to the timing of our internal pushes.
*** Original change description ***
Switch over to non-ReferenceUnion fields on DomainBase
This is the second phase of a three phase migration to remove
ReferenceUnions. As of the end of this phase, ReferenceUnions are no longer read
from in any active code paths, but are still written to in case a rollback to
the previous version is necessary. The third and final phase will remove the
ReferenceUnions entirely.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136642759
This is the second phase of a three phase migration to remove
ReferenceUnions. As of the end of this phase, ReferenceUnions are no longer read
from in any active code paths, but are still written to in case a rollback to
the previous version is necessary. The third and final phase will remove the
ReferenceUnions entirely.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136388057
