This question is related to another question of mine: Query to retrieve defects from parent and children
I have inherited code that displays a burndown of a project. I have now took my project and split it into two projects, so that now there is a parent project and two children. The code (below) fails to create any burndown, I assume this is because it cannot find any stories/tasks on top-level project, and (I assume) it is not looking at the children project.
Please note - the solution in the link I refer to did not work for me here (removed the children: null and replaced with _ProjectHierarchy: context.getProject().ObjectID,)
Anyway - here's the code:
storeConfig: {
find: { _TypeHierarchy: "HierarchicalRequirement"},
fetch: ["TaskEstimateTotal", "TaskRemainingTotal", "Iteration"], hydrate: ["TaskEstimateTotal", "TaskRemainingTotal", "Iteration"],
sort: { _ValidFrom: 1 },
filters: [{ property: "Iteration", value: iterationRecord.get("ObjectID") }, { property: "_TypeHierarchy", value: "HierarchicalRequirement"}]
},
You should be able to restore your hierarchy by adding this to your find:
_ProjectHierarchy: 12345
where 12345 is the object id of your parent project.
Additionally, what Joel mentioned above is also true. In Rally there is a concept of "like iterations", where in a project hierarchy there are similarly named/dated iterations for each project.
So you'll just have to add the following to your find clause to make sure your results are filtered to all the child iterations:
Iteration: {$in: [23456, 34567]}
where 23456 and 34567 are the object id's of the iterations for the child projects.
You can use a simple Rally.data.wsapi.Store to load all the "like iterations" for whatever period you're interested in reporting on and then grab the object id's to pass into your chart storeConfig.
Related
I'm using KeystoneJS v6. I'm trying to enable functionality which allow me to reorder the placement of images when used in another list. Currently i'm setting up the image list below, however I'm unable to set the defaultIsOrderable to true due to the error pasted.
KeystoneJS list:
Image: list({
fields: {
title: text({
validation: { isRequired: true },
isIndexed: 'unique',
isFilterable: true,
isOrderable: true,
}),
images: cloudinaryImage({
cloudinary: {
cloudName: process.env.CLOUDINARY_CLOUD_NAME,
apiKey: process.env.CLOUDINARY_API_KEY,
apiSecret: process.env.CLOUDINARY_API_SECRET,
folder: process.env.CLOUDINARY_API_FOLDER,
},
}),
},
defaultIsOrderable: true
}),
Error message:
The expected type comes from property 'defaultIsOrderable' which is declared here on type 'ListConfig<BaseListTypeInfo, BaseFields<BaseListTypeInfo>>'
Peeking at the definition of the field shows
defaultIsOrderable?: false | ((args: FilterOrderArgs<ListTypeInfo>) => MaybePromise<boolean>);
Looking at the schema API docs, the defaultIsOrderable lets you set:
[...] the default value to use for isOrderable for fields on this list.
You're trying to set this to true but, according to the relevant section of the field docs, the isOrderable field option already defaults to true.
I believe this is why the defaultIsOrderable type doesn't allow you to supply the true literal – doing so would be redundant.
So that explains the specific error your getting but I think you also may have misunderstood the purpose of the orderBy option.
The OrderBy Option
The field docs mention the two effects the field OrderBy option has:
If true (default), the GraphQL API and Admin UI will support ordering by this field.
Take, for example, your Image list above.
As the title field is "orderable", it is included in the list's orderBy GraphQL type (ImageOrderByInput).
When querying the list, you can order the results by the values in this field, like this:
query {
images (orderBy: [{ title: desc }]) {
id
title
images { publicUrl }
}
}
The GraphQL API docs have some details on this.
You can also use the field to order items when listing them in the Admin UI, either by clicking the column heading or selecting the field from the "sort" dropdown:
Note though, these features order items at runtime, by the values stored in orderable fields.
They don't allow an admin to "re-order" items in the Admin UI (unless you did so by changing the image titles in this case).
Specifying an Order
If you want to set the order of items within a list you'd need to store separate values in, for example, a displayOrder field like this:
Image: list({
fields: {
title: text({
validation: { isRequired: true },
isIndexed: 'unique',
isFilterable: true,
}),
displayOrder: integer(),
// ...
},
}),
Unfortunately Keystone doesn't yet give you a great way to manage this the Admin UI (ie. you can't "drag and drop" in the list view or anything like that). You need to edit each item individually to set the displayOrder values.
Ordering Within a Relationship
I notice your question says you're trying to "reorder the placement of images when used in another list" (emphasis mine).
In this case you're talking about relationships, which changes the problem somewhat. Some approaches are..
If the relationship is one-to-many, you can use the displayOrder: integer() solution shown above but the UX is worse again. You're still setting the order values against each item but not in the context of the relationship. However, querying based on these order values and setting them via the GraphQL API should be fairly straight forward.
If the relationship is many-to-many, it's similar but you can't store the "displayOrder" value in the Image list as any one image may be linked to multiple other items. You need to store the order info "with" the relationship itself. It's not trivial but my recent answer on storing additional values on a many-to-many relationship may point you in the right direction.
A third option is to not use the relationship field at all but to link items using the inline relationships functionality of the document field. This is a bit different to work with - easier to manage from the Admin UI but less powerful in GraphQL as you can't traverse the relationship as easily. However it does give you a way to manage a small, ordered set of related items in a many-to-many relationship.
You can save an ordered set of ids to a json field. This is similar to using a document field but a more manual.
Hopefully that clears up what's possible with the current "orderBy" functionality and relationship options. Which of these solutions is most appropriate depends heavily on the specifics of your project and use case.
Note too, there are plans to extend Keystone's functionality for sorting and reordering lists from both the DX and UX perspectives.
See "Sortable lists" on the Keystone roadmap.
I'm trying to create a ranking where the projects entity can receive votes, represented by another table, the votes entity. However, when no one voted for project x, the entity votes does not know about the specific project. I'm using ORM Sequelize and I'm using SUM/GROUPBY method to join common records. When there are records, everything goes well. The problem is when there is no vote registered for a given project in the vote table, my wish is that this project without votes, would also be returned with a default value of 0. I've read that it has a default value like "isnull(sum, 0)", something like that, but I don't know where to put it, because in my head the votes entity will have to go back to the projects entity to check which ones didn't add up, so I don't know if it fits in my case.
let response = await Votes.findAll({
limit,
offset,
attributes: ['project', [sequelize.fn('sum', sequelize.col('factor')), 'votes']],
group: ['project', "project_.address" ],
include: [
{
model: Projects,
as: 'project_',
attributes: ["address","name"],
}],
raw: true,
order: [[sequelize.literal('votes'), 'DESC']],
})
return res.json(response);
I do query cars from an api with a single query but two resolvers (listing and listings)(hopefully resolver is the right name for it). One car I get by the id via listing and the other cars I get without filters by listings. The resolvers output the data i a little different structure on the server-side but I do get the same fields just at different „places“. I want to merge the structure in order to get a single array I can simply loop over in vue.js. For the apicalls I do use vue-apollo.
Couldn't find any information to merge data client-side inside graphqlqueries. All I found is about handling it serverside with resolvers but it's an api I do not own.
Is it possible with graphql or do I have to merge it inside my vuecomponent and if so what would be the best way to do so?
The output will be a grid of cars where I show the car of the week (requested by id) together with the newest cars of the regarding cardealer.
Full screenshot including response: https://i.imgur.com/gkCZczY.png
Stripped down example with just the id to show the problem:
query CarTeaser ($guid: String! $withVehicleDetails: Boolean!) {
search {
listing(guid: $guid){
details{
identifier{
id #for example: here I get the id under details->identifier
}
}
}
listings( metadata: { size: 2 sort:{ field: Age order: Asc}}) {
listings{
id #here it's right under listings
details{
…
}
}
}
}
}
}
Ideally you're right, it should be handled server-side, but if it's not your API the only solution is to manipulate the data on the client side, meaning in your component.
It's probably a lot simpler to leave the listings array untouched and to just merge the listing element with it, like this for instance:
// assuming 'search' holds the entire data queried from the api
const fullListing = [
// car of the week, data reformatted to have an identical structure as
// the 'other' cars
{
id: search.listing.details.identifier.id,
details: {
vehicle: search.listing.details.vehicle,
},
},
...search.listings.listings, // the 'other' cars
]
I have two models: Entity and Cabinet. Entity model can have multiple cabinets. One cabinet can have one Entity object.
In my admin UI when I create Cabinet I specify the Entity which the cabinet belongs to.
I have linked Entity to Cabinets and Cabinets to Entity like this:
models/Entity.js
Entity.add({ name: { type: Types.Text, initial: true, label: 'Име' }, cabinets: { type: Types.Relationship, ref: 'Cabinet', many: true }, })
models/Cabinet.js
Cabinet.add({ entity_id: { type: Types.Relationship, ref: 'Entity'}, name: { type: Types.Text, initial: true } })
When I save a new Cabinet and go to Entity list, I expect to see populated cabinet ( I just created )
in the column Cabinets
The column Cabinets in the Entity list view is empty.
Is this a bug in keystone.js or I have missed something?
What you've done here is just create two different models. That being said once you create a new Cabinet you should be able to go into Entities and select that Cabinet from a search/dropdown.
Since this was asked two months ago I'm going to assume you've solved what you were looking for and moved on... but if you are still stuck could you clarify what the rest of your models have and confirm that the Cabinet that you've saved is actually generating?
I'm at a loss as to how to map a document for search with the following structure:
{
"_id": "007ff234cb2248",
"ids": {
"source1": "123",
"source2": "456",
"source3": "789"
}
"names": [
{"en":"Example"},
{"fr":"exemple"},
{"es":"ejemplo"},
{"de":"Beispiel"}
],
"children" : [
{
"ids": {
"source1": "CXXIII",
"source2": "CDLVI",
"source3": "DCCLXXXIX",
}
names: [
{"en":"Example Child"},
{"fr":"exemple enfant"},
{"es":"Ejemplo niño"},
{"de":"Beispiel Kindes"}
]
}
],
"relatives": {
// Typically no "ids" at this level.
"relation": 'uncle',
"children": [
{
"ids": {
"source1": "0x7B",
"source2": "0x1C8",
"source3": "0x315"
},
"names": [
{"en":"Example Cousin"},
{"fr":"exemple cousine"},
{"es":"Ejemplo primo"},
{"de":"Beispiel Cousin"}
]
}
]
}
}
The child object may appear in the children section directly, or further nested in my document as uncle.children (cousins, in this case). The IDs field is common to levels one (the root), level two (the children and the uncle), and to level three (the cousins), the naming structure is also common to levels one and three.
My use-case is to be able to search for IDs (nested objects) by prefix, and by the whole ID. And also to be able to search for child names, following an (as yet undefined) set of analyzer rules.
I haven't been able to find a way to map these in any useful way. I don't believe I'll have much success using the same technique for ids and names, as there's an extra level of mapping between names and the document root.
I'm not even certain that it is even mappable. I believe at least in principle that the ids should be mappable as terms, and perhaps that if I index the names as terms in some way, too.
I'm simply at a loss, and the documentation doesn't seem to cover anything like this level of complex mapping.
I have limited (read: no) control of the document as it's coming from the CouchDB river, and the upstream application already relies on this format, so I can't really change it.
I'm looking for being able to search by the following pseudo conditions, all of which should match:
ID: "123"
ID by source (I don't know how best to mark this up in pseudo language)
ID prefix: "CDL"
Name: "Example", "Example Child"
Localized name (I don't even know how best to pseudo-mark this up!
The specifics of tokenising and analysis I can figure out for myself, when I at least know how to map
Objects when both the key and the value of the object properties are important
Enumerable objects when the key and value are important.
If the mapping from an ID to its children is 1-to-many, then you could store the children's names in a child field, as a field can have multiple values. Each document would then have an ID field, possibly a relation field, and zero or more child fields.