Project

General

Profile

Actions

Bug #2176

open

Moderator UI and functionality for ESA

Added by Saurabh Garg over 19 years ago. Updated over 16 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
metacat
Target version:
Start date:
09/05/2005
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
2176

Description

Implement the moderator UI and functionality..(MODERATE) -- Sid * replication issues - e.g. when a user tries to update a document on
knb.ecoinformatics which was replicated from esa.ecoinformatics
(replication locks are denied if the replication is asynchronous -
with proper error sent back to user explaining replication is only one
way)
(This is from the ESA tasklist)

Detailed Notes describing this functionality

-> The first step in the life cycle of a registry entry is document insertion
by the author. For this the author should have a ldap account.
Issue: Should links to the ldap account creation be provided from the ESA home
page?

-> When the document is created it does not have public read access.
ToDo: Modify the register-dataset.cgi to not give public read access for the
documents created.
ToDo: The document has to viewed/deleted by the moderators. Hence all the
moderators should have all permission on the document.
Issue: Should email alert be sent to the moderator? To the author also with
instructions for viewing and editing the document?

-> Once the document is created, it has to be queued up for moderation. Hence
when the moderator logs into the system, he/she should be directly taken to a
search page which displays
ToDo: Create a new login page for the moderator
ToDo: Check that login/logout functionality for the moderator is working in the
skins.
ToDo: A new action should be created for moderator login? action=login can not
be used here because Metacat has to be told to check if the user is a moderator
or not. Hence either a new action has to be created. Or a new arguement to the
login action has to be creater. Metacat has to read the moderator list from
metacat.properties and it should check if the specified user is part of it.

-> Once the Metacat has checked that a user is a moderator, the moderator
should be forwarded to the search page. The search page should show all the
documents which do not have public read access with links/buttons for viewing,
accept, decline and revision of the document.
ToDo: Modify Resultset.xsl to have the above links/buttons.
ToDo: Accept leads to modification of the document to have public read access,
the document is updated in the repository and an email is sent to the author
ToDo: Decline leads to a page where the moderator can spefiy reason for
declining. Then the document is deleted and an email is sent to the author with
the reason.
ToDo: Revision leads to a page where the moderator can spefiy reason for
requesting revision. Then an email is sent to the author with the reason.

Actions #1

Updated by Saurabh Garg over 19 years ago

Correction in the previous description. This is not required:

'A new action should be created for moderator login? action=login can not
be used here because Metacat has to be told to check if the user is a moderator
or not. Hence either a new action has to be created. Or a new arguement to the
login action has to be *created.'

Moderators can be handled in the same way as administrators are handled
currently. That is when an action is requested, it can be checked if a user is
moderator or not.

Actions #2

Updated by Matt Jones over 19 years ago

I agree with all of the steps you outlined. However, the layout of the
moderation resultset was discussed as well. We want the moderation process to
be as quick and easy as possible. So we might consider a system where the
moderation form (accept, decline, revise, explanation) is in the EML document
itself (possibly rendered on the left side in its own iframe). When the
moderator makes a decision, he bonks the button and is automatically brought to
the moderation page for the next document.

Actions #3

Updated by Saurabh Garg almost 19 years ago

Moderator UI and functionality for ESA has been implemented. Waiting for
feedback from ESA and next round of changes. Hence, moving the bug 1.7

Actions #4

Updated by Callie Bowdish over 16 years ago

When checking ESA mail response for Metacat release I notice that the email path has problems on the revise document. Here are too examples:

---------
Dear Callie Bowdish,

Upon review, we feel that the metadata entry for your article submission,
Test ESA edit Mon June 11:37, is still missing some relevant information. Please read the
reviewer's comments below for any suggested additions and changes. You are strongly
encouraged to go back and address these issues with your entry. You can login,
edit, and resubmit your entry at http://chico.dyndns.org/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.3.

The Ecological Society of America

Reviewer's Notes:
This looks good, Callie. Please add a little more in the methods section.

Callie


The path for some reason does not go to the latest version number even though the "docid=esa.3". Usually when there is not a version number the version goes to the most recent data package. This path opens the data package in the online form but it is name esa.3 with no version number. If the user works with the address posted in the email they will not be able to save because there is already a version older than that one.

I am not sure if this is just on the test server.


The ESA email for when the data package is accepted says:

Dear callie bowdish,

We are happy to inform you that the metadata entry for your article submission,
Test ESA on Chico, has been accepted. This part of the submission process is now
complete. Your metadata entry can be cited in the future as <LSID>, and will be
viewable online at /metacat/metacat?action=read&cfg=esa&docid=esa.1 after publication. Thank you for your cooperation.

The Ecological Society of America


The <LSID> section and the "viewable online at .." path do not look right. Also currently if this is accepted their publication is accepted too.

Actions #5

Updated by Callie Bowdish over 16 years ago

Here is the error that show up on the current production server 1.8.0 when using the email link after logging in.
Failure
An error occurred. Please check the list of errors below:

  • Next revision number couldn't be less than or equal 2
  • Failed while updating.

Click the button below to return to the form and fill in the required fields. Do NOT use the back button on your browser. Submit the description again when you are finished.

Actions #6

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 2176

Actions

Also available in: Atom PDF