This is very much a "just make it work" type of patch. The main issues
were:
- A bunch of type errors in the `index.test.ts` file when opened in VS
Code. I'm not sure how it happened, but it's possible I'm just using a
more recent TS compiler than whoever edited this last.
- `localhost`, on my machine at least, resolves to `::1`, and therefore
the connections were just not established. I've opted for replacing
`localhost` with explicit `127.0.0.1`.
- `npm-cli.js` was not an executable in my `PATH`, and won't be for
most users, but `npm` is not on our testing infrastructure's `PATH`.
Those tests are obviously not tested by CI, so please review carefully /
test this on your own machine before approving.
CHANGELOG_BEGIN
CHANGELOG_END
* Adapt the setup script to show how you can create/get parties on canton
* address review comments
* Update templates/create-daml-app/daml/Setup.daml
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update templates/create-daml-app/daml/Setup.daml
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update templates/create-daml-app/daml/Setup.daml
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update templates/create-daml-app/daml/Setup.daml
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* address review comments
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
I don’t own this, it’s broken and other people don’t want to fix it
for 2.0 so this PRs deletes it instead of shipping broken code.
fixes#13045
changelog_begin
changelog_end
Complements #12952 which drops it from create-daml-app by also
dropping it from the rest.
Couldn’t find any docs or other stuff that is broken by this.
changelog_begin
changelog_end
... so that Navigator shows users for login by default.
When parties are specified explicitly in daml.yaml,
navigator uses those instead of querying user management
for the list of users a user can log in as.
These days, it actually doesn't make sense to list the
parties in the daml.yaml. Navigator will query party
mgmt for a list of known parties. We don't implicitly
allocate parties (anymore), so unclear why this section
is still here.
The users for the template are created by the init script
(see Setup.daml).
See #12945
CHANGELOG_BEGIN
CHANGELOG_END
* Support getting started guide on Daml Hub
This is annoyingly complex so let me try to provide an explanation for
the changes:
1. On Daml hub, we need to use a separate token for the public party
and the user party.
2. This means that we need separate contexts. I cannot get access to
the default context (not exposed) so annoyingly even for the user context we need to
use a custom context
3. The way to get access to the public party in Daml hub is via a
hook that reads it from the context. However, we cannot call that
within the login callback so the way things work now that we login
immediately show a "Logging in..." loading screen while we run the
background query. This is actually kinda nice since it means
something happens immediately after clicking login.
I’m sure there are better ways of handling this, my react foo is very
weak but this is what I managed to get to work.
Tested locally as well as on Daml hub and both work fine.
changelog_begin
changelog_end
.
.
.
.
.
.
.
* s/any/void/
* fmt
* Create alias contracts in frontend in create-daml-app
Creating them in the setup script is nice but it makes it much harder
to port this to Daml hub where we cannot rely on this.
This also requires figuring out the public party in the frontend.
I’ve chosen to infer it from the user rights which seems broadly
sensible.
For the backwards compat mode, I just hardcoded it because there isn’t
a great way to figure it out.
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* Drop uniqueness from user aliases
We cannot support this on Daml Hub or multi-domain Canton so dropping
it seems more reasonable unfortunately.
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* Bump Canton and reenable tests
fixes#12808
changelog_begin
changelog_end
* display names are no longer defaulted
changelog_begin
changelog_end
* topology-change-delay is redundant
changelog_begin
changelog_end
* Switch away from grpcurl
changelog_begin
changelog_end
* try to fix canton conformance tests
changelog_begin
changelog_end
* that’s not how you scala
changelog_begin
changelog_end
changelog_begin
Ledger API Specification: CreateUser and GetUser endpoints of UserManagementService now return the CreateUserResponse or GetUserResponse messages, whereas previously they were returning the User message).
changelog_end
Sadly most of these changes are not actually related to Canton but the
previous docs were already broken primarily because of the patch file
not making all the required changes.
I got the patch file as close as possible to the `messaging.patch` to
make it easier to keep them in sync. The fact that we have two patch
files that duplicate most of the code is something that we really need
to fix but not in this PR.
changelog_begin
changelog_end
CHANGELOG_BEGIN
Ledger API Specification: Maximum number of user rights per user is now limited to 1000 and is added to UserManagementFeature in VersionService. getLedgerApiVersion endpoint.
CHANGELOG_END
We add a `useUser` hook to daml-react returning the user currently
logged in the ledger participant. create-daml-app is changed
accordingly.
CHANGELOG_BEGIN
[daml-react] A `useUser` react hook is added to the daml-react
TypeScript library. It allows for easy access to the currently logged in
user of a ledger participant node for ledgers supporting user
management.
CHANGELOG_END
* create-daml-app: Use alias templates for display names
We introduce Alias contracts to the create-daml-app Daml model and use
them to display aliases in the UI instead of party identifier strings.
CHANGELOG_BEGIN
CHANGELOG_END
* fix tests
* addressing review
* Add comments to Setup.daml
* factor out alias to option conversion
CHANGELOG_BEGIN
CHANGELOG_END
* small fix in setup.daml
* replace user dropdown with input in login screen
* fix compatibility tests
* fix alias loading flick in mainscreen
* remove canton incompatible sandbox options from daml.yaml
* fix gsg-trigger.patc
`alert` isn’t exactly great error handling but matches what we do in
other places of create-daml-app and I’m not all that keen on reworking
that everywhere for 2.0
fixes#12275
changelog_begin
changelog_end
* user management: require `daml_ledger_api` scope in user access tokens
The accesss token's scope must include `daml_ledger_api` to ensure
that access token was issued for accessing the Daml ledger api.
CHANGELOG_BEGIN
CHANGELOG_END
* Error handling for User Management exposed via daml-script
changelog_begin
changelog_end
adapt ScriptTest.daml to new user-management interface
adapt create-daml-app Setup.daml to new user-management interface
* Add deriving Ord for UserId
* change example of invalid user-id char to "%" from "." (which is no longer illegal)
* recover/reify ALREADY_EXISTS from GrpcLedgerClient.createuser
* fix testcase expected order of users from daml-script listUsers
* adapt create-saml-app Setup.daml to changed interface of user-management
* reinstate sort lost in merge
* sort user in ScriptService user-management test
* improve comment for error foobar hack
* improve doc comment for validateUserId
* use upper case as test example for invalid user-id
* Make quickstart-java template work with canton
Also update the quickstart-java release test instructions to use the new sandbox. This is a bit more involved than before, because of the party names being different every time, but I hope this is not too much of a burden. The test here is similar to what gets tested in the assistant integration test for quickstart-java.
changelog_begin
changelog_end
* try to fix indentation
And change the relevant release test instructions to make it clear this
isn't a quickstart-java project, but a project that uses the default
template (skeleton).
changelog_begin
changelog_end
* Rename daml sandbox to daml sandbox-kv
Also drop the default sandbox on `daml start`
Part of #11831
changelog_begin
changelog_end
* update release test instructions
* try to fix a couple compat tests
* dont need special 0.0.0 logic
* buildifier-fixx
Somewhat error-prone, so please review carefully.
Reasons we need this:
- Some file types are not properly handled by the script.
- The only exclusion mechanism we currently have (`NO_AUTO_COPYRIGHT`)
is overly coarse.
CHANGELOG_BEGIN
CHANGELOG_END
* Get rid of deprecated components
Removes:
- mentions of the Node.js bindings
- mentions of the Scala bindings
- usage of the Scala codegen as an SDK tool
- Java bindings "reactive components"
changelog_begin
The Node.js bindings are no longer supported as part of the Daml SDK
The Scala bindings are no longer supported as part of the Daml SDK
The Java bindings reactive components are no longer supported as part of the Daml SDK
The `daml codegen` command has dropped support for Scala
changelog_end
* Fix typo noticed by @cocreature
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Address https://github.com/digital-asset/daml/pull/12167#issuecomment-995714093
* Remove quickstart-scala from the SDK tarballs
* Fix failing codegen test
* Address https://github.com/digital-asset/daml/pull/12167#pullrequestreview-833991243
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
See #11358.
CHANGELOG_BEGIN
- [@daml/react] Our React bindings now request the `react` library as a
peer dependency, and will accept React 17 in addition to the current
React 16. For new projects, the `create-daml-app` template now uses
React 17.
CHANGELOG_END
* Initial work-in-progress
changelog_begin
[TS bindings] When using daml-react and daml-ledger, all streaming request to the query endpoint will be multiplexed through a single web socket.
changelog_end
* Minor touches, renaming
* Handle offsets received from the JSON API
* Create state array once per downstream consumer
* Handle reconnections as streamSubmit does
* Don't share mutable state between events
* Fix compilation errors
* Remove language-support/ts/package-lock.json
* Remove --downlevelIteration option, materialize iterators, fix one test
* I will refrain from commenting on the meaning of `this` in JavaScript
* WebSocket does not have a removeAllListeners method
* Remove unnecessary docstring from `handleQueriesChange`
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670441680
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670427941
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670448474
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670473307
* Fix some failing tests and linting fixes
* fix reconnect on server close test
* fix failing tests in test.ts and create-daml-app tests
* Update language-support/ts/daml-ledger/index.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.test.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.test.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* changes based on code review comments
Co-authored-by: Akshay <akshay.shirahatti@digitalasset.com>
Co-authored-by: akshayshirahatti-da <86774832+akshayshirahatti-da@users.noreply.github.com>
* Factor out npm install step of create-daml-app tests
This PR speeds up the create-daml-app tests by 30s or so by factoring
out the install of the unchanged npm deps into a genrule which we then
feed in again. This is a bit ugly but given how frequently we run
those tests I do think it is worth the uglyness.
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
We’ve seen this timeout a few times on CI. The version in the compat
tests already has a 60s timeout and that seems to work better so
here’s to hoping this helps.
I’ve also added some logs to see where it stops if it times out
again (jest hides console.log by default which is why this uses
console.debug by default).
changelog_begin
changelog_end
On Windows, we run without a sandbox, which means that the `gsg-trigger`
folder might already exist and be patched, because we work directly in
the source tree.
This changes the script to work with temp dirs instead.
CHANGELOG_BEGIN
CHANGELOG_END
As I was adding support to a sample app for the third time, I decided I
might as well clean it up a bit and add support for everyone.
This is completely optional, activated by (build-time) environment
variables, and should be trivial to remove for users who don't care
about it. In an ideal world we'd have options to `daml new` and this
would be one, but I think adding it out-of-the-box is a better
alternative than letting people figure this out on their own.
CHANGELOG_BEGIN
- The `create-daml-app` template now includes support for a third
authentication scheme (in addition to the existing "dev mode" and Daml
Hub support): Auth0.
CHANGELOG_END
The current README dates back to when `create-daml-app` was its own
repo, and seems mostly written from the perspective of being the default
home page for the project. These days, `create-daml-app` serves two
purposes:
1. As the core starting point for the Getting Started Guide, we can
assume people who are totally new to Daml will be following the
getting started guide. How else would they even know about this
template? In that case, I think it's fair to assume the user will *not*
be looking to the README for guidance. Therefore, repeating the
documentation here seems a bit pointless.
2. As a template to quickstart the creation of a "custom" app that is
not the GSG. For that use-case, the README is the place where people
would look for information, but at that point the information they're
looking for are more along the lines of quick refreshers of what
commands to run than explanations on how to use the app as Alice and
Bob.
CHANGELOG_BEGIN
CHANGELOG_END
It currently has all it needs for the docs to build, but not quite for
people to use it as a useful result of the triggers docs page: without
the UI components, it's hard to see anything the triggers are supposed
to do.
CHANGELOG_BEGIN
CHANGELOG_END
* rewrite trigger docs to follow gsg
Per #10419 point 4, I've rewritten the Triggers section to build upon
the Getting Started Guide instead of inventing its own example.
Compared to #10395, this has a lot more explanations as this page must
now serve the dual purpose of being a possible "next step" from the GSG
and being the main reference page for triggers. It's also lost the "next
steps" section, which I think is a bit of a shame, but it doesn't really
make sense here.
There's also no easy way for people not interested in the GSG to follow
along; should we expose the "completed GSG" as a tempate?
CHANGELOG_BEGIN
CHANGELOG_END
* keep copy-trigger as a template
* fix copy-trigger project name
* make up gsg-trigger template
* remove awkward sentence, fix existing typo
* update code to use when{,Some}
* add to
* swap emitCommands and getCommandsInFlight
* typo
* insist on state-correction perspective
* fix copy-trigger tests
* add back copy-trigger to whitelist
* add gsg-trigger to whitelist
When opening #10342 I was only aware of the `.gitignore`; @cocreature's
comment made me find out the `.dlint.yaml`, and then, testing it, I
realized we ended up with the ignore rule twice. It does not seem to be
causing any issue in cursory tests, but still, I think it's worth
cleaning up.
CHANGELOG_BEGIN
CHANGELOG_END
