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?
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);
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.
I have two models, User and Capture, where a Capture can be related to multiple users: it is owned, claimed, and processed all by three different users.
User = thinky.createModel 'User',
id: String
displayName: String
email: String
Capture = thinky.createModel 'Capture',
id: String
ownerID: String
processedByID: String
claimedByID: String
created: Date
updated: Date
Capture.belongsTo User.model, 'owner', 'ownerID', 'id'
Capture.belongsTo User.model, 'processedBy', 'processedByID', 'id'
Capture.belongsTo User.model, 'claimedBy', 'claimedByID', 'id'
The owner relationship works, but I cannot get the processedBy and claimedBy relationships to work. I'm querying with .getJoin(), and Thinky has created the secondary indexes on my tables (so it at least knows about the relationships)
What am I doing wrong? How can I get the nested objects to return in my queries?
That's because thinky will join another model once by default (to avoid circular references).
You must be explicit on the links you want to fetch:
Capture.getJoin({owner: true, processedBy: true, claimedBy: true}).run()
I'm trying to connect a many-to-many relationship with RestKit.
Suppose we have 2 entities:
User, returned by /user/:login_name:
{
id: 1234,
name: 'Joe Bloggs',
...
}
and Group, returned by /user/:login_name/groups:
[
{
id: 2345,
name: 'Diggers',
...
},
{ id: 2346,
name: 'Fillers',
...
},
...
]
Each user can belong to several groups and each group can have several users.
My Core Data models reflect the data returned by API plus have User.groups and Group.users relationships.
The problem is no foreign keys are returned by API: there's neither User.groups nor Group.users collection. So, as far as I understand, I can not use RKConnectionDescription in this case?
It looks like [RKRoute routeWithRelationshipName:objectClass:pathPattern:method:] could have been used, but I'm not using object mapping and it looks like routing can't be used with entity mapping.
Am I missing something here?
You can use RKConnectionDescription, but you will need to tread carefully...
You should use a route. The important part is for RestKit to collect :login_name in the routing metadata and then you can use that in your mapping.
It means you need to request the user before you request the group so that there is something in the DB to find.
You also need to set RestKit to use RKAssignmentPolicyUnion so that your relationships are built up rather than being replaced.
See this answer for more details on route and metadata. See this answer for RKAssignmentPolicyUnion details.