feat: relateBy

@jasonkuhrt @Weakky Hey again :bowtie: This change is not ready to be merged yet, but the core functionality is unit tested and I'm already consuming it from our app on our forked package, so I figured I'd create a PR just to get some early feedback on the concept. The best way to explain it is probably a short example.
Starting from this schema.prisma:
model Tag {
  id   Int    @id
  user User
  name String
  @@unique([name, user])
}

model Selector {
  id  Int    @id
  css String
}

model Step {
  id       Int      @id
  action   String
  selector Selector
  value    String
  tests    Test[]
}

model Test {
  id    Int    @id
  user  User
  name  String
  steps Step[]
  tags  Tag[]
  @@unique([name, user])
}

model User {
  id        Int        @id
  email     String     @unique
  password  String
  first     String
  last      String
  steps     Step[]
  selectors Selector[]
  tags      Tag[]
  tests     Test[]
}

A mutation like t.crud.createOneTest() would result in an API that could be used like this:
    mutation createTest {
        createOneTest(
            data: {
                name: "Test 1"
                tags: {create: [{ name: "critical" }]}
                steps: {create: [{
                    action: "click"
                    value: "something"
                    selector: { create: { css: "#someId" } }
                }}}
            }
        ) {
            id
        }
    }

While it's nice that it's autogenerated, if the API was defined manually it would probably be much cleaner. If I want is to pass an object that looks like a "Test" as it is represented in my app and have the server create it, I have to manipulate the data to include "create" keys in all the right places first. With the ubiquity of "create" and "connect" in mind, I've built an "upfilterKey" option that can be passed to a resolver like t.crud.createOneTest({upfilterKey: "create"}) for a much more natural API:
    mutation createTest {
        createOneTest(
            data: {
                name: "Test 1"
                tags: [{ name: "critical" }]
                steps: {
                    action: "click"
                    value: "something"
                    selector: { css: "#someId" }
                }
            }
        ) {
            id
        }
    }

