feat: disable dp #19671
feat: disable dp #19671
Conversation
| const testInTransaction = (...args: Parameters<jest.It>) => { | ||
| if (args.length > 1) { | ||
| return it( | ||
| args[0], // name | ||
| wrapInTransaction(args[1]), // fn | ||
| args[2] // timeout | ||
| ); | ||
| } | ||
| return it(...args); | ||
| }; |
There was a problem hiding this comment.
will actually remove this from here and do another separate pr for it
| const shop = await shopDocuments.create({ | ||
| data: { | ||
| name: 'Shop1', | ||
| products_mo: { documentId: 'Skate', locale: 'en' }, | ||
| products_oo: { documentId: 'Skate', locale: 'en' }, | ||
| products_ow: { documentId: 'Skate', locale: 'en' }, | ||
| }, | ||
| locale: 'en', | ||
| populate: xToOneRelations, | ||
| }); | ||
|
|
||
| // Products should be connected to both draft and published version | ||
| xToOneRelations.forEach((relation) => { | ||
| expect(shop[relation]).toMatchObject([ | ||
| { name: 'Skate-En', locale: 'en', publishedAt: null }, | ||
| { name: 'Skate-En', locale: 'en', publishedAt: expect.any(String) }, | ||
| ]); | ||
| }); |
There was a problem hiding this comment.
@alexandrebodin I would like to review the set of tests for relations together (there are still missing tests atm)
Specially, I would like to discuss the approach on return values of "oneToOne" relations, if a one to one relation can return a published and draft version, it has to be an array.
That will be a breaking change, and I wonder if it just would make sense (in xToOne relations) to always return a single relation at a time (draft or publish and pick a default)
packages/core/content-type-builder/server/src/controllers/validation/content-type.ts
Outdated
Show resolved
Hide resolved
packages/core/content-type-builder/server/src/services/schema-builder/content-type-builder.ts
Outdated
Show resolved
Hide resolved
|
Will create other PRs for relations, I have checked and frontend does receive the default value of draft and publish if it is not set in the schema 👍 cc @alexandrebodin |
|
Do you think it's better to build the whole feature on this branch like we are for relations? or merge incrementally, honestly i'd opt for the former considering they're small features 👀 |
|
I wouldn't mind any of those options, handling relations will not be a small feature, so maybe we could keep this branch for this work+ the necessary ui work and I work on the relational stuff in parallel. wdyt? |
* chore: re-implement option in ctb * chore: refactor CM & i18n to accomodate option D&P * test(unit): add test to ensure status is not in EditView header when we dont pass the prop * chore: remove unused import Co-authored-by: Jamie Howard <48524071+jhoward1994@users.noreply.github.com> --------- Co-authored-by: Jamie Howard <48524071+jhoward1994@users.noreply.github.com>
joshuaellis
added
source: core:content-manager
echoes-hq
bot
added
the
echoes/type: feature/new
What does it do?
Describe the technical changes you did.
Why is it needed?
Describe the issue you are solving.
How to test it?
Provide information about the environment and the path to verify the behaviour.
Related issue(s)/PR(s)
Let us know if this is related to any issue/pull request