Contributor Roles and Type #696

jyhein · 2025-09-01T06:22:43Z

Contributor Roles and Type

Add contributor Roles to Author
Add contributor Type to Author
Remove user group functions from Author
Remove translator from user groups
Add possibility to add more roles than author and translator
Selected contributor type changes what contributor form fields are required
More than one contributor role can be selected in the contributor form

jardakotesovec

This is excellent work. Great extension for the required option.

In general we are aiming to have the managers configurable via configuration functions (getColumns, getTopActions, etc). But in this case I can hardly imagine someone would need to extend this. So I think we can leave it as is and improve it if needed.

Only more significant suggestion is to move the form logic for managing the contributor roles to client side. So please check that one out. After that I would do second round, just to make sure I did not miss anything..

Thanks!

jardakotesovec · 2025-10-02T09:06:34Z

src/components/Form/Form.vue

 			let errors = {};
 			this.fields.forEach((field) => {
 				if (
 					!field.isRequired ||


This might not be necessary, if the require logic is handled inside requireWhen?

src/managers/ContributorRoleManager/ContributorRoleManager.vue

src/managers/ContributorRoleManager/contributorRoleManagerStore.js

jardakotesovec · 2025-10-06T12:18:39Z

src/managers/ContributorRoleManager/useContributorRoleManagerFormAddRole.js

+
+	initEmptyForm('editContributorRole', {
+		action: rolesApiUrl.value,
+		locales: supportedLocales,


If you don't pass locales it should by default initialise locales based on the getSupportedFormLocales, which is better fit than the getSupportedLocales

The form name fields should be filled in ui locales for the identifier. Is this not the way to do it?

initEmptyForm by default configures correct locales for the form - https://github.com/pkp/ui-library/blob/main/src/composables/useForm.js#L346

I need the translations to be in UI locales. So, which is it then: supported locales or supported form locales? What’s the difference between them?

I was asking that @bozana the other day, also wondering which one should be used when. Rule of thumb is basically UI is for displaying data, FORM is for entering data.

These will be usually same languages. And if there are some additional languages in the UI - it would fallback to the default language if there is no translation.

But we are opened to hear thoughts from you and @ajnyga as you have been thinking about locales a lot :-).

I would be also interested to hear if someone is using different set of UI and Form languages - whats the expectation from such setup.

The identifier is the actual data here and the names for it are just for display purposes. So, using some other list than ui locales is not good, even if form locales are usually same

There is couple of similar use cases. Like sections or categories. All are using list of form locales.

As result if someone would configure UI in language that is not covered in forms. User would see the UI in given language and couple of these labels would fallback to primary language, which often will be english.

We are not sure about exact reasoning about the UI/Form being configured separately. But if we decide to change it - it would make sense to carefully evaluate the change across the system, so we have clear rule to apply. At this point I think its best to keep it consistent with all other similar forms, which are using that.

Hi all, @jyhein and @jardakotesovec,
Yes, as Jarda said, for the forms i.e. data input we should use supported form locales. Those are languages the journal maintains the data/texts/settings in. They could be different than the UI locales -- Journal can choose to provide menu and actions (all OJS default/existing translations) to the users in a UI language that they are not able to provide all the translations of data/texts/settings in.
The same is with submission locales -- Journal could accept submissions or metadata in a language that they do not provide translations of data/texts/settings in. That submission language could however be selected for the UI (if it exists in OJS).
Thus, in all journal forms -- all forms that do not have anything to do with submissions -- the supported form locales should be used. (As the name says :-))

Hi, the source of misunderstanding here is probably the reasoning why we have the UI language and Form language as separate settings. This has been in OJS for a quite long time and we did not pay much attention to it when the Submission language settings were separated.

This can maybe lead to a situation where UI is turned on for a language but no data is available for the role names because the form language was not turned on. Of course there are other possibilities for misconfiguration in OJS besides this and a journal can fix this quite easily, But it does maybe pose the question whether we need those settings separately or should the UI language just enable the forms for the language. But it is not in the scope of this issue.

So let's proceed with the form languages and maybe have this discussion somewhere else.

Maybe just a note: if data in UI language is missing, there is always a fallback locale (for required fields) we display, for contest settings it is context primary locale, for users it is site primary locale, for submission metadata it is submission locale.

src/managers/ContributorRoleManager/useContributorRoleManagerFormAddRole.js

jardakotesovec

Looking great.. just two minor feedbacks.

jardakotesovec

Looking great.

I still would recommend just to have primary language required as its anywhere else. It make sense for consistency. When admin is creating categories for example - we don't enforce all the languages. Same for recommendations. As result always fallback to primary language.

Couple more suggestions inline. Let me know if something is not clear.

jardakotesovec · 2025-11-06T11:08:27Z

src/managers/ContributorRoleManager/useContributorRoleManagerFormAddRole.js

+	addFieldSelect('contributorRoleIdentifier', {
+		label: t('manager.contributorRoles.identifier'),
+		isRequired: true,
+		options: setIdentifierOptions(contributorRoleIdentifiers.value ?? []),


Could these be filtered, to just provide identifiers that don't exist yet in form of credit role? Since every identifier can be used just once. And it results in crash if existing identifier is selected.

Ah, ok. So, they decided that same identifier can be used more than once

Yes, we decided that one identifier can be used more than once -- journal manager will be able to create multiple roles with the identifier AUTHOR, for example.

I see, thanks for clarifying. So maybe it was crashing only because I was using older database snapshot from the last code review and I assume you probably changed model not to have identifier being unique. So if adding multiple roles with same identifier works, then all good.

jardakotesovec · 2025-11-06T11:22:50Z

src/managers/ContributorRoleManager/contributorRoleManagerStore.js

+			}
+
+			// Prepare form for editing
+			if (role.id && action === Actions.EDIT) {


Not a big deal. So I will leave it up to you whether you decide to adjust it.

Its nice to have the form creation logic in one place. So rather than creating the form in useContributorRoleManagerFormAddRole and editing it here. I would suggest to extend useContributorRoleManagerFormAddRole to handle both ADD and EDIT use case and always return form for that purpose.

To basically have something like:

export function useContributorRoleManagerAddRole({ rolesApiUrl, contributorRoleIdentifiers, editMode: false/true }) {

Than you can basically always call the useContributorRoleManagerFormAddRole when you need the form with the right arguments. And not creating it when store is being created. That also avoid needs for cloning the form. Just always basically create it from scratch contextually.

jyhein · 2025-11-06T14:07:53Z

Looking great.

I still would recommend just to have primary language required as its anywhere else. It make sense for consistency. When admin is creating categories for example - we don't enforce all the languages. Same for recommendations. As result always fallback to primary language.

Couple more suggestions inline. Let me know if something is not clear.

The php-side validation seems to require all the locales anyway without special rules. So, I am showing here all the locales for that reason, i.e. not confuse user when adding/editing with error messages

bozana · 2025-11-07T10:05:46Z

@jyhein, the PHP validation should not require all locales, only the primary locale...

bozana · 2025-11-10T13:41:53Z

Hi @jardakotesovec and @jyhein, I have just checked the contributor roles Repository::validation() and it is as I said:
Required props that are also multilingual will only be required in the primary locale
which is journal primary locale in our case. So the UI part that requires names in other/all locales can be removed, I think...

jardakotesovec

Thank you for the updates, looking great. I think we are good to go here :-).

Only thing I did not double check is the required props discussion above. But hopefully that can be adjusted.

bozana mentioned this pull request Jul 1, 2025

Contributor metadata enhancements: Credit Roles, Contributor Roles and Contributor Types pkp/pkp-lib#11378

Open

jyhein force-pushed the f857 branch from 4fe052f to 6209b89 Compare September 18, 2025 08:14

jyhein force-pushed the f857 branch 2 times, most recently from 30d6645 to 0f4bad7 Compare October 1, 2025 18:11

jardakotesovec requested changes Oct 2, 2025

View reviewed changes

jyhein force-pushed the f857 branch from 0f4bad7 to 1a8b353 Compare October 2, 2025 16:59

jardakotesovec reviewed Oct 6, 2025

View reviewed changes

src/managers/ContributorRoleManager/useContributorRoleManagerFormAddRole.js Outdated Show resolved Hide resolved

jardakotesovec requested changes Oct 6, 2025

View reviewed changes

jyhein force-pushed the f857 branch from 1a8b353 to f36ae8a Compare October 22, 2025 09:03

jyhein force-pushed the f857 branch 3 times, most recently from 7489779 to e29e11e Compare October 31, 2025 09:37

jyhein force-pushed the f857 branch from e29e11e to 933cd7d Compare November 6, 2025 08:55

jardakotesovec requested changes Nov 6, 2025

View reviewed changes

jyhein force-pushed the f857 branch 2 times, most recently from 2460c88 to d9d17db Compare November 6, 2025 21:22

jardakotesovec approved these changes Nov 10, 2025

View reviewed changes

Contributor Roles and Type

86bedd3

jyhein force-pushed the f857 branch from d9d17db to 86bedd3 Compare November 11, 2025 09:02

Contributor Roles and Type #696

Are you sure you want to change the base?

Contributor Roles and Type #696

Conversation

jyhein commented Sep 1, 2025

Uh oh!

jardakotesovec left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jardakotesovec Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jardakotesovec left a comment

Choose a reason for hiding this comment

Uh oh!

jardakotesovec left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jyhein commented Nov 6, 2025

Uh oh!

bozana commented Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bozana commented Nov 10, 2025

Uh oh!

jardakotesovec left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jardakotesovec Oct 6, 2025 •

edited

Loading

bozana commented Nov 7, 2025 •

edited

Loading

jardakotesovec left a comment •

edited

Loading