Passing "upfilterKey" creates new InputTypes like "TestCreateCreateOnlyInput" so other input object types aren't polluted and the changes are contained to a single resolver. Additionally, to ensure at runtime Photon still gets the right args, the "create" keys that were removed from the GraphQL input type are recursively injected into the data the resolver receives. You could theoretically pass in any key, although I've mainly been thinking about "create" and "connect". I think especially in conjunction with my "computedInputs" change (https://github.com/prisma-labs/nexus-prisma/pull/540), this allows many apps to get up and running with a clean API without writing any of the resolver logic themselves which is a huge win.
Bear in mind this change relies heavily on the recursive data population logic implemented in my computedInputs change, so the diff with master won't reflect that actual changes until that PR is merged, but in the meantime I'd love to hear any thoughts you have on the concept as I'm testing the new functionality over the next few days with my own app so I can adjust as necessary to align with your vision nexus-prisma. Thanks again for all your work, and happy holidays! :santa:

Hey @ssalbdivad thanks for this.
A feature that would support being able to disable/enable connect/create is something we've had in the backlog for some time now. Like computed inputs we saw it as something local and global.
// Disable connections for all relational fields in `Test` object
t.crud.createOneTest({ connectable: false })

// Enable connections only for `Test.A` and `Test.B`, disabling all others
t.crud.createOneTest({ connectable: ["A", "B"] })

// Disable connections only for `Test.A` and `Test.B`, enabling all others
t.crud.createOneTest({ unconnectable: ["A", "B"] })

// Disable nested creates in the whole api
nexusPrisma({
  crud: {
    nestedCreates: false
  }
})

Then, in situations where only connect or create would be available (not both, as is the case today), the input typings could be flattened, with only one kind left, it being then implied.
We could consider additional patterns, like expressing "take away connect but leave create as an explicit field".
What would you say are the advantages to your proposal? IIUC it permits "lifting" a level of schema config up? But I don't really understand what happens if there are peer fields in the level being removed. E.g.:
                    a: { b: { d: "fib" }, c: "fob" }

What does upfilterKey: "b" mean then? Maybe this:?
                    a: { d: "#someId", c: "bar" }

?

@jasonkuhrt
Applying upfilterKey: "b" to a mutation whose data would have otherwise been:
a: { b: { d: "fib" }, c: "fob" }

would result in
a: { d: "fib" }

It completely removes the peer fields from the input type and they are never repopulated. As you can imagine, this would cause problems once the resolvers needs to interact with photon if all peer fields are not optional. I've really only considered the "create" and "connect" case, but figured I'd implement the functionality generically as limiting input values or changing the way the option is passed to something like createOneTest({createNested: true}) would be trivial. There is not currently logic that exists that checks when a key is upfiltered whether all of its peers are optional, but it would also be straightforward to throw an error in case one or more is non-nullable.
I like being able to limit which fields get upfiltered based on strings that are passed in. What about an object like this:
t.crud.createOneTest({nestedRelations: {A: "create", B: "connect"}})
That would allow any combination with a single arg, which we could supplement with shortcuts like:
createOneTest({createNested: true})
createOneTest({connectNested: true})
When all nested types should be handled the same.

Yeah I think a specialized settings system for CU relations connect/create is a reasonable abstraction. We have to date multiple requests for the use-case and no more general leak-free solution than a direct settings approach. Considering how particular this feature (connect/create) is of CU I think correspondingly particular config isn’t so bad.
Of course I’m open to more general (but always leak free of course) approaches in the future.
I will loop back with some more refined spec work riffing on your points too.
Sent with GitHawk

I was referring to CU before but I don’t see why D is not worth consideration. Related: https://github.com/prisma-labs/nexus-prisma/issues/565.
If Photon does not have any features around the D then we may not be ready to tackle the subject at this level.
Just noting if nothing else.
Sent with GitHawk

@jasonkuhrt This feature has been a big improvement so far in terms of the API-quality of our autogenerated resolves. As soon as you let me know how you'd like the specified I'll finalize this PR!

Related https://github.com/prisma-labs/nexus-prisma/issues/518

@jasonkuhrt @Weakky Any additional thoughts on the API? Are we comfortable moving forward with something like this?
createOneTest({nestedRelations: {A: "create", B: "connect"}})
createOneTest({createNested: true})
createOneTest({connectNested: true})

I've been happily consuming my "upfilterKey" implementation for the last few weeks and would be fine continuing to do that, but I just spent a fair bit of time resolving merge conflicts on this branch and would love to avoid doing so again. I can have a PR ready within a day of getting confirmation on the API.

@jasonkuhrt @Weakky Had a chance to think about the API suggested above yet? Just want to make sure if more work is being done I don't end up going through another round of conflicts.

@jasonkuhrt @Weakky I built this feature because it felt like without it, I couldn't get an API that wouldn't make devs cringe without writing custom input types for all of my mutations. The flexibility of "create" and "connect" make lots of sense for photon as a DB interface but are terrible for a public API. I suspect I am not the only one who has started using nexus-prisma, been super impressed by the idea that you can create an API server from a simple model, and then let down when they realize the API you get by default isn't clean enough to commit to. I suspect at that point, many of them either wrote a bunch of custom input types and resolvers, negating much of the benefit of nexus-prisma, or switched to another tool entirely. I genuinely love prisma and its commitment to DX and open source so I figured I'd solve the problem I was having by contributing to your project as opposed to doing one of those things or building my own solution. However, I don't feel the experience I've had is in keeping with those values. It's often been challenging to get a response, even to let me know when to expect to hear back, which sucks when I feel like I've done a lot of work to build a feature that I believe is critical to achieving nexus-prisma's goals and am just asking for the API the team wants so I can accommodate you. I get how much pressure there can be from every direction when you work in software, but I don't think it's fair not to prioritize communicating with devs who are working on your project for free and I hope as a company rooted in open source prisma feels the same.

@ssalbdivad Extremely busy on many things right now but we finally got to this PR:

I think in the future it could be great to have you on these design calls. Let me know if you're open to such a thing.
We came up with a design that unifies in a sense (you'll see) your two features, computedInputs and upfilterKey.
The API surface is sufficiently different that we will create a new issue to lay out the proposal. It will clearly point to this and your previous PR as the original work on the subjects.
We're pretty happy with where we landed, and looking forward to feedback generally but also especially yours.

@jasonkuhrt Sure I'd be happy to jump on a call for something like this. Luckily, I've already taken an approach that unifies the way computedInputs and relation logic are handled :smile: I'm sure it won't match your API exactly, but hopefully we can get there without fundamentally refactoring anything as for the most part that's already been done!

Hey @ssalbdivad if we can align on enough of the issue linked by GH just above I think we then define a small increments of it you want to chew off in this PR and aim to merge soon.
Sent with GitHawk

@jasonkuhrt Added some feedback! I'd like to get a PR up that includes resolver-level and plugin-level configs for computedInputs and the relations config. I've refactored the way computedInputs are handled during typegen and when transforming GraphQL inputs for prisma (which occurs at runtime). My goal was to create a scalable strategy for managing these kinds of overridable input configs that are applied recursively.
I'd recommend the following be handled by separate PRs:

Migrating other configs like ordering and filtering to this model
Adding support for model-level configs. I think this should be straightforward with the new unified implementation of plugin-level and resolver-level configs that sandwich it in terms of precedence/specificity, but, like you, I'd love to get a functional subset of what you laid out merged ASAP :bowtie:

Hey @ssalbdivad, wish we'd found a clear path forward by now but seems we're still a step or two away from alignment. From your side, based on the latest proposals you've seen, do you think you can find a minimal version of this PR that is a kind of "common denominator" so far?
I would like to start some serious refactoring of this library, in part because the upgrades we do to follow new Prisma 2 releases are becoming costly with status quo. We'll need some arbitrary control over the codebase back but I don't want to wreck havoc on your work/PR here.
So hoping we can get something merged here, just a step forward, then keep discussing while internally we may start to overhaul the codebase.

@jasonkuhrt I appreciate the consideration re: the other refactoring work that needs to be done. I think I've found a reasonable path forward and hope to finish up this PR today. Will keep you posted!

@jasonkuhrt So I had a working version of the new relateBy & computeFrom functionality with new unit tests, but I'm not sure what's going on with imports after merging master. I get the following error when trying to run unit tests now:
ts TypeError: PrismaClientGenerator.getDMMF is not a function
Perhaps you could advise on how to resolve this? In the meantime, I've written up some new summary documentation for the inputs config API I built, which currently supports configuration at the plugin and resolver levels:
Transform your Prisma Inputs into a Clean GraphQL API
// Create an object that maps field names to configs.
const inputsConfig = {
  /*
    Removes Prisma fields named "user" from affected input types
    and infers their values from context at runtime.
  */
  user: {
    computeFrom: ({ args, ctx, info }) => ({ connect: { id: ctx.userId } }),
  },
  /*
    Removes the "create/connect" input type for fields named "blog" and
    the corresponding layer of the API, replacing it with a connect-only type.
  */
  blog: {
    relateBy: 'connect',
  },
}

/*
  This config can be applied globally, affecting fields across all input types
  that are passed to the config.
*/
nexusPrismaPlugin({
  inputs: inputsConfig,
  /*
    Sets the default relateBy value globally. If unset, the default value
    is "any", which preserves the "create/connect" layer from Prisma's API.
    "relateBy" values passed to individual inputs always have a higher
    precedence than those passed directly to a config like this one,
    even if the config-level relateBy has a more narrow scope.
  */
  relateBy: 'create',
})

/*
  The same config can be applied to a resolver. This will override the global
  config and will not affect input types outside of the resolver to which
  it is passed.
*/
mutationType({
  definition(t) {
    t.crud.createOnePost({
      inputs: {
        blog: {
          /*
            This overrides the relateBy value for the 'blog' field that was
            passed globally.
          */
          relateBy: 'create',
        },
      },
      /*
        Override the default relateBy for the resolver. For example,
        if the global default is 'create', you might pass 'any' to allow
        both create and connect by default.
      */
      relateBy: 'any',
    })
  },
})

Without the above inputs config:
mutation createOnePost {
  createOnePost(
    data: {
      title: "Automatically generate clean APIs with nexus-prisma!"
      blog: {
        create: {
          name: "Redo your expectations"
          url: "https://redo.qa"
          user: { connect: { id: 1 } }
        }
      }
    }
    user: { connect: { id: 1 } }
  )
}

With inputs config:
mutation createOnePost {
  createOnePost(
    data: {
      title: "Automatically generate clean APIs with nexus-prisma!"
      blog: { name: "Redo your expectations", url: "https://redo.qa" }
    }
  )
}

I've tried to build this in a way that should allow it to be expanded to eventually handle other scopes (e.g. model) and configs like ordering, filtering, etc.
I was consuming my upfilterKey changes through a custom package, but as of a few days ago that no longer works even with old versions of prisma. Seems like something went wrong with semver since I use exact versions and didn't upgrade. Regardless, getting this change working with the latest prisma and merging it is my highest priority right now since it seems like it will unblock both of us :bowtie: Let me know your thoughts!

👋  Hey, I was advised to post a use case here from the Slack channel.
I think the ability to have the inputsConfig feature in this PR apply to filterable queries would also be incredibly useful. Currently, I find the read CRUD generated with nexus-prisma to be unusable for anything other than prototyping as all my queries need a tenant, user, or other limiting query based on context.
The ability to automatically compute XWhereInput based on context might prove useful for others who have applications with multiple tenants and users living in the same database.
My current example query would look something like this with the current API and filtering: true. However, it would be unsafe to call from the client, so my queries never actually use this API.
queryField((t) => {
    t.crud.posts({ filtering: true })
})

query posts(where:{ user:{ id: "abc" } }) {
    id
}

With the new proposed API I would much rather prefer to write something like this in my queries:
// Now, I'm no expert on API design or even quite familiar with the principles with which this
//  project's API is created so please treat this as purely concept
queryField((t) => {
    t.crud.posts({
        filtering: true,
        computedInputs: {
            where: { user: {
                computeFrom: ({ctx}) => ({ id: ctx.currentUser.id })
            } }
        }
    })
})

 # This is automatically limited by the computed input now and only fetches posts
# for the current user
query posts {
    id
}

@HokumGuru Thanks for the input, that makes a lot of sense. I'll take a look today at how much work would be involved in supporting computeFrom for queries. @jasonkuhrt @Weakky Any thoughts on the blocking issue I brought up? Like you, I'd like to get this merged ASAP :bowtie:

@jasonkuhrt @Weakky Could I get an update on this? I'm actually planning to give a talk about nexus-prisma at a GraphQL meetup in Boston on 3/4, so I'd love to resolve this last issue and have this merged by then :crossed_fingers:

Hey @ssalbdivad I currently still feel the API focuses too much on create operation, without addressing the overall set of CRUD operations in a wholistic  way. I don’t know if I have anything new to add over the comments last posted by @Weakky and I in the issue thread. A good next step night be a tech call to break the impasse?

About the dmmf error, this is probably due to the recent Prisma upgrade. I am on mobile right now, when I get a chance will see if I can spot the change needed here now to get it working again.

@jasonkuhrt

A good next step might be a tech call to break the impasse?
Sounds great. Email me at<EMAIL_ADDRESS>and we'll schedule it.

So hoping we can get something merged here, just a step forward, then keep discussing while internally we may start to overhaul the codebase.

Does this still apply? The scope of this PR is already massive and these features are opt-in. I don't see a great reason not to get it merged as soon as possible. Let me know when you have a chance to take a look at the DMMF error.

I don't see a great reason not to get it merged as soon as possible.

I think the main blocking issue right now is the relateBy api.

@jasonkuhrt How is relateBy blocking?

https://github.com/prisma-labs/nexus-prisma/issues/598#issuecomment-584045173
https://github.com/prisma-labs/nexus-prisma/issues/598#issuecomment-584235746

These comments were the last round of feedback from @Weakky and I. We were not/are not aligned on the relateBy API.

@jasonkuhrt I carefully considered that comment before finalizing my API proposal and justified the decision in the other thread:

After a lot of deliberation, I didn't end up moving forward with the relation toggle API because while building and consuming the new relations config, the easiest way to think about its effect was twofold:
Create a default relation type within some scope
Remove the API layer required to specify a relation type (currently, that API layer is an input object with create and connect keys, although it could have more in the future)
(1) is useful by itself for refining which relations you want to expose within some scope, but (2) is what makes the feature so compelling because it fundamentally improves your schema. In the quoted example, you can see how much cleaner an API call looks with these features, and I don't think the example is particularly contrived.
If we want to allow the removal of optional fields (like create and connect, but also others that have nothing to do with prisma relations), that could be a useful feature on its own. However, since the most important part of this relations-specific feature is (2), I'd offer that the config is more intuitive as a string representing the default relation as opposed to a map of relation types to booleans enabling/disabling them.

I never received any feedback on that. Further, in @Weakky's comment, he mentioned that:

we'll want to add options to the connect or create "relations" (or others because there's also delete, 'disconnect', update, 'upsert'...)

If that's true, it's even more critical to use something like relateBy as opposed to a set of toggles because to remove the relation layer from your API, the number of fields you'd have to configure would scale linearly with the number of relations we support. {relateBy: "upsert"} is significantly better than {creatable: false, connectable: false, deleteable: false} or something equivalent.
I think a boolean-based interface would be the right approach for a feature with the goal of enabling/disabling particular inputs, not selecting a default input and removing a layer of the API. That work should be handled separately.
You had said you were hoping we can get something merged here, just a step forward, then keep discussing. As mentioned, I'm happy to jump on a call with you, but I don't see why an ongoing design discussion should stop us from merging what we have with an "experimental" disclaimer in the documentation if you'd like.
Lastly, we haven't even started code review yet and this branch is already more than two months old and  65 commits ahead of master. I'm starting to feel hostage to this PR. It would be a huge relief to me if we could take the quickest path to an opt-in version of this feature like the one I built merged.

@jasonkuhrt @Weakky @schickling @nikolasburk
There's a conversation from earlier in this thread about the importance of responding to external contributors. I do not want to fork this repo or build my own plugin, but I am continuing to really struggle with the lack of support I'm getting after doing more work on this package than any other developer, internal or external, over the last few months.
Later today, I'm giving a talk evangelizing nexus-prisma and the prisma ecosystem at a Boston GraphQL meetup. Obviously, I was hoping to make this feature available by then. It seems like that's unlikely. Could I at least get confirmation we have a path towards merging the 65 commits that have already been put into this in the next few days?

@ssalbdivad just got off a call with @Weakky and the next steps are roughly as follows:

Get minimally upgraded to Prisma 2 preview 23 (minimal means working with current feature set, not supporting the new features of preview 23 yet)

Change how deps are structured so that tests hopefully become deterministic (they are not, master is failing right now where once it was passing)

(re)Build up context on this PR and see if we think a compromise between what you want and what we stated is within sight. If it is we'll offer to have a call and try to reach it.
If not we'll say so. Then I don't know what. I can speculate. We'd continue to focus on quarter goals and q2 planning where crud may be a big focus. If it is then we presumably start shipping fundamental improvements of the kind this PR is proposing. But it will be in the context of the nexus framework plugin.
Whatever happens we'll probably be refactoring to put the project into a healthier state.

@jasonkuhrt If you review the changes that are included in this PR, they go a huge way to putting the project in a better state. It would be a critical mistake to make other changes first that would make it more difficult to merge this.
I've spent hundreds of hours working on this feature. It is fundamentally unreasonable to offer no timeline for merging the work, even under an experimental flag, after asking me to "find a minimal version of this PR that is a kind of "common denominator" so far." You then said you were "hoping we can get something merged here, just a step forward, then keep discussing while internally we may start to overhaul the codebase."
I took all of the feedback I'd received into account and made a very clear case for why the API I've suggested is a good one. It may not be perfect, but I have spent an awful lot of time thinking about it and can't afford to wait any longer on this. If we don't have a path to merging this by Monday, I'm not sure how I can in good faith, recommend during my talk tonight that other developers interested in contributing to open source consider this project.
I'm begging you to reconsider this stance. Review the actual code changes. I promise you will find they vastly improve the state of this package.

@jasonkuhrt It could work exactly the same way it does for create/connect for any other relation type with a trivial change. The goal of the relateBy option is to allow users to remove the relation layer of their API and specify which relation's type is implicitly used in that case. This works exactly the way the original upfilterKey did:

Remove the layer of the API where a user specifies create/connect/updated/delete etc.
Substitute the input type of that particular relation for the removed layer.
Reinsert the relateBy key when passing the value to prisma.

E.g. for update:
mutationType({
  definition(t) {
    t.crud.updateBlog({
      inputs: {
        post: {
          relateBy: 'update',
        },
      }
    })
  },
})

Could transform something like:
mutation updateBlog {
  updateBlog(
    data: {
      title: "New Blog Name"
      post: {
         update: {
             data: {
                  name: "Redo your expectations"
                  url: "https://redo.qa"
             },
             where: {
                 id: 1
             }
         }
      }
    }
  )
}

mutation updateBlog {
  updateBlog(
    data: {
      title: "New Blog Name"
      post: {
         data: {
            name: "Redo your expectations"
            url: "https://redo.qa"
         },
         where: {
            id: 1
         }
      }
    }
  )
}

So it's totally agnostic to what relation is being modified. It's still really just "upfiltering" a type under the hood, but we're restricting its usage to relations we want people to be able to upfilter. I think this should be extremely flexible if we want to expand it to work with nested updates/deletes if we want to use it in the future and shouldn't require any major changes.

The granularity that would be offered by enabling/disabling any combination of optional fields would also be useful for other cases, and should in my view be handled separately by an "enabled" option that is made available on each input field through the same multi-level API I've built for this feature. Importantly, it's goal is fundamentally different and it wouldn't remove layers of your API, it would just remove optional types like delete and create to leave ````connectandupdate``` for example. Using this feature, users would still have to specify the relation type (or whatever other optional key they want to remove) as part of their input.

Good morning @ssalbdivad,
I have spent quite some time this morning retaking the whole context of this PR including its associated issue. I also checked-out your PR and tested it locally. Here are my findings:

I think the current API (and to be clear here, our proposal doesn't solve the problem either) has a fairly important use-case that it doesn't solve.

Let's consider this prisma schema:
model A {
  id          Int     @id @default(autoincrement())
  someField   String
  relationToB B
}

model B {
  id         Int      @id @default(autoincrement())
  someField  Int
}

Now let's customize the createOneA mutation
mutationType({
  definition(t) {
    t.createOneA({
      inputs: {
        someField: {
        }
      }
    })
  }
})

Nothing alarming but I encountered a bunch of stack overflow issues, probably due to infinite recursion in some cases.

On the blog example, the following statement break:
t.crud.createOneBlog({
  inputs: {
    posts: {
      relateBy: 'create',
    },
  },
})

Here is an example of the current crud operation update with regard to relation fields:

I'm trying to understand how relateBy is the right abstraction for the API author to customize the client-facing args here.

@Weakky and I landed on a near-final spec. It will be posted in a few hours in #598.

We found a design problem late in the spec, resolving took up @Weakky's end of day. Posting the spec will move to tomorrow.

@jasonkuhrt I really don't think this could be clearer. relateBy allows the user to specify that only one type of nested relation is allowed for a particular field, and in doing that allows the user to skip specifying the relation type explicitly when they provide an input object as I've shown many times. There is no flaw here, it is just a simple improvement. It may not handle every case, but it can easily be expanded in the future with a non-breaking change to, for example, toggle sets of relations on and off.
From your screenshot, it looks like since I started building this feature months ago, there are more relation types that are now available? Great, I can change the type to relateBy: "connect" | "create" | "set" | etc... and with a couple tweaks, this API handles that case perfectly, much better than the boolean based API that was suggested. You have not messaged me about scheduling a design call, so I'm not particularly enthused about being handed a new design after working hundreds of hours on this feature by two engineers who have tried to glean what they can from a PR without a discussion.
I am absolutely certain at this point that relateBy is the right way to specify a default relation for an API which is the goal of this feature. Most of the critiques have shown a fundamental lack of understanding of the issue.
If you need the type expanded to handle other relations like "set" that have been added more recently, I'm happy to do that because the code was written very flexibly. Please let me know.

@jasonkuhrt While I was developing this feature, relation input types that were generated had two fields: create and connect.
You said as much yourself in your first responses on this issue:
From https://github.com/prisma-labs/nexus-prisma/pull/566#issuecomment-568342237 :

A feature that would support being able to disable/enable connect/create is something we've had in the backlog for some time now.

This is the feature we talked about building. If there are more relations to support, I can easily adjust the type to cover them.
The most recent description I gave for relateBy's purpose is this:

relateBy allows the user to specify that only one type of nested relation is allowed for a particular field, and in doing that allows the user to skip specifying the relation type explicitly when they provide an input object

What is the design flaw there? And if there were a design flaw, would that be sufficient to avoid merging 100s of hours of work done on your project, including significant design improvements, under an experimental flag? It would be very easy for you to change that API later, as you've indicated a willingness to do many times in the past.
@Weakky  @nikolasburk  @schickling
This is an unacceptable standard for a relationship between an open source project and its contributors. For developers to be enthusiastic about using and contributing to your project, you need to fundamentally respect them and their opinions. I've been so excited about Prisma as long as I can remember; I literally gave a talk to a room full of developers about how great it was last night.
On this issue, I've yet to receive any meaningful description of a problem with the existing design. Would it be possible to get a couple of extra opinions before throwing away 100s of hours of work?

What is the design flaw there?

https://github.com/prisma-labs/nexus-prisma/issues/598#issuecomment-584045173
https://github.com/prisma-labs/nexus-prisma/issues/598#issuecomment-584235746
And the spec we'll post tomorrow that refines these

And if there were a design flaw, would that be sufficient to avoid merging

If you're willing to make the tweaks needed to align this PR with where we want the API to go, then that's great. That part is up to you. Looking forward to your thoughts after we post our refined proposal.

@jasonkuhrt I already responded to those concerns multiple times, most recently:
https://github.com/prisma-labs/nexus-prisma/pull/566#issuecomment-593146580
I did not receive feedback on any of that.

Our refinement posted tomorrow should serve as feedback then I think. On the other hand we don't feel our points have been addressed. Perhaps they were not clear enough.  It also helps that you now realize there are more operations than create and connect which was a significant factor in our thinking, but didn't connect with you then.

@jasonkuhrt  From the comment I linked:

In @Weakky's comment, he mentioned that:

we'll want to add options to the connect or create "relations" (or others because there's also delete, 'disconnect', update, 'upsert'...)

If that's true, it's even more critical to use something like relateBy as opposed to a set of toggles because to remove the relation layer from your API, the number of fields you'd have to configure would scale linearly with the number of relations we support. {relateBy: "upsert"} is significantly better than {creatable: false, connectable: false, deleteable: false} or something equivalent.

is significantly better than {creatable: false, connectable: false, deleteable: false} or something equivalent.

Indeed it would be. Our revised designs don't have this verbosity defect, if the previous ones did (not sure). This will be my last comment before we post our revisions. Again, looking forward to your thoughts about it.

@jasonkuhrt Added my comments on https://github.com/prisma-labs/nexus-prisma/issues/598. I'll quote part of that reply here:

there seems to be a lot of confusion around the relateBy API. @Weakky gives this example of how relateBy would be used:
import { mutationType } from 'nexus-prisma'
mutationType({
definition(t) {
t.crud.updateOneA({
inputs: {
someField: {
relateBy: ['create', 'delete', 'update']
}
}
})
}
})
I absolutely understand why you'd have a problem with that API. I'd like to again clarify that relateBy accepts a single string value (not an array) representing the default relation for a particular field. To be able to remove the inputObject that is needed to specify which relation to use from the API altogether, we need to have exactly one allowed relation, therefore string, not string[], is the correct data type to specify that relation.

You can imagine it is rather frustrating to see that after writing so many comments trying to explain the relateBy API and its advantages, the examples and critiques I received were not even applicable to the API I was suggesting.

For the getDMMF error, it should be fixed once you're on the latest version of prisma. @Weakky and @timsuchanek did some great improvements on the way the Prisma 2 binary is pinned by this package in the test suites such that it will now move in lockstep. All to say hopefully things will start to feel a bit more stable when it comes to tests. Whereas up until a few days ago new Prisma 2 releases could break master branch tests that once passed, no more will that happen.
I can't remember why we used require instead of ECMA modules. If it works great but maybe there's still a reason we have to use require.

@jasonkuhrt @Weakky I've added some new commits to get a workable version of this feature based on what we discussed. I ended up going with collapseTo & computeFrom as opposed to compact & computeFrom as it felt more intuitive based on the way the functionality behaved. Here is the updated documentation:
Transform your Prisma Inputs into a Clean GraphQL API
// Create an object that maps field names to configs.
const inputsConfig = {
  /*
    Removes Prisma fields named "user" from affected input types
    and infers their values from context at runtime.
  */
  user: {
    computeFrom: ({ args, ctx, info }) => ({ connect: { id: ctx.userId } }),
  },
  /*
    Searches for fields named "connect" within fields named "blog." As long
    as all siblings of "connect" are optional, replaces the input type of the
    "blogs" field with the input type of the "connect" field, collapsing the
    API to better accomodate its intended use (in this case, connecting existing
    blogs as part of an input as opposed to creating new ones).
  */
  blog: {
    collapseTo: 'connect',
  },
}

/*
  This config can be applied globally, affecting fields across all input types
  that are passed to the config.
*/
nexusPrismaPlugin({
  inputs: inputsConfig,
  /*
    Sets the default collapseTo value globally. If unset, the default value
    is null, which preserves inputs from Prisma's API. collapseTo values
    passed to individual inputs always have a higher precedence than those
    passed directly to a config like this one, even if the config-level
    collapseTo has a more narrow scope.
  */
  collapseTo: 'create',
})

/*
  The same config can be applied to a resolver. This will override the global
  config and will not affect input types outside of the resolver to which
  it is passed.
*/
mutationType({
  definition(t) {
    t.crud.createOnePost({
      inputs: {
        blog: {
          /*
            This overrides the collapseTo value for the 'blog' field that was
            passed globally.
          */
          collapseTo: 'create',
        },
      },
      /*
        Override the default collapseTo for the resolver. For example,
        if the global default is 'create', you might pass null to allow
        both create and connect by default.
      */
      collapseTo: null,
    })
  },
})

Without the above inputs config:
mutation createOnePost {
  createOnePost(
    data: {
      title: "Automatically generate clean APIs with nexus-prisma!"
      blog: {
        create: {
          name: "Redo your expectations"
          url: "https://redo.qa"
          user: { connect: { id: 1 } }
        }
      }
    }
    user: { connect: { id: 1 } }
  )
}

With inputs config:
mutation createOnePost {
  createOnePost(
    data: {
      title: "Automatically generate clean APIs with nexus-prisma!"
      blog: { name: "Redo your expectations", url: "https://redo.qa" }
    }
  )
}

Possible values for collapseTo are any of the field names that exist on input objects in the schema as well as null, which disables collapsing. Added some new tests for both computeFrom and collapseTo. Will address any PR feedback you have as soon as I receive it so we can merge ASAP. Thanks for your patience :heart:

Thanks @ssalbdivad excited to take a proper look soon!

@HokumGuru All inputs, including for queries, are now supported by both computeFrom and collapseTo.

Thanks @ssalbdivad. Right now we're thinking of doing a nexus-prisma focused sprint in Q2 where we'd merge this at the start and then roll out a series of progressive pre-release changes up to and finally a stable release.

@jasonkuhrt Currently I'm publishing and consuming a redo-nexus-prisma package that includes these changes, which is fine in the short-term. Obviously my biggest concern is needing to resolve any more merge conflicts. Any idea of when that sprint would take place and what work might happen on this package before then?

@ssalbdivad I would love for it to be in April. Our Q2 planning is the first week of April so we should discuss and hopefully decide then.

@jasonkuhrt Well I'll admit I'm a little disappointed given it's already been over a month since you said you wanted to merge this as soon as possible, but are we at least confident there won't be any more merge conflicts in the meantime?

@ssalbdivad only from updates to keep up with Prisma 2. They usually shouldn't be very disruptive. There were some recent changes because of the Nexus transition, but that's unique.

@jasonkuhrt Locally, I'm seeing two tests failing in field-resolution-test.ts after merging master. It also looks like for some reason prisma generate isn't being executed in CI which is causing other tests to fail? If you could provide guidance on resolving these issues that would be greatly appreciated.
Given the current situation is already causing problems, it would really mean a lot to me if we could prioritize getting this change merged. It represents a huge refactor and significant improvements for the package, so it seems like it would be logical to do make sure any ongoing work that is done accounts for it. I'm already publishing and using it end-to-end, but I'm concerned that future merge conflicts will only create more problems I don't have context on.
If now that the code has been reviewed, your team could find a way to prioritize merging this in the next week, that would mean a lot to me given the hundreds of hours of my time I've already contributed to this feature. Plus, it would very reliably get me off your back :bowtie:
Thanks,
David

Don't worry about the conflicts anymore, we can handle them when the time comes. It'll be easier this way for both sides I think.

@jasonkuhrt I've also been keeping prisma  and redo-nexus-prisma up to date with master, and am waiting on a few unrelated fixes. If I stop resolving conflicts I will fall behind :disappointed:

We're eying something like March 14 as the start of prisma plugin sprint. Updates for prisma 2 beta (🎉) will happen before. I guess you're feeling stuck between rock and hard place, so pick the least hard one I guess. Looking forward to putting you between pillow and soft place.

@jasonkuhrt @Weakky Is there a reason the README is now just a link to the new nexus framework docs page? None of the docs for this repo seem to exist anymore.

https://github.com/graphql-nexus/nexus-schema-plugin-prisma/issues/630

April 14 as the start of prisma plugin sprint.

Could I get a status update on this?

Could I get a status update on this?

@Weakky @jasonkuhrt I consulted with you over months and invested 100+ hours to build this feature.
Can you please provide a status update?

Hey David, unfortunately we're going to be closing down this PR. The underlying issue and ideas are not obsolete, but the timing isn't right anymore.
nexus-prisma has remained outside our team's focus longer than I anticipated with a roadmap I predicted poorly. t.crud has been even less of a focus, which we've just officially marked as experimental by having it disabled by default. None of this bodes well for your PR.
The underlying reasons for this outcome and my personal lessons are many, but the bottom line is you feel you wasted time and I'm sorry about that. I engaged this PR in good faith but ultimately it seems it was a net negative. I have no idea when we're going to seriously get back into t.crud. When we do though, we're going to need a fresh take, possibly rewriting or heavily refactoring the codebase.
My advice for you is if t.crud is important to you and your work then continue maintaining your fork. By now you probably know the current codebase better than us anyways and you are deeply aware of your product's needs.
You can reach out to @janpio if you wish to get more non-technical insight into the details of this decision. Again sorry I've let this go on so long. Best of luck!


Feature request: Specify BoundingBox rather than center Coordinates

Not really an issue, but it would make a nice addition if one could use bounding box to specify what area to stich rather than {latLng},{z},{w},{h}
Not sure if that is hard to implement, but figured i might as well ask!
Har'e gött!

Hej Edvin,
It wouldn't be too difficult to have an option to specify a bounding box given you omit the output image width and height.

True! Forgot to mention the W/H as part of my post


Starknet conversions aren't idiomatic

We should use From and Into traits instead

We should use From and Into traits instead

I don't think you can implement external traits for external types. E.g. when I try to impl Into<Felt252> for ClassHash> I get
error[E0117]: only traits defined in the current crate can be implemented for types defined outside of the crate

@MaksymilianDemitraszek that's why we did not implement it in the first place. Closing.

It is implemented using our own trait though, I don't really get the issue

Me neither, we analyzed the issue and don't see a clear solution to this

Best we could do is probably
let class_hash: ClassHash = felt.into_();
let class_hash = Into_::<ClassHash>::into_(felt);
let class_hash = ClassHash::from_(felt);

or
let class_hash = Into::<ClassHashWrapper>::into(felt).get();
let class_hash = ClassHashWrapper::from(felt).get();

but I don't think it's any better than the current state

@Arcticae @drknzz Using generic is much better as you can implement converstions selectively and you can use single method for that.
thus you can do
impl IntoSt<Felt252> for FieldElement {
    fn into_(&self) -> Felt252 {}

instead of having a giant trait for every type
having a function for every type is anti pattern, generics exists for a certain reason.


Missing information on connectivity and how to run the sql script

Hello,
It is not clear from the start what account you should be connecting to run the scripts. I am not sure if I should log in the SQL using the admin or regular user? or when should I run the queries on the 'master' database vs another database. Can you specify this in your guide?
Thanks

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4a94f4ea-0f0d-2e8c-7246-189cd0201dcd
Version Independent ID: 7adf540e-c5a9-5e3f-cf4f-bc598f68ba3e
Content: Tutorial load data from Azure Data Lake Storage - Azure SQL Data Warehouse
Content Source: articles/sql-data-warehouse/sql-data-warehouse-load-from-azure-data-lake-store.md
Service: sql-data-warehouse
Sub-service: load-data
GitHub Login: @kevinvngo
Microsoft Alias: kevin

@cesarfloressuazo  Thank you for the feedback.
This is being assigned to the content author to evaluate and update as appropriate.

Fixed the doc. PR: 106481

#please-close


Bug, Sell advice when already filled to buy, but gekko still say there buy order.

Note: this is the technical bug tracker, please use other platforms for getting support and starting a (non technical) discussion. See the getting help page for details.
**I'm submitting a ...error bug
[x ] bug report
[ ] question about the decisions made in the repository
Action taken (what you did)
restart gekko for for correct again.
Expected result (what you hoped would happen)
reading portofolio for last buy order from binance.
Actual result (unexpected outcome)
buy order already filled, and first is correct last buy order in binance market :

2018-09-23 16:51:13 (DEBUG):	[ORDER] statusChange: SUBMITTED
2018-09-23 16:51:14 (DEBUG):	[ORDER] statusChange: OPEN
2018-09-23 16:51:15 (INFO):	[ORDER] partial buy fill, total filled: 3208
2018-09-23 16:51:15 (DEBUG):	[ORDER] statusChange: FILLED
2018-09-23 16:51:17 (ERROR):	Error while creating summary: Error: Trades not found
at get (/root/gekko/exchange/wrappers/binance.js:365:23)
at checkFn (/root/gekko/exchange/exchangeUtils.js:23:16)
at /root/gekko/exchange/wrappers/binance.js:129:12
at Request.request [as _callback] (/root/gekko/exchange/node_modules/binance/lib/rest.js:100:21)
at Request.self.callback (/root/gekko/exchange/node_modules/request/request.js:185:22)
at emitTwo (events.js:126:13)
at Request.emit (events.js:214:7)
at Request. (/root/gekko/exchange/node_modules/request/request.js:1157:10)
at emitOne (events.js:116:13)
at Request.emit (events.js:211:7)
at IncomingMessage. (/root/gekko/exchange/node_modules/request/request.js:1079:12)
at Object.onceWrapper (events.js:313:30)
at emitNone (events.js:111:20)
at IncomingMessage.emit (events.js:208:7)
at endReadableNT (_stream_readable.js:1064:12)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickCallback (internal/process/next_tick.js:180:9)
2018-09-23 16:51:28 (DEBUG):
Current market: bear
Percent change predicted: -0.15861826809892832
Current price: 0.000567
Last buy price: 0.000565

And gekko send advice to sell after buy filled succesfully ( i see in the last buy order at binance and correct if gekko make buy order and filled) then here is the problem :

2018-09-23 17:21:29 (INFO):	Received advice to sell however Gekko is already in the process to buy
2018-09-23 17:21:29 (INFO):	Canceling buy order first
2018-09-23 17:21:29 (DEBUG):

and now still continue.
the strategie i'm using is NNv2.
sory for my bad to explain the bug.
Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc)
i'm using latest version of gekko:
Using Gekko v0.6.6 and Gekko UI v0.2.3.

already at the latest develop branch.. thanks for your works ... restarting gekko again now..

Hi @askmike,
I'm running Gekko via UI, I have a live tradebot configured and started through the interface, and I've just encountered the error above.
My question is: If I simply leave it running, does it recover from the error and continue trading? I see the logs continue to periodically show "syncing private data" which I assume are my balances, orders, trades, etc. so it should have up-to-date information at this point. Correct?
Conversely, if it doesn't recover and I need to restart it, is it enough to just kill the node process and rerun "node gekko --ui"?
Thanks in advance!

If I simply leave it running, does it recover from the error and
continue trading?

No it doesn't, it won't do any more trades. But I want to focus on fixing
the error that causes this first!
On Tue, Sep 25, 2018 at 9:50 PM dgghita<EMAIL_ADDRESS>wrote:

Hi @askmike https://github.com/askmike,
I'm running Gekko via UI, I have a live tradebot configured and started
through the interface, and I've just encountered the error above.
My question is: If I simply leave it running, does it recover from the
error and continue trading? I see the logs continue to periodically show
"syncing private data" which I assume are my balances, orders, trades, etc.
so it should have up-to-date information at this point. Correct?
Conversely, if it doesn't recover and I need to restart it, is it enough
to just kill the node process and rerun "node gekko --ui"?
Thanks in advance!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/askmike/gekko/issues/2561#issuecomment-424350451, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7MDzq6bq1AAvlcTg5cfmODAFcjsg_Zks5uejSRgaJpZM4W2Azv
.

--
PGP key at keybase.io/mikevanrossum
https://keybase.io/mikevanrossum/key.asc

Ok, thank you for the answer. I'm running develop now. I will post the logs if I encounter the error again.


[BUG]: Missing Cursor Pointer

Description

Currently the button elements have no pointer during interaction, this will greedly effect accessability.
I need to  improve the accessbility of Rubik cube game buy adding pointing cursors for button elements.

i want to work upon this please assign this task to me under GSSOC'24.

i can add cursor pointer for buttons

I want to work upon this please assign this task to me under GSSOC'24.

@Dev-tanay assign me for the issue.


Steps are not announced by Talkback (Android)

Scenario to reproduce
Samsung Galaxy J3 Prime
Android version 7.0
Step 1 to 6 screens after splash screen
While Talkback on, using “Read from top” from “Global Context menu” Talkback starts reading from the top of the screen and moves to each step automatically and continue reading. However, it doesn’t announce what step it is reading. At the end of the step 6, it announces “Step 1 of 6 and “Next” button. Further, the same behaviour when tried swiping through each element.
Expected result
Talkback should announce each step.
Screenshots

Fixed in IOS V16.


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target_479d5fa5-14b9-4a20-861f-7794fed38807/pull/1 is merged into live branch.
Auto archive content to https://github.com/OPS-E2E-PPE/docs-archive-test-target_479d5fa5-14b9-4a20-861f-7794fed38807.git

Docs Build status updates of commit 933f0ff:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Archive_master_2019-10-10-08-53-47 has been deleted or has been force pushed: fatal: Couldn't find remote ref Archive_master_2019-10-10-08-53-47

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Please add suport for H7151 Dehumidifier

{"device":"11:DB:D4:AD:FC:E8:52:AE","deviceName":"Big Dehumidifier","model":"H7151","httpInfo":{"groupId":12795826,"device":"11:DB:D4:AD:FC:E8:52:AE","sku":"H7151","spec":"","versionHard":"1.02.00","versionSoft":"1.00.24","deviceName":"Big Dehumidifier","deviceExt":{"deviceSettings":"{"wifiName":"CabinInTheWoods","address":"D4:AD:FC:E8:52:AF","bleName":"ihoment_H7151_52AF","topic":"GD/2d93bbef538ea7d11cc28088096da394","wifiMac":"D4:AD:FC:E8:52:AE","pactType":1,"pactCode":1,"wifiSoftVersion":"1.00.24","wifiHardVersion":"1.02.00","ic":0,"secretCode":"OaOwLl7JwQI=","waterFull":1,"thermometerUnit":1,"mcuSoftVersion":"1.00.08\u0000","mcuHardVersion":"1.00.01\u0000","boilWaterCompletedNotiOnOff":1,"completionNotiOnOff":1,"autoShutDownOnOff":1,"sku":"H7151","device":"11:DB:D4:AD:FC:E8:52:AE","deviceName":"Big Dehumidifier","versionHard":"1.02.00","versionSoft":"1.00.24","playState":false}","lastDeviceData":"{"online":false}","extResources":"{"skuUrl":"https://d1f2504ijhdyjw.cloudfront.net/sku-img/e56fed8032f2a7c161baad696732350e-add_list_type_device_7151.png\",\"headOnImg\":\"\",\"headOffImg\":\"\",\"ext\":\"\",\"ic\":0}"},"pactType":1,"pactCode":1,"share":0,"goodsType":147}}

The device now shows up in the item list under the new beta.
Not sure the fan level controls work, but on/off does seem to work.


Website Redesign - About

As a User,
I want to visit the About Page,
So that I can become informed about ReportStream...
Designs

Figma Link https://www.figma.com/proto/Du7feM8huRDAAZCQcUIj93/Website-Redesign?page-id=2026%3A2&type=design&node-id=2026-73&viewport=554%2C195%2C0.17&t=0LVQdVbXub958ODz-8&scaling=min-zoom&hide-ui=1
Content Updates
See Figma
Page Title
TBD
Analytics
Page Load
Button / Link clicks
Storybook updates
TBD
Verification Steps

Code Review
Trail / Dev environment signoff by Product / Design
Staging environment signoff by Product / Design / Stakeholders (Need to be explicit)
Production environment signoff by Engineering, Product and Design

Acceptance Criteria:

[ ] Analytics / Metrics Required
[ ] Storybook update required
[ ] Unit Tests
[ ] End to End Tests
[ ] Manual Testing Steps

Dependencies:

Designs - https://www.figma.com/proto/Du7feM8huRDAAZCQcUIj93/Website-Redesign?page-id=2026%3A2&type=design&node-id=2026-73&viewport=554%2C195%2C0.17&t=0LVQdVbXub958ODz-8&scaling=min-zoom&hide-ui=1
Platform API Endpoints - N/A

Additional Details:

The deployment strategy will follow the general deployment strategy for the Website Redesign EPIC. We will deliver this page in isolation from the other pages.

Hey team! Please add your planning poker estimate with Zenhub @etanb @jpandersen87 @penny-lischer

@jillian-hammer or @yudonoodles the Values section order of topics is not the same b/w the two templates (collapsed/expanded views). Please advise.

Sorry, not sure how one of them got moved, but the order is updated and the same now! Thanks for noting @penny-lischer.


Adding hadoop kerberos authentification.

This PR adds the ability to eagerly authenticate druid process to a hadoop/hdfs kerborized cluster.
In addition this will keep renew the ticket as long as the druid process is running.
With this change you don't need to run the kinit command at all.
User need to provide both the path for keytab file and principal name for this to quick in.
This will allow druid user to avoid relying on cron jobs that renew the TGT kerberos ticket.

do we need to make similar changes to hadoop job also ?

@nishantmonu51 this is enough if user is using hdfs storage module. If not i guess we would have to add that to jobs as well. Although i am not aware if there is a use cases where you have hadoop with Kerberos without hdfs. Anyway we can add that in the future if we have a request for it.

I agree with @nishantmonu51 that we should add to jobs as well. It'll be a lot less confusing to the user.

The use case I was thinking was to use hadoop jobs with S3 as deep storage instead of HDFS, where you may possibly use batch ingestion without having hdfs-storage module.

@nishantmonu51 but at that use case is there any Kerberos in the picture ?

@b-slim it is possible to read raw data from HDFS and write segments to S3

@nishantmonu51 and @fjy i have added kerberos auth to the jobs as well.

@gianm thanks very much for the review. can you take a look again ?

@b-slim sure, just took another look and wrote some more comments.
I guess it's challenging to test this in unit tests, so I'm ok if those are missing, but did you test this on an actual kerberized hadoop cluster to confirm it works?

@gianm again thanks for the second round ! yes i have tested it in local setup up and it works !
As you suggested i have moved the network stuff to be managed by lifecycle.

👍  LGTM, assuming you tested the new version (w/ lifecycle) in a local setup as well.

let me test with life cycle stuff.

@gianm good call on this, looks like the taskRunner doesn't call the method annotated with startLifeCycle and i am not sure why it is not called, any hint ? or should i revert it and do it during configure like that we guarantee that the auth is called  ?

hmm, I'm not sure why it wouldn't get called, but I think it's worth trying to figure that out. start is really the right place to do this kind of stuff imo.

i am trying to understand but my guess is that ExecutorLifecycle doesn't call extension based registered classes annotated with start.

@gianm i guess it is the way the classloader is set up makes the loading of extensions after the lifecycle start as you can see in this log https://gist.github.com/b-slim/a7611cfca60895f111ccbfe2ae4a2975.
@drcrallen does this make sense ?

@nishantmonu51,  @gianm  and @drcrallen i have updated this please look again.

@gianm To avoid adding Critical calls like lifecycle.start() i decided to go other way around.
The new way to do it is to have 2 classes (HdfsKerberosConfig and HadoopKerberosConfig) that binds to the properties under the same druid.hadoop.security.kerberos.* that provides keytab and principal. the idea here is to avoid having druid final user configuring 2 different things for the same end goal.
Thus, if the end-user is using the HDFS storage module. The auth call will be done by lifecycle stuff and that will work fine for all the CLI that loads pdfs-storage-module like historicals/MM/Overloard .
In the other hand if the user will be submitting hadoop job with or without hdfs-module, hadoop jobs will have to do the auth call once the new class loader is used to run the jobs anyway. The call will occur once the job calls ensurePaths.
In the end of the day user has to set the properties druid.hadoop.security.kerberos.principal and druid.hadoop.security.kerberos.keytab and druid will do the necessary auth calls under the hood.

@gianm and @drcrallen this should be good to go i guess, thanks !

:+1:

as per @nishantmonu51 suggested i have made the two functions more identical.

👍  after travis


Implement Webhook Utility

Successor to https://github.com/grammyjs/website/pull/523
Layout preview:

I created a new dedicated page for this component and added a link to it in the "Resources" menu in the navbar.
That's a suggestion and I'm completely fine if we decide to change it

Pretty awesome stuff! 🎉
What's the loading spinner at the top doing? It never completes for me 🤔
It would be cool to remove the button to load the bot info. This can happen automatically as soon as the token is inserted and correct.
Does the component actually store the token in localStorage? It's gone upon reload.
We should link to this website's source code in the promise that we don't send the token anywhere.
Are you planning on adding a light mode?
This should probably be in its own category under Resources, perhaps called Tools. http://fqs.deno.dev can go in there, too, as soon as it's done. /cc @dcdunkan
Additionally, we should add this component to every tutorial on the page that tells users to set a webhook.

What's the loading spinner at the top doing? It never completes for me 🤔
It's loading the bot's picture. I don't think it's able to handle a bot not having a picture. I'll fix that.

It would be cool to remove the button to load the bot info. This can happen automatically as soon as the token is inserted and correct.
I can't really validate the token without calling the API, and I'm not sure if it's a good idea to do that on every typed character, but if you think it's fine, I can implement it no problem

Does the component actually store the token in localStorage? It's gone upon reload.
No, not really. I forgot about that part. I'll add it ASAP

We should link to this website's source code in the promise that says we don't send the token anywhere.
👍🏻

Are you planning on adding a light mode?
The component framework already has one built-in, but I couldn't figure out how to detect that the user changed the overall page theme

This should probably be in its own category under Resources, perhaps called Tools. http://fqs.deno.dev/ can go in there, too, as soon as it's done. /cc @dcdunkan
I agree.

Additionally, we should add this component to every tutorial on the page that tells users to set a webhook.
Should we do this on a new PR after this one gets merged?

it's a good idea to do that on every typed character, but if you think it's fine

I do think it's fine. Note that tokens are usually pasted, so most often there will only be a single request. Even if there are a few hundred requests, it shouldn't be much of an issue.

I couldn't figure out how to detect that the user changed the overall page theme

There's https://github.com/vuepress/vuepress-next/blob/d283ffe3ef0668bfea54e6d973066695f46f13c0/ecosystem/theme-default/src/client/composables/useDarkMode.ts but it doesn't seem to be available to the outside. We can check the DOM manually, but that's ugly. Perhaps @Loskir or @CikiMomogi know this?

Should we do this on a new PR after this one gets merged?

That depends on whether or not we even want to keep it on a dedicated page. Note that #635 was closed. @roj1512 what do you think?

I can't really validate the token without calling the API, and I'm not sure if it's a good idea to do that on every typed character, but if you think it's fine, I can implement it no problem

Why not use a regex for quickly validating that the bot token is at least valid. Then if it is valid, then request?

Because the format of the tokens is unspecified, so we could only base this regex on our own assumptions. The correct way to validate a token is via getMe.
 As long as we don't actually know of any problems related to performance, there's no need to spend time on it.
Also also, rate limits are not a problem. They're very high for getMe, so no ordinary website visitor could ever trigger it, even not by typing the token by hand many times. What's more: the rate limits enforced on checking bot token validity (=failing calls) are enforced per IP address AFAIK. This means that malicious website visitors can only harm themselves but never us.

This is a grey area. It is not exactly markdown text (it is not just docs) but then again it's just a component that this website uses, and that no other website uses. If we were to move it to a different repo, we would consequently also have to extract things like https://github.com/grammyjs/website/blob/main/site/docs/.vuepress/plugins/better-line-breaks.ts but this leads to a lot of added complexity. I am not sure what we gain by this.
I don't think that this component can be treated the same way as the filter query explorer.
What we can do is to only include it on the tutorial pages, and drop the Resources > Tools entry.

It still is a separate VuePress plugin that can be used independently from this repo, so we could publish it on npm and then consume it. I just don't wanna do it to avoid the maintenance overhead.

Because the format of the tokens is unspecified, so we could only base this regex on our own assumptions. The correct way to validate a token is via getMe.
 As long as we don't actually know of any problems related to performance, there's no need to spend time on it.
Also also, rate limits are not a problem. They're very high for getMe, so no ordinary website visitor could ever trigger it, even not by typing the token by hand many times. What's more: the rate limits enforced on checking bot token validity (=failing calls) are enforced per IP address AFAIK. This means that malicious website visitors can only harm themselves but never us.

Okay. I'll implement it then.

Should this also be in a separate repository?

I don't think it's necessary since this shouldn't really be needed outside the docs.
Also, publishing it as a library would imply setting up the build system and everything.
Also also, I'd feel the need to make it more generic in terms of appearance and I really don't know / wanna know how to do that with the component library I'm using for this.
This repo contains a website, and this PR adds a component of that website. I really think they fit together nicely.

There's https://github.com/vuepress/vuepress-next/blob/d283ffe3ef0668bfea54e6d973066695f46f13c0/ecosystem/theme-default/src/client/composables/useDarkMode.ts but it doesn't seem to be available to the outside.

You can usually import hooks from @vuepress/client, but I don't know about that one.
Ill check it out as soon as I get to my computer

It still is a separate VuePress plugin that can be used independently from this repo, so we could publish it on npm and then consume it. I just don't wanna do it to avoid the maintenance overhead.

Right, but it is still something that cannot be interacted with in the front end unlike the webhook utils component.

But anyway, let’s continue this way. Will this component be in every page that guides the user to set webhook?

Will this component be in every page that guides the user to set webhook?

That's the ideia, yeah.
But I'd rather merge this first, then create another PR to add it to those pages

Can you make the preview work somehow?

On it. I saw it was failing after I requested your review.

I have some more feedback. All of these ideas are optional and won't block from merging. You're free to decide if you want to do them here or in a subsequent PQ or not at all.

The three checkboxes look like we could change the settings. It is not intuitive that all they do is to provide information. Either restyle, or add a tooltip, or add a link to BotFather, or a combination of the above.
The text field loses focus when typing.
The error message "Network request for 'getMe' failed!" should not be printed when the text field is cleared.
The error message "Network request for 'getMe' failed!" should perhaps be changed to something more informative.
The text "The one which @BotFather gave you." should include a link to BotFather.
The back arrow should perhaps be displayed next to the bot's avatar. That's where I'd expect backwards nav.
The component should not flicker when pressing refresh.

I have some more feedback. All of these ideas are optional and won't block from merging. You're free to decide if you want to do them here or in a subsequent PQ or not at all.

The three checkboxes look like we could change the settings. It is not intuitive that all they do is to provide information. Either restyle, or add a tooltip, or add a link to BotFather, or a combination of the above.
The text field loses focus when typing.
The error message "Network request for 'getMe' failed!" should not be printed when the text field is cleared.
The error message "Network request for 'getMe' failed!" should perhaps be changed to something more informative.
The text "The one which @BotFather gave you." should include a link to BotFather.
The back arrow should perhaps be displayed next to the bot's avatar. That's where I'd expect backwards nav.
The component should not flicker when pressing refresh.

Closing due to inactivity and grammY tools.

Wouldn't it still be awesome to have a webhook utility component that can be included in the respective guides? IMO it is much preferable to write docs that go like
you gotta set your token, have a tool for that, look: [TOOL]
rather than
you gotta set your token, you can do this via curl or your browser or this other website over there which we created, it is called tools.grammy.dev and it is very good but no matter what you do you always have to leave this site and your train of thought

I agree it's better to have something inline, but I'll open another PQ with the grammy tools version of the component, since it doesn't depend on a UI framework and the design should work better in the docs

Awesome!

Thanks for proving what I assumed as a YES @roziscoding.


Why double quotes in filenames?

I'm having a bad time trying to update nvm because of the double-quotes in the file names on your tests...
It's a bad practice to put double-quoted file names in software that will run in various file systems...
windows screams at me when I use double-quotes in my files and makes my life a hell when I try to upgrade nvm with a simple git pull...
Please! Do not use double-quotes (nor single-quotes) in file names or folder names...

nvm isn't supported on windows, and quotes in filenames work just fine in every other filesystem. In addition, the test files are only pulled when installing nvm with git - with curl or wget it won't grab them.

Oh, thanks!


fix(frontend/docker, ci): fix borked Docker build due to Lerna v8 uplift

fix(frontend/docker, ci): fix borked Docker build due to Lerna v8 uplift
SUMMARY
Closes #29658

Remove --no-optional in docker-frontend.sh to allow installing @nx optional dependencies which is necessary for Lerna v8
Also upgrading prop-types to next minor version to assess reproducibility of issue raised in PR https://github.com/apache/superset/pull/29723
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@eschutho I'm not able to reproduce your CI issue as this PR's frontend-build has installed FE dependencies with success 👀
https://github.com/apache/superset/actions/runs/10120546422/job/27990411018?pr=29725

My vote is to replace those two lines with a single, simple npm install

The webpack install is not necessary, simplifying further here https://github.com/apache/superset/pull/29779

@supersetbot unlabel 4.1


[core] Support to make up the sequence number to nanosecond precision

Purpose
fix #1050
Taking System.nanotime() as the time source with high precision, make up to the provided sequence.field to nanosecond if it's inTimestamp data type and with the precision of second or millisecond.
Tests
ChangelogWithKeyFileStoreTableTest#testNanosSequenceNumberOnTimestampSecond
ChangelogWithKeyFileStoreTableTest#testNanosSequenceNumberOnTimestampMilliSecond
ChangelogWithKeyFileStoreTableTest#testNanosSequenceNumberOnTimestampMicroSecond
ChangelogWithKeyFileStoreTableTest#testNanosSequenceNumberOnNonTimestampField

Or we can introduce a 'sequence.auto-padding' key, valid values are 'second-to-micro' and 'mills-to-micro' and 'none'. Default is none.

@JingsongLi Updated, thanks for you suggestions~

@schnappi17 Please ensure test passing first.

@JingsongLi Updated, and I didn't see any test failed, maybe it's confused by another pr  of mine that UT failed, please help to approve the workflows and let's check it, thanks a lot!

In the current implementation, it's possible for the "padding" of later data's sequence to be smaller than that of the earlier data,resulting in data errors.
for example:
seconds->micros
currentNanoTime1:1062154,766334,200
currentSecondsTime1:1062154
currentNanoTime2:1062155,676231,100
currentSecondsTime2:1062155
sourceMillis:1691482327000
result_sequence:1691482327,766334 and<PHONE_NUMBER>,676231(smaller)
Possible solutions?
set an incremental sequence for the sequence.field, incrementing by one for each incoming data?

In the current implementation, it's possible for the "padding" of later data's sequence to be smaller than that of the earlier data,resulting in data errors. for example: seconds->micros currentNanoTime1:1062154,766334,200 currentSecondsTime1:1062154 currentNanoTime2:1062155,676231,100 currentSecondsTime2:1062155 sourceMillis:1691482327000 result_sequence:1691482327,766334 and<PHONE_NUMBER>,676231(smaller)
Possible solutions? set an incremental sequence for the sequence.field, incrementing by one for each incoming data?

You are right. This PR does not solve the problem.


Added Katib API reference to the website docs

What this PR does / why we need it:
Add the Katib API reference to the website docs
Which issue(s) this PR fixes
Fixes #1481
Special notes for your reviewer:
@sarahmaddox
Please review. Please note that I use PyTorchJob as example rather than Metedata reference since the katib reference is the description of each field (like type, description, etc.) which is closer to that in PyTorchJob reference.
Question:  there are two TODO in the original document in Github. How should we handle this in the website ? Leave them as TODO or remove them?

This change is

/assign @sarahmaddox


DTS 2159378: Fix AggregateError--Part 2

Task name: AzureAppServiceSettingsV1,AzureFunctionOnKubernetesV1,AzureSpringCloudV0,AzureFunctionAppV1, AzureFunctionAppV2,
Description: DTS 2159378
Documentation changes required: Y
Added unit tests: N
Attached related issue: DTS TASK 2159378
Checklist:

[x] Task version was bumped - please check instruction how to do it
[x] Checked that applied changes work as expected

/azp run

/azp run

/azp run


LOAD DATA LOCAL INFILE option shouldn't be open by default.

impact
This may cause arbitrary file read vulnerability.
how to do
This is my client code:
var mysql = require('mysql');
var connection = mysql.createConnection({
    host: 'my_ip',
    user: 'root',
    password: '123456',
    database: 'test'
});

connection.connect();

connection.query('SELECT 1 + 1 AS solution', function (error, results, fields) {
    if (error) throw error;
    console.log('The solution is: ', results[0].solution);
});

Use this rogue mysql tool on my server. We can just read any file from my computer.

Although it throws an error, it doesn't matter.
how to fix
I'm not familiar with source code. But just turn off the LOAD DATA LOCAL INFILE option by default.

https://github.com/mysqljs/mysql/blob/master/Readme.md#security-issues


Break apart state and add mute support

Breaking apart the state object into several notifiers allows for more efficient UI re-renders (and pushes in the direction I think all our SDKs should follow).

@benlower This is maybe not the clearest example of what I meant by breaking up state and having consistent names for events across SDKs since there aren't really "events" per se in Flutter, but hopefully you can get a sense of what I was thinking.


Explainer

You keep asking me why an agent is or is not assigned to a task.  You designed the algorithm!
To help out with this I have added an optional 'explainer' that lists the available agents for each task in priority order
C:\Users\James\code\Agents2Tasks\bin>Agents2Tasks.exe explain ../dat/a2t_40.txt ../dat/r.txt
Unit tests passed

Assigning task Cleaner in slot<PHONE_NUMBER>00, available<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>A_group B_group assigned: A_group
Assigning task Welcomer in slot<PHONE_NUMBER>30, available<EMAIL_ADDRESS>assigned<EMAIL_ADDRESS>Assigning task Collector in slot<PHONE_NUMBER>00, available<EMAIL_ADDRESS>assigned<EMAIL_ADDRESS>Assigning task Welcomer in slot<PHONE_NUMBER>30, available: Rose_group<EMAIL_ADDRESS><EMAIL_ADDRESS>assigned: Rose_group
Assigning task Collector in slot<PHONE_NUMBER>00, available<EMAIL_ADDRESS>assigned<EMAIL_ADDRESS>

This issue has been assigned to you for testing for 4 days now.  Are you having problems with testing it?
Here is a simple example showing how it works:
This input:
a aA 1 fA tA
a aC 1 fB tA
a aB 1 fA tA
t<PHONE_NUMBER>00 tA tA
t<PHONE_NUMBER>00 tA tA

gives these assignments
A<PHONE_NUMBER>00 aA to tA
A<PHONE_NUMBER>00 aB to tA
A<PHONE_NUMBER>00 aC to tA
A<PHONE_NUMBER>00 aA to tA

The fA family is assigned as a whole to the first timeslot, but the second timeslot only gets part of the family.  Why?
Switch on the explainer and you see
Assigning task tA in slot<PHONE_NUMBER>00, available: aA aC aB assigned: aA
Assigning task tA in slot<PHONE_NUMBER>00, available: aB aC assigned: aB
Assigning task tA in slot<PHONE_NUMBER>00, available: aC aA aB assigned: aC
Assigning task tA in slot<PHONE_NUMBER>00, available: aA aB assigned: aA

For the first timeslot agent  aA is assigned to the first task because that is the first agent input.  Because aA is a member of the family fA, the other member of that family is assigned to the other task in the timeslot.
For the second timeslot, the agents are made availble in a different order, with aC first because aC has been assigned zero tasks so far.  AC is thus assigned to the first task.  There are no other member of aC's family, so the first available agent from another family is assigned.

Explaining further - I have added the current workload to the explainer output.  Like this:
Assigning task tA in slot<PHONE_NUMBER>00, available: aA w0,  aC w0,  aB w0,  assigned: aA
Assigning task tA in slot<PHONE_NUMBER>00, available: aB w0,  aC w0,  assigned: aB
Assigning task tA in slot<PHONE_NUMBER>00, available: aC w0,  aA w1,  aB w1,  assigned: aC
Assigning task tA in slot<PHONE_NUMBER>00, available: aA w1,  aB w1,  assigned: aA

This has bee assigned to you for over a week now!  Why are you keeping it open?

I do not understand.  This issue has been assigned to you for a long time.  I have asked you to take a look at it several times.  Yet
you continue to ignore it.
Well enough!  I am closing it.


Camera LongTasks seems broken

Since my workaround to fix texture, I create some Steps []float64, so I can use:
m.MouseZoomer.Steps = []float32{1, 2, 4, 8}

However, the change of zoom and angle is very roughly. In way to prevent it, I make one m.MouseZoomer.Duration = time.Second. The Duration supplies the Duration of CameraMessage.
It was suppose to take 1 second to change the zoom from 1 to 2, another 1 second to change 2 to 4.

However, there's some bugs:
https://github.com/EngoEngine/engo/blob/db964088800cfff0d9f08710dd4391607189a53c/common/camera.go#L171
That doesn't work. The time.Duration is int64. If the game is running at 60 FPS the dt will be 0.16 seconds, which will be 0, since int64(float32(0.16)) is 0. It creates a infinite loop. I think the solution must be:
	const second = float32(time.Second)
	longTask.Duration -= time.Duration(dt * second)

Then, have another problem, which seems to be caused by longTask.speed = longTask.Value / float32(longTask.Duration.Seconds()) when longTask.Incremental = false. It should be false since it is a "steped" zoom.

I'm trying to fix that, but I think it will be very different from the current implementation. 😐

I found the second issue. It's kinda related to longTask.speed = longTask.Value / float32(longTask.Duration.Seconds()). The problem is that the value isn't exactly, for instance you can set to zoom-out 2, but it only zoom-out 1.99.
The fix for that is enforce to set the correct value when longTask.Duration <= time.Duration(0). So, the last step will zoomTo(2).
I'll try to make an pull-request, because I blow-up my fork. 😅


Fix QPY deserialization of UCRX, UCRY, and UCRZ gates

Co-authored-by: Matthew Treinish<EMAIL_ADDRESS>
Summary
Copy latest updates from qpy module in terra. https://github.com/Qiskit/qiskit-terra/pull/7933
Details and comments
Fixes #

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 66.058%

Totals

Change from base Build<PHONE_NUMBER>:
0%

Covered Lines:
2678

Relevant Lines:
4054

💛  - Coveralls


Additional NTE support; initial ORM-O01 support

Several changes to make NTE more usable:
Concatenate multiple sequential NTE's together.
NTE.5 should create a practitioner and reference.
Support for ORU-R01, PPR-PC1, PRC-PC2, PPR-PC3, MDM-T02, MDM-T04, MDM-T06, MDM-T08, MDM-T10, ORM-O01, OMP-O09, RDE-O011, RDE_O25
Tests
Activate ORM-O01 as supported

In Release 1.0.14


Errors in numba_tools matrix functions

conjugate, conjugate_transpose:

def conjugate_transpose(A, B):
    for i in range(A.shape[0]):
        for j in range(A.shape[1]):
            B[i,j] = A[j,i].conjugate()

should be B[j, i] = A[i, j] since A has shape [i, j] (as defined by loops).

matrix_dot_matrix

def matrix_dot_matrix(A, B, C):
    for j in range(B.shape[1]):
        for i in range(A.shape[0]):
            C[i,j] = 0.
            for n in range(C.shape[0]):
                C[i,j] += A[i,n] * B[n,j]

A has shape [i, n], B has shape [n, j] and C will have shape [i, j]. Therefore, the innermost loop should iterate over A.shape[1] (or B.shape[0]).
If I'm not mistaken, these bugs luckily don't affect 3x3 matrices...
Fixes to these issues (plus unit tests for all functions and that work on both CPU and GPU) are forthcoming in https://github.com/IceCubeOpenSource/pisa/pull/585

Good catch, that is indeed the wrong way. But you're right that it will not change anything in our osc. calculations as they are all 3x3

Fixed with pr #585 / https://github.com/IceCubeOpenSource/pisa/commit/88fabb872698c52575878df5dd7b38244d02192a


Solve text overflow in github cards

As you can see above, the issue is visual and in order to solve, you need to update the card component and maybe the grid layout. The observer implementation is here. Finally, you can use yarn dev to launch the only frontend, but I recommend use task in the root. With task start command, you can perform all the compilation routine and launch the complete suite of supersense, only remember your .env config with your config.

This looks like CSS problem. Has anyone else called dibs on this issue?

Yes, the issue is related to the CSS (abstracted with React and ChakraUI), specifically in the EventCard Component.


[Outlook] (Mac) 'New Outlook' support

Docs Build status updates of commit 29b3115:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/reference/requirement-sets/outlook-api-requirement-sets.md
:warning:Warning

Details

docs/outlook/compare-outlook-add-in-support-in-outlook-for-mac.md
:white_check_mark:Succeeded

docs/reference/requirement-sets/outlook-api-requirement-sets.md

Line 105: [Warning] Invalid file link:(~/reference/requirement-sets/compare-outlook-add-in-support-in-outlook-for-mac.md#new-outlook-on-mac).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit b2380b9:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/outlook/compare-outlook-add-in-support-in-outlook-for-mac.md
:white_check_mark:Succeeded

docs/reference/requirement-sets/outlook-api-requirement-sets.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 5b4fbe8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/outlook/compare-outlook-add-in-support-in-outlook-for-mac.md
:white_check_mark:Succeeded

docs/reference/requirement-sets/outlook-api-requirement-sets.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit c353f5c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/outlook/compare-outlook-add-in-support-in-outlook-for-mac.md
:white_check_mark:Succeeded

docs/reference/requirement-sets/outlook-api-requirement-sets.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit a3d7bb6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/outlook/compare-outlook-add-in-support-in-outlook-for-mac.md
:white_check_mark:Succeeded

docs/reference/requirement-sets/outlook-api-requirement-sets.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 3196d79:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/images/outlook-on-mac-classic.png
:white_check_mark:Succeeded

docs/images/outlook-on-mac-new.png
:white_check_mark:Succeeded

docs/outlook/compare-outlook-add-in-support-in-outlook-for-mac.md
:white_check_mark:Succeeded

docs/reference/requirement-sets/outlook-api-requirement-sets.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit b840e61:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/images/outlook-on-mac-classic.png
:white_check_mark:Succeeded

docs/images/outlook-on-mac-new.png
:white_check_mark:Succeeded

docs/outlook/compare-outlook-add-in-support-in-outlook-for-mac.md
:white_check_mark:Succeeded

docs/reference/requirement-sets/outlook-api-requirement-sets.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


[W6.2][T09-B2]Melvin Leo

@Melvin-leo
Accepting this PR with minimal review and I found no important issue.


Refactoring ArticleController

Pre-req for #303
Move logic down into Components for ease of reuse.

Do you consider this done now or only partially?

Only partially, It will be done when I refactor the error checking to each component.

Okay cool (this was the one I thought I had moved to review by the way)


kitchen login prompts for password

I've tried to figure out what's not moving along correctly, and finally threw my hands up in the air at my own inability to grok this, so here I am asking about it.
Most kitchen drivers provide the user/name and password, so that you don't have to type a password. kitchen-vagrant handles this correctly.
With kitchen-docker, I must type in the default password any time I want to log in.
I can see that there's a setting for username/password in the code and this user/password combo does indeed work, since the kitchen setup/converge/verify/test all work over ssh, right?
$ kitchen login -l debug source-ubuntu-1204
D      [kitchen::driver::docker command] BEGIN (docker > /dev/null)
D      [kitchen::driver::docker command] END (0m0.00s)
D      Berksfile found at /Users/miketheman/code/miketheman/nginx/Berksfile, loading Berkshelf
D      Berkshelf 3.1.5 library loaded
D      Login command: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=VERBOSE -p 49156<EMAIL_ADDRESS>(Options: {})
Warning: Permanently added '[<IP_ADDRESS>]:49156' (RSA) to the list of known hosts.
<EMAIL_ADDRESS>password:
Authenticated to <IP_ADDRESS> ([<IP_ADDRESS>]:49156).
Last login: Sat Sep  6 14:59:15 2014 from <IP_ADDRESS>
kitchen@3b5d8f92de41:~$

Related gems:

kitchen-docker (1.5.0)
test-kitchen (1.2.1)

My .kitchen.local.yml:
driver:
  name: docker
  socket: tcp://<IP_ADDRESS>:2375 # boot2docker

And now I don't know where else to look.

@portertech Have you had a chance to read this? With the recent changes to the lib, I haven't had a chance to see if I can dig through to trace the behavior, but I can confirm that a kitchen login still prompts the user for a password.

+1 for experiencing this problem.

I'm also having this issue. Here's a workaround command-line Expect script:
expect -c 'spawn kitchen login; expect "ssword: "; send -- "kitchen\r"; interact'

This was fixed in #141, and released in v2.3.0.

I can confirm that I had this issue with 1.5.0 but no longer with 2.3.0.

Yep, closing this out now that this is no longer an issue.

Thanks for getting this in, super useful! :+1:


[CSS] Refactor variant css tokens

:open_book: Description
Refactor variant css tokens
Adding $theme-colors-rgb color mixin loop
Generating all $theme-colors in variables.scss.
Both badge and spinner components are working as intended.
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

:test_tube: How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Tested in storybook visually.

:white_check_mark: Checklist:

[x] My code follows the SGDS style guidelines and naming conventions
[x]  I have performed a self-review of my own code
[x]  I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Any dependent changes have been merged and published in downstream modules

THank you its working great

Forgot to mention this PR includes the badge fixes as well.

Added stories to the badge
Fixed isLight variant by generating --sgds-*state-color* custom variables in sgds-elements.scss


v0.9.8 broken on Windows

As of 0.9.8, vscode-idris no longer works for me in Windows 7 and 10, using the latest version of vscode and idris v1.0.
Auto-completion, build/typecheck-on-save, shortcuts such as case-split, etc.
Also, when I open an Idris project and switch to the Output tab, I get this in the dev tools console.

ENOENT: no such file or directory, open 'C:\Program Files (x86)\Microsoft VS Code\extension-output-#4': Error: ENOENT: no such file or directory, open 'C:\Program Files (x86)\Microsoft VS Code\extension-output-#4'
at Object.fs.openSync (fs.js:558:18)
at Object.module.(anonymous function) [as openSync] (ELECTRON_ASAR.js:173:20)
at Object.fs.readFileSync (fs.js:468:33)
at Object.fs.readFileSync (ELECTRON_ASAR.js:506:29)
at Object.getIdents (C:\Users\dcastro.vscode\extensions\zjhmale.idris-0.9.8\out\analysis\common.js:116:20)
at Maybe.of.map (C:\Users\dcastro.vscode\extensions\zjhmale.idris-0.9.8\out\providers\ipkg\completionProvider.js:11:24)
at module.exports.Maybe.map (C:\Users\dcastro.vscode\extensions\zjhmale.idris-0.9.8\out\maybe.js:19:19)
at Object.buildCompletionList (C:\Users\dcastro.vscode\extensions\zjhmale.idris-0.9.8\out\providers\ipkg\completionProvider.js:9:44)
at context.subscriptions.push.vscode.window.onDidChangeActiveTextEditor (C:\Users\dcastro.vscode\extensions\zjhmale.idris-0.9.8\out\extension.js:63:20)
at e.invoke (c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:14715)
at e.fire (c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:53565)
at c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:390025
at e.invoke (c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:14715)
at e.fire (c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:53565)
at t.$acceptDocumentsAndEditorsDelta (c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:346353)
at t.e.handle (c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:312304)
at s (c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:176531)
at h (c:\Program Files (x86)\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:177208)
at _combinedTickCallback (internal/process/next_tick.js:67:7)
at process._tickCallback (internal/process/next_tick.js:98:9)

I don't get this error in non-idris projects.
An entry for "idris" seems to also be missing from the list of outputs:

Manually download and reverting back to 0.9.3 and 0.9.6 seems to work fine.

@dcastro Thanks for the reporting, I think the potential reason is the fake maybe monad here https://github.com/zjhmale/vscode-idris/blob/master/src/maybe.js

@dcastro
What is "the last version of vscode" exactly?
Could you please provide a file that causes the error?

Yes, providing a sample file which causes the error will help us a lot to indicate the issue.

@be5invis Well, I've updated vscode to 1.13.0 this morning, but it hasn't been working for a couple of days now.
This happens with any file, really. I just created a brand new folder, with the default main module, and I'm getting this issue.

Hi @be5invis, do you got the same issue on Windows10 with v0.9.8?

@zjhmale I can reproduce the latter one. However typechecking or hover is usable on my PC.

Nothing works at all here on Windows 8.1 and VS Code 1.15.
The menu exists and the Idris output window exists but no matter the command it's always stuck "Loading...".

Hi @dcastro, I can reproduce the same error message on Windows, but just for the newly created Idris files, v0.9.8 should work well with already opened files.

@Enamex I can work with Windows10 and VSCode 1.14.2

It will be really helpful if you provide some screenshot for me to see your scenario more clearly.

@zjhmale commented on Jul 31, 2017, 7:10 PM GMT+2:

@Enamex I can work with Windows10 and VSCode 1.14.2

It will be really helpful if you provide some screenshot for me to see your scenario more clearly.

I'm not sure what to screenshot (and can't take gifs) but in summary: exactly what you're doing in the gif except for me the Loading... never changes.

@Enamex I also have the "Loading..." problem. I tried to fix this by setting the Idris executable path to the full path: "idris.executablePath": "C:\\Users\\erikschierboom\\Bin\\idris\\idris". Unfortunately, this does not work for me. Is there anything more I have to do?

@ErikSchierboom commented on Aug 3, 2017, 11:50 AM GMT+2:

@Enamex I also have the "Loading..." problem. I tried to fix this by setting the Idris executable path to the full path: "idris.executablePath": "C:\\Users\\erikschierboom\\Bin\\idris\\idris". Unfortunately, this does not work for me. Is there anything more I have to do?

Just to be sure you have the right path: go to the executable and right click it while holding Shift, then choose "Copy as path" and use that. Make sure it has the extension .exe in the end.
Also Update 3: Not sure whether this's the extension's fault (probably not) but the issue is that it's trying to call idris from cmd.exe no matter what default shell I'd configured in VS Code (MSYS2 in my case).

@Enamex I've tried that but unfortunately I still have the "Loading..." message. As for the terminal, I only have one terminal installed (cmd.exe) and I can successfully run idris or idrin from VS Code's terminal.

@ErikSchierboom Hmm, really wired.

Pls check can you run idris executable in the terminal with its explicit path, I mean C:\\Users\\erikschierboom\\Bin\\idris\\idris, since on OSX and Linux you can run an executable with its full path, but I don't know whether it is legal on Windows.
You can run idris directly from the terminal, so you have already added idris executable path to Windows $PATH right?

@zjhmale The answer to both questions is: yes. I'll see if I can find anything else being wrong.

I have the same issue. Windows 10. Idris 1.1.1. Visual Code 1.16.
Interestingly, selecting "Start or refresh Idris repl" works. Everything else seems to not work.
I can run idris from the command line.
I noticed Windows has both environment variables at the user and system level. I tried setting the path to include idris in both, but no luck.
Output shows: Errors (0)

I had the files store on my desktop, which has the path: \\MyDomain\Users\MyUserName\Desktop\idris
Notice this is a domain path. I moved my idris file to C:\tmp\ and then it works.

I encountered this error when I made a file named IO.idr in the project. Removing it fixed the issue for me.