This was an oversight I noticed ages ago, so resurrecting some old local changes I had to correct it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146812322
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 is a cleanup in preparation for the next change that does a lot
of work with subordinate hosts, to make it easier to reason about in
complex code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146689904
Follow-up to comments on [] in particular to clarify that INACTIVE can be combined with other statuses and doesn't have any special relationship to OK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146683905
This generalizes the "LINKED can't be anywhere" idea into more
targeted restrictions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146158204
* Remove LINKED when loading an EppResource
* Enforce that you can't add it to a resource
* Ignore LINKED on xjc import of contacts and hosts
After running ResaveAllEppResourcesAction we will no
longer have persisted LINKED statuses in datastore.
In the process of writing this I discovered that RDAP
treats LINKED like any other status value and returns
the persisted value rather than the derived one. Since
this is an existing bug and is orthogonal to the changes
in this CL, I am addressing it in a separate CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145585227
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
Now that we return an Info object rather than the resource itself,
there's no reason for the cloning pattern.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145426484
This is preparatory refactoring for the next CL, which gets rid
of cloneWithLinkedStatus
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145424322
We no longer care about ROID suffix uniqueness in a post-Registry-2.0-migration
world, and the Registry cache is sufficient for efficiently grabbing the ROID
suffix for TLDs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144483726
The command still enforces uniqueness (which is fine), but by changing the cache
from a BiMap to a Map, we can support non-unique suffixes if they happen to be
configured as data. The only reason the cache was ever a BiMap in the first
place was to support the Registry 2.0 migration, which was finished a year and a
half ago. It's only being read one way now, so a Map is fine.
See https://github.com/google/nomulus/pull/53 for context.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144381946
This allows us to use util methods from within config, which is a useful thing
to be able to do for, e.g., being able to log errors while loading configuration.
It makes sense that the util package should be at the very base of the
class inheritance hierarchy; config seems logically higher than it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144324273
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
We are now ready to begin configuration using YAML, mediated by ConfigModule.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143818507
The next step will be to get rid of RegistryConfig descendants and RegistryConfigLoader entirely.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143812815
This CL adds an otherClientId field to be populated on domain transfers with client ID of the other end of the transaction (losing registrar for requests and cancels, gaining registrar for approves and rejects). This will be used for reporting in compliance with specification 3 of the ICANN registry agreement.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143775945
This primarily addresses issues with TMCH testing mode and email sending utils.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143710550
I'm setting it to three buckets across all tests, because the default one bucket
wasn't realistic enough, and allowed some tests to pass that shouldn't have,
essentially by accident.
This also changes RegistryConfig from being an interface to being an abstract
base class. The medium term goal here is to have it be a static class so that it
can provide fields from the YAML-derived POJO in situations where Dagger
injection isn't feasible.
The expected end state is as follows:
default-config.yaml -- The master config file that provides defaults for all
values.
nomulus-config.yaml -- A per-environment config file that overrides the defaults
from the previous file.
YamlConfig.java -- The POJO that the aforementioned YAML files are deserialized
into.
RegistryConfig.java -- Contains a static, memoized instance of YamlConfig and
provides static methods for getting some of those values.
ConfigModule -- Will become a static inner class of RegistryConfig, using Dagger
to provide most of the fields from the memoized YamlConfig instance. This way,
all configuration will be coming from a single place: RegistryConfig.java.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143567288
We're now using java_import_external instead of maven_jar. This allows
us to specify the relationships between jars, thereby allowing us to
eliminate scores of vendor BUILD files that did nothing but re-export
@foo//jar targets, thus addressing the concerns of djhworld on Hacker
News: https://news.ycombinator.com/item?id=12738072
We now have redundant failover mirrors, which is a feature I added to
Bazel 0.4.2 in ed7ced0018
A new standard naming convention is now being used for all Maven repos.
Those names are calculated from the group_artifact name using the
following algorithm that eliminates redundancy:
https://gist.github.com/jart/41bfd977b913c2301627162f1c038e55
The JSR330 dep has been removed from java targets if they also depend
on Dagger, since Dagger always exports JSR330.
Annotation processor dependencies should now be leaner and meaner, by
more appropriately managing what needs to be on the classpath at
runtime. This should trim down the production jar by >1MB. As it stands
currently in the open source world:
- backend_jar_deploy.jar: 50MB
- frontend_jar_deploy.jar: 30MB
- tools_jar_deploy.jar: 45MB
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143487929
This is the first in a decently long series of commits to delete RegistryConfig
entirely and centralize all configuration in ConfigModule using Dagger. Once
this is done, then the text-based YAML configuration work can begin in earnest.
Note that the configuration settings from TestRegistryConfig will be moving
into ConfigModule.LocalTestConfig. This way they can be referred to in a static
context from test and test utility helpers, rather than having to be injected
everywhere, which we don't typically bother with for tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143473089
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
It wasn't being used by any actual code, and having helper methods handling
saving/persistence on entities like this is not a pattern we want to encourage,
since it hides Datastore transactions from further up in the call chain. The
idea is that you can always look for ofy() calls in the same layer of code to
see where persisted data is being changed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143036027
Enums should be immutable, so all fields on them should be final.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142025872
With some code cleanup/refactoring/formatting by Ben McIlwain.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141199855
Swap all calls to TldSpecificLogicProxy.getCreatePrice() to the counterpart in
DomainPricingLogic. Also makes necessary changes for testing to work, including
fake implementations of DomainPricingCustomLogic and
DomainCreateLofwCustomLogic.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140754334
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
The callsites were inconsistent between whether they were passing empty list or
null, and many of the ones that were passing null were not correctly annotated
with @Nullable. I'm now going with empty list throughout except for the final
step where the actual field that will be transformed into XML is set, where it
is coerced to null to avoid an empty element in the XML output.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139340837
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
1) Prefer .getConstructor().newInstance() over .newInstance()
because otherwise checked exceptions can be propagated from
the constructor even though they aren't declared.
2) Use the type T in the parameters to instantiate().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138874730
