Bug #282


need update/delete handling for data registry

Added by Matt Jones over 21 years ago. Updated over 19 years ago.

In Progress
Data Registry
Target version:
Start date:
Due date:
% Done:


Estimated time:


The current registry is insert-only: How are updates to be handled. How does a
user obtain & modify a current metadata record & submit for update? Morpho?
Other? Could use XSLT to transform the XML doc from metacat into the HTML
entry-form.html format. Other possibilities.

Do we need/want a "delete" function?

Actions #1

Updated by Saurabh Garg over 19 years ago

The current interface has insert and query capability. But a popular demand is
to also have the ability to modify the previous records. But allowing
modifications of previous records lead to the issue of security - a record
written by someone can be modified by someone else. This maybe done with a good
intention. But such functionality can be highly misused if not used with

Authentication can only be done using a username and password. (is there any
other easier way?)For researchers entering metadata, this might be a turnoff.

So we could give them a choice between the following:
1. If they choose not to edit the metadata later, they can skip the part of
entering username and password. The metadata will be added to the database
using a default account.
When the record is requested for modifying, it won't be reachable by the user
as user doesn’t know the default username and password (which is required to
modify the account). So the record is still modifiable - but just by admin.
2. If they choose to edit the metadata later, then they will have to enter a
username and password. The metadata will be added to the database using the
username and password provided.
When the record is requested for modifying, it would be reachable by the user
using his username and password. So the record is modifiable only by the person
who created it. (Maybe we can let the default account also modify any entry -
as Rudolf won't be checking all the entries. If someone adds a rogue entry
which is found later, it could be modifiable by the admin using the web

For now, we are going to hard code option 2 without giving the user the choice.
Maybe in future we can give the above choice to the user.

Another requested feature is that the data entered should be confirmed before
entering into the system. After the user submits the data, a page should be
shown which shows all the data entered, so that the person can confirm the
data. At the end of the page we can have a username and password field. The
buttons would be submit and reset. We could also add options for ACL. That is
the user can decide whether to make the document public or private.

In case submit is pressed, the username - password fields will be checked. If
correct, the metadata will be entered to the database. If not correct, it can
be forwarded to a new webpage requesting to register or find out password for
your username. If reset is pressed, the register dataset page is shown back
again. (.. with fields filled with old entries)?

Also when retrieving a document for modifications – a check should be made as
to any additional information has been added to the document. That is, has
something been added to the document which cannot be shown using the webpage.
If yes, then the user should be told that the document is not modifiable using
the web interface and the user should use software like Morpho to edit the

(Solution to Bugs 282 and 283 are related?)

Actions #2

Updated by Redmine Admin about 10 years ago

Original Bugzilla ID was 282


Also available in: Atom PDF