VegBank

• Bug 866 has been marked as a duplicate of this bug. ***

not critical bug to be highlighted in red, but very important

One of the 5 major (critical on bugzilla so higlighted red) bugs:

We must implement the new intellectual property design so that plots with
current embargoes are not viewable. This will use changes made for version
1.0.2 vegbank model.
-------------------------------------------------
-----WHAT USERS SHOULD BE ABLE TO VIEW ----------
-------------------------------------------------

Changes in field usage: plot.confidentialityStatus may only contain 0-3 meaning
no fuzzing of lat/long, or up to 100km of fuzzing. This is necessary, because
there can only be one value in lat or long, so different users cannot each see
views of the plot with coordinates fuzzed to different degree.

Whenever a user attempts to view or download a plot, or child of plot (orange,
teal [not project], grey, and yellow tables in ERD), embargo.defaultStatus must
be checked, where embargoStart is before now and embargoStop is after now
(embargo stop date REQUIRED, ie it must expire). Currently the following values
apply to defaultStatus:
0 Public
1 1 km radius
2 10 km radius
3 100 km radius
4 Location embargo
5 Public embargo on data
6 Full embargo on data

IF: 0-3, then all normally viewable fields (ie NOT realLatitude,
confidentialityReason, embargo table), should be viewable.
--------
IF: 4, then the following fields/tables should not be viewable:
plot.{fields:
realLatitude
realLongitude
locationAccuracy
confidentialityStatus
confidentialityReason
latitude
longitude
authorE
authorN
authorZone
authorDatum
authorLocation
locationNarrative
placementMethod (may contain loc info?)
}
place table {all fields}
-------
IF:5
User may request permission to view this plot. I am not sure how the user
finds out about the plot's existence. My worry is that this will be challenging
to implement, if, for example, the query can see the plot, but the user can't.
Perhaps certain views of plots for case 5 will be OK, others not. For example,
the plot could be returned to the "list of plots matching your query" but
detailed and summary views wouldn't be available. Others with technical
know-how should comment on this. Users requesting permission is talked about below.
--------
IF:6
Do not let users see this plot.

(see next comments on users requesting permission to view and how to consider a
user's special permission that may exist)

----------------------------------------------------------------------------
---- THE PLOT IS CONFIDENTIAL TO SOME DEGREE BUT THE USER HAS PERMISSION
----------------------------------------------------------------------------

IF a plot is not viewable to a user, or only to a lesser degree
(embargo.defaultStatus>0), then the user may have special permission from the
plot owner to view the plot anyway. This would be found in userPermission table
corresponding to the usr_id of the user and the embargo_id of the embargo. If
the current date is between the permissionStart and permissionStop, then their
permission value is userPermission.permissionStatus, not embargo.defaultStatus.
See above for what this means. 0-6.

For 0, we may want to allow the user to download the realLatitude and
realLongitude- some business rule may need to exist for this. If the user is
assigned permission of 1-3 (1,10,100 km radius fuzzing), then this value should
match plot.confidentialityStatus. Then they can see lat&long. If the user's
permission is 4, then the same fields that are hidden above in case 4 should be
hidden now. Case 5 and 6 seem absurd. This shouldn't be a valid value for
userPermission.permissionStatus (see next comment).

------------------------------------------------------------
--------- OK so a user wants to request permission, how does this happen?
------------------------------------------------------------

We need a form that we can link to when a user is denied permission to viewing a
plot (defaultStatus=4,5). Business rules not yet in existence need to deal with
cases where the defaultStatus=1-3 and user wants to know exact coordinates. In
theory, they should be able to use the same form.

The form would state the plot(s) the user would like to view that a particular
plot owner has embargoed. Initially, this form could be filled out once per
plot, but better would be once per plot owner. The form would show the plot the
user wanted to see, the owner's name, and allow the user to fill in information
about him/herself [basic stuff we can send from the user's party info] and why
they want to see the plot. They would press submit and we'd send an email to
the plot owner (as determined in table:UserRecordOwner, find the owner of the
plot record), which would state that a user has requested permission to see
their plot #XXX and why. It would also have a link to a page where the user
could login, then grant permission to the first user.

the form where the owner gives permission would be much like the administrative
pending tasks for mailman on hyperion's mailing lists. The plot owner could
either accept/reject/accept at a different level than the owner requested, or
discard (in case of abuse of this, in which case cc to dba). The plot owner
would optionally stop date of the permission and any notes that they wanted to
record about this permission granting. All this info, along with teh current
date for permission start go into a new record in user_permission table for the
user and embargo in question.

Bob, please read through this bug and my long-winded descriptions and then, if
OK, please pass along to Mark.

bug 835 = form for owner to provide permission

the thing that is high priority here is ensuring that embargoed plots cannot be
viewed. Building forms to request and grant permission are lower priority (835)

fuzzing of lat/long according to new rules listed on the wiki has been
implemented in VegBranch

we could initially have an all-or-nothing embargo whereby plots exist in
VegBank, but are completely unaccessible (by anyone) until we build tools to
selectively get around the embargo. We would do this by using SQLStore and
database views (SQL) to create a list of "ok" data to show, and only these
tables would be referenced in SQLStore.

All-or-nothing embargo now complete through our standard view. Plots that are
completely embargoed (level 6) cannot be viewed through our standard views.
This has holes in that there are places (plot-query and download most notably)
where the plots can be viewed in part, and in the case of download, completely
accessed.

This bug is now in PMark's court to test when the download feature (most
importantly) and plot-query use either the same SQLStore as everything else, or
use the SQL-views I created to accomplish this.

example plot that is embargoed on aldo:
http://aldo.vegbank.org/get/std/observation/8896

compare to vegbank:
http://vegbank.org/get/std/observation/8896

the rest of the views could probably use a little QA to make sure I didn't break
anything with my monkeying around with the SQL

simple system is mostly done, and put into a new bug 1925

Original Bugzilla ID was 919