EditorialTeam memberlist plugin

[luiz_borges]

Hi there,
I started this topic some months ago: viewtopic.php?f=2&t=4682&p=18218#p18218

Now, I must do something to ease my work on editing groups. We handle some 10 journals, and the editorial team changes (minor changes) every six months. Just today I had to add 13 new members to a journals, and them go one by one to place then in the correct order. I lost almost 1 hour oh work just for that.

My idea is as follows, on the manager side, a plugin/template/class/patch/etc handles the page manager/groupMembership and add radio button with two choices:
- Use Members
- Use Content
The first choice acts as it is today, the second on enables a Memo field (like many others where you can add text and edit HTML) where you type whatever you want in it.

Then, on the reader side (page about/editorialTeam) the plugin checks the flag, if set just display the HTML under the group title otherwise act as usual.

So far, I don't see how to do that with plugins without changing/patching the source code of OJS.

Any suggestions? Also, if someone is experienced on OJS Development and want to help me do that I would be very thankful.

Luiz Borges

[jmacgreg]

Hi Luiz,

A couple of thoughts:

1) OJS 2.3, which will be released in a few weeks, will allow you to sort lists by drag-and-drop. This means you won't have to use the up and down arrows to reorder lists, and will hopefully allow users to sort lists *much* more quickly. (Some lists also have the option to sort by column; unfortunately, not the Masthead membership lists at the moment.)

2) Adding users to a flat text field will be much faster than the current add+arrow key reorder way, but perhaps not so much faster than the new method that it remains a worthwhile option. However, there's a quick way you can hack this in: just add your list to the template file /templates/about/editorialTeam.tpl, replacing any template logic you don't need. (If you are editing editorialTeam.tpl, make sure that you have the Masthead generation option set to "OJS lists people in Editorial Team under assigned roles (Journal Manager, Copyeditor, etc.)"; otherwise, edit editorialTeamBoard.tpl.)

I don't think we have any firm plans on modifying the way OJS handles the masthead; however, it might be possible for a plugin to override the default behaviour. I'm not sure myself, but hopefully someone else will weigh in if they have done so.

Cheers,
James

[luiz_borges]

Here are some thoughts I had about that issue:
- Create a plugin that hooks on the LoadHandler;
- The plugin callback checks for (pages=about AND op=editorialTeam AND plugin-settings=enable) then it supress the default handling and writes the content previously stored in the DB (just a TEXT field over a simple .tpl);
- The plugin has 3 verbs: enable, disable, setCustomEditorialTeam.
- The setCustomEditorialTeam just shows a simple form with a formated memo field and a Save and Clear buttons.

I think this is the most easy and simple aproach. It doesn't mess with OJS source code, it is enabled per journal if needed, and requires just a new TABLE with two fields: journal-id and contents (TEXT).

I tried some hacks on the staticPagesPlugin and aparently my idea will work fine, I just need some guidance on the whole plugin development issue. I've already read the Technical Docs but is just touchs plugins in a brief way, also I'm not very used with PHP (my main focus is C++/C#) so I need to rethink and relearn a lot of stuff.

Any comments or suggestions of the above will be greatly apreciated.

Luiz Borges

PS: Something I forgot to mention, one of the main issues here, is that our "online" journals in many cases are just online versions of tradionally printed journals. As such, most members of the editorial team are not even members of the ojs platform, so I keep having to create new users that don't actually exists. I my perspective, I think that is a very bad practice to do so, but I can't (unfortunetly) force the editors to make all members of the journal be members online.

[jmacgreg]

Hi Luiz,

You've already gone over my head, so I'll ask a developer to reply. One quick note though: I recently posted a feature request to hopefully resolve the issue of adding users who in fact don't want to be (or can't be) users within the system: http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=4508. That report has yet to be resolved, and is still sort of a hassle compared to what you're describing; if you have any further comments on that, we'd love to hear them.

Cheers,
James

[luiz_borges]

About the bug report, it originated on the topic I created earlier about that problem. About that, I think it's nice to be able to create an article without having to put an e-mail for the main author, since in many cases the article is put online by the editors (or the slav...workers, such as me). So I guess a few checks in the right places should be enough to make e-mail for author optional. But I'm sure that finding all of those "right places" will be no easy job.

But that is not my main issue, I'm used to type email@example.com so it doesn't really bug me. Also, in most places you don't need to create a fake user, the only place that really requires users to be created is the Editorial Team (as far as I know), so this is my main issue. Solving that will allow the user base of the journal to be a lot thinner, without fake/ghost users acting just as placeholders for names.

I still haven't got time to mess around the solution I posted about. I think it should be relatively easy to make and should get the job done. Also, I'm waiting for the v2.3 release, so that I may work with the most recent code base. Btw, any news on when its going to be out?

Luiz Borges

[asmecher]

Hi Luiz,

Your plugin suggestion (a plugin that, when enabled, overrides the default about / editorial team page) sounds like a great plan -- I'd suggest going ahead with it. Let me know if you have any specific questions with it.

We're just working on translations for OJS 2.3 -- we rely on volunteers to maintain the translations (and very much appreciate their work!) but it's tough to know exactly when they'll be finished. I'd expect that you'll see OJS 2.3 within a few weeks. Keep in mind that it'll be releases as an "unstable" package -- we're dividing our release strategies into "stable" and "unstable" for the first time -- so while we've done a lot of testing, you'll probably encounter a few hiccoughs. If you decide to go live with OJS 2.3, be prepared to have to patch a few things as the release solidifies. We'll do our best to help you through that here.

Regards,
Alec Smecher
Public Knowledge Project Team

[luiz_borges]

Thanks for the support. I would like to help translating OJS to portugues brazil, but unfortunetly I have no time to do that right now (also I think there's already a team into that).

Can you give me any hints about the plugin system for the new version? It will be backward compatible with 2.2.3? Any new features? Knowing that I can begin to work on my plugin.

Thanks again,
Luiz Borges

PS: About translation, how the corrections can be done? I ask that because when I tried to help on the translation of phpBB3 I reached a dead end. Since there was already a maintainer, my suggestions never went through (he seemed to have abandoned the project but was still associated with it).