New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(content-releases): releases migration to v5 #20259
base: v5/main
Are you sure you want to change the base?
Conversation
* chore: migrate bulkDelete to v5 * chore: change findLocales type to accept strings array * fix: docs prettier styles * chore: remove console.log
…into v5/bulk-publish-unpublish
meta: { | ||
count: actions.count, | ||
target_type: contentTypeUid, | ||
target_id: entryId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the entry id the one stored in the releases actions content type?
There might be a scenario where a document draft is discarded (deleted) and regenerated with a new entry id one.
Would that be an issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point and probably is going to be a problem 🤔
I'm using the entryId because I think polymorphic relations with documentId are not implemented yet, right? So I don't see a solution 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might need to find alternatives, relations will allways be stored using entry ids, it's just that we expose docId relations to make things consistent on the api.
I guess, at the moment, discarding a draft would result in removing that one from the release 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment, how do you handle entries being deleted? do you have a db lifecycle that checks for those and removes them from the releases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we are using a db lifecycle to listen to that "event" and remove deleted entries from releases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well , I guess discarding the documetn would just unlist it from the release then.
It might be a good discussion with Yannis to check if this is an issue and if we want to work on it on the future , wdyt?
Size Change: 0 B Total Size: 2.58 MB ℹ️ View Unchanged
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -25,14 +25,14 @@ export const getPopulatedEntry = async ( | |||
}; | |||
|
|||
export const getEntryValidStatus = async ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @jhoward1994 just in case, just in case you want to handle publishing validations backend side this might be useful.
packages/core/content-releases/server/src/controllers/release.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some minor feedback on the FE tweaks, you might not have know those things were available :)
const Panel: PanelComponent = () => { | ||
const { | ||
slug: contentTypeUid = '', | ||
id, | ||
locale, | ||
} = useParams<{ | ||
slug: UID.ContentType; | ||
id: string; | ||
locale: string; | ||
}>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you get model
and documentId
passed as props to this component, you should use them instead :)
edit: { options }, | ||
} = useDocumentLayout(contentTypeUid); | ||
const { formatMessage, formatDate, formatTime } = useIntl(); | ||
const { collectionType } = useParams<{ collectionType: string }>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you also get collectionType
as a prop, use that instead
const { formatAPIError } = useAPIErrorHandler(); | ||
const [{ query }] = useQueryParams<{ plugins?: { i18n?: { locale?: string } } }>(); | ||
const locale = query.plugins?.i18n?.locale; | ||
const { collectionType } = useParams<{ collectionType: string }>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you get collectionType as a prop
const query = await permissionsManager.sanitizeQuery(ctx.query); | ||
|
||
query.sort = query.groupBy === 'action' ? 'type' : query.groupBy; | ||
delete query.groupBy; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not something related to this PR, but this should contain a yup validation. I don't think the sanitizeQuery is sanitizing non existing filters like "groupBy"
|
||
type ReleaseWithPopulatedActions = Release & { actions: { count: number } }; | ||
|
||
const releaseController = { | ||
async findMany(ctx: Koa.Context) { | ||
async findByDocumentAttached(ctx: Koa.Context) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you add some comment or explanation of what's the responsability of this controller? 🤔
After 2 weeks of being of, I forgot a bit the logic, and I don't quite see what findByDocumentAttached
means.
Maybe what confuses me is the "Attached" word
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it feels off that the endpoint is called findByDocumentAttached, but you can send a parameter to find by documents not attached 🤔
const relatedReleases = await releaseService.findMany({ | ||
where: { | ||
releasedAt: null, | ||
releasedAt: { | ||
$null: true, | ||
}, | ||
actions: { | ||
target_type: contentTypeUid, | ||
target_id: entryId, | ||
}, | ||
}, | ||
}); | ||
|
||
const releases = await releaseService.findMany({ | ||
where: { | ||
$or: [ | ||
{ | ||
id: { | ||
$notIn: relatedReleases.map((release: any) => release.id), | ||
}, | ||
}, | ||
{ | ||
actions: null, | ||
}, | ||
], | ||
releasedAt: { | ||
$null: true, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe these queries could be inside the service itself.
releases.findEntryReleases({id, populate...})
releases.findNotInEntryReleases({id, ...))
You could also reduce logic here if you do something like:
releases.findDocumentReleases({documentId, locale, populate...})
releases.findNotInDocumentReleases({documentId, locale, ...))
const documents = await strapi.documents(contentTypeUid).findMany({ locale }); | ||
|
||
return documents[0].id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use the .findFirst
instead, this might load 1M documents if they exist in the database.
Don't know if it's something already fixed in the v5 branch , but it's a bit difficult for me to test strapi using multiple users atm. It's not possible for me to refresh the page when I have two tabs (one in incognito) with two different users. |
What does it do?
Migrates and apply new changes on the Content Releases plugin for v5.
Work to do