Skip to content
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

custom_fields: added custom vocab flag #1109

Merged
merged 1 commit into from
Mar 5, 2024

Conversation

0einstein0
Copy link
Member

❤️ Thank you for your contribution!

Description

Closes Issue #733

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

Third-party code

If you've added third-party code (copy/pasted or new dependencies), please reach out to an architect.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

  1. You license your contribution under the same terms as the current repository’s license.
  2. You agree that you have the right to license your contribution under the current repository’s license.

@0einstein0 0einstein0 linked an issue Feb 26, 2024 that may be closed by this pull request
@0einstein0 0einstein0 force-pushed the Custom-Fields branch 2 times, most recently from 652ad0a to 7b7d3cb Compare February 26, 2024 20:46
Copy link
Member

@slint slint left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of questions/comments, but otherwise looks good (with @yashlamba)

@@ -28,16 +28,25 @@ export class CustomFieldSerializer {
if (customFields !== null) {
for (const [key, value] of Object.entries(customFields)) {
const isVocabularyField = this.vocabularyFields.includes(key);
const isCustomVocabulary = value.isCustomVocabulary;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment/minor: why do we have to track separately if the value is coming from a custom vocabulary? also, what is a "custom vocabulary" compared to a regular vocabulary? Aren't they served under /api/vocabularies/....

If it's about being "generic" vocabularies, I think we should use the same terminology, i.e. isGenericVocabulary.

@0einstein0 0einstein0 force-pushed the Custom-Fields branch 3 times, most recently from 06fb5c1 to 4062259 Compare February 29, 2024 16:07
const _value = _isArray(value)
? value.map((v, i) => mapValue(v, i, isVocabularyField))
: mapValue(value, null, isVocabularyField);
? value.map((v, i) => mapValue(v, i, isVocabularyField, isGenericVocabulary))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think now the isVocabularyField is quite confusing as name because isGenericVocabulary should also be a vocabulary field. Do you intend to split between generic and custom?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes because the custom field we added is a non generic vocabulary, hence why this check was needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then I would clearly rename isVocabularyField with something like isCustomVocabularyField

@slint slint merged commit 17f68ae into inveniosoftware:master Mar 5, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement the subjects field as a custom field
4 participants