Commit graph

11 commits

Author SHA1 Message Date
mountford
fb47d2563d Add extra flow logic hooks for transfer approve, cancel and reject
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139217498
2016-11-15 13:52:01 -05:00
cgoldfeder
84009eaccb Scope down TransferData to only ContactResource and DomainResource
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
2016-11-15 13:47:28 -05:00
shikhman
f76bc70f91 Preserve test logs and test summary output for Kokoro CI runs
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135494972
2016-10-14 16:57:43 -04:00
cgoldfeder
f3a0b78145 Move thrown.expect() right before the throwing statement
aka regexing for fun and profit.

This also makes sure that there are no statements after the
throwing statement, since these would be dead code. There
were a surprising number of places with assertions after
the throw, and none of these are actually triggered in tests
ever. When I found these, I replaced them with try/catch/rethrow
which makes the assertions actually happen:

before:

// This is the ExceptionRule that checks EppException marshaling
thrown.expect(FooException.class);
doThrowingThing();
assertSomething();  // Dead code!

after:

try {
  doThrowingThing();
  assertWithMessage("...").fail();
} catch (FooException e) {
  assertSomething();
  // For EppExceptions:
  assertAboutEppExceptins().that(e).marshalsToXml();
}

To make this work, I added EppExceptionSubject.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135793407
2016-10-11 11:27:54 -04:00
cgoldfeder
096877f03e Unify two exceptions that mean the same thing
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
2016-09-26 13:21:54 -04:00
mcilwain
21a98b899c Replace loadByUniqueId() with methods that don't overload unique id
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
2016-09-26 13:20:22 -04:00
cgoldfeder
1b34f1e326 Flatten the domain transfer flows
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133906420
2016-09-22 14:30:05 -04:00
cgoldfeder
5098b03af4 DeReference the codebase
This change replaces all Ref objects in the code with Key objects. These are
stored in datastore as the same object (raw datastore keys), so this is not
a model change.

Our best practices doc says to use Keys not Refs because:
 * The .get() method obscures what's actually going on
   - Much harder to visually audit the code for datastore loads
   - Hard to distinguish Ref<T> get()'s from Optional get()'s and Supplier get()'s
 * Implicit ofy().load() offers much less control
   - Antipattern for ultimate goal of making Ofy injectable
   - Can't control cache use or batch loading without making ofy() explicit anyway
 * Serialization behavior is surprising and could be quite dangerous/incorrect
   - Can lead to serialization errors. If it actually worked "as intended",
     it would lead to a Ref<> on a serialized object being replaced upon
     deserialization with a stale copy of the old value, which could potentially
     break all kinds of transactional expectations
 * Having both Ref<T> and Key<T> introduces extra boilerplate everywhere
   - E.g. helper methods all need to have Ref and Key overloads, or you need to
     call .key() to get the Key<T> for every Ref<T> you want to pass in
   - Creating a Ref<T> is more cumbersome, since it doesn't have all the create()
     overloads that Key<T> has, only create(Key<T>) and create(Entity) - no way to
     create directly from kind+ID/name, raw Key, websafe key string, etc.

(Note that Refs are treated specially by Objectify's @Load method and Keys are not;
we don't use that feature, but it is the one advantage Refs have over Keys.)

The direct impetus for this change is that I am trying to audit our use of memcache,
and the implicit .get() calls to datastore were making that very hard.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131965491
2016-09-02 13:50:20 -04:00
mcilwain
aa2f283f7c Convert entire project to strict lexicographical import sort ordering
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127234970
2016-07-13 15:59:53 -04:00
Michael Muller
c458c05801 Rename Java packages to use the .google TLD
The dark lord Gosling designed the Java package naming system so that
ownership flows from the DNS system. Since we own the domain name
registry.google, it seems only appropriate that we should use
google.registry as our package name.
2016-05-13 20:04:42 -04:00
Justine Tunney
5012893c1d mv com/google/domain/registry google/registry
This change renames directories in preparation for the great package
rename. The repository is now in a broken state because the code
itself hasn't been updated. However this should ensure that git
correctly preserves history for each file.
2016-05-13 18:55:08 -04:00
Renamed from javatests/com/google/domain/registry/flows/domain/DomainTransferApproveFlowTest.java (Browse further)