Tracker log

An overview of recent activity in the tracker.

New issue »Transition to GroupReview state no longer populates Assigned Reviewer group..« added by Jonathan Gutow

Transition to GroupReview state no longer populates Assigned Reviewer group..Last year (2010 cycle) we had it working so that when the review forms were created the assigned reviewers we added to the "Assigned Reviewer" group. This is no longer working on the installed grant sites (2011).

Added 471 day(s) ago.

New issue »Need to update proposal_member_view template in product..« added by Jonathan Gutow

I have customized this template on the production site trying to clarify things for proposers. These changes should be folded into the product.

Added 846 day(s) ago.

New issue »Need to fold customized file_view template into product« added by Jonathan Gutow

I customized the file_view template (in skins/plone_content) to provide instructions for proposers after they upload the proposal file. It should probably include a tal statement making this only show for files loaded into proposals, but it now shows for all uploaded files.

This customized template should be built into the product. For the time being it has been hand coded into the two production sites.

Added 846 day(s) ago.

New issue »Have two equivalent object tabs...« added by Jonathan Gutow

The object tabs "Change Reviewer" and "Change Reviewers" were equivalent. On the production sites I have removed the "Change Reviewer" tab manually. This also needs to be done in the product if it isn't already done.

Added 865 day(s) ago.

New issue »take_reviewerform_ownership should not check for creator« added by Jonathan Gutow

take_reviewerform_ownwership was checking as follows

if ci.Creator()<>"Reviewer":

causing no change when the "Change Reviewers" tab was clicked. This script is for updating the reviewers after the forms have been created if they must be changed.

Fixed on site by changing statement to
if ci.Creator():

need to fix in product as well.

Added 865 day(s) ago.

New issue »Faculty group needs role uwosh.grants.faculty« added by Jonathan Gutow

I've set this manually on the sites. Should this be part of the product?

Added 866 day(s) ago.

New issue »Reviewers could not save review forms on new install ver 1.3« added by Jonathan Gutow

Reviewers could not save review forms on new install because they did not have add Portal Content permission for the proposal (a folder). This has been changed for just the groupReview state of the proposal, in 1.3 build 9.

Added 899 day(s) ago.

New issue »Stats tab should only be visible after transition to panelReview state« added by Jonathan Gutow

At present the Stats tab is visible during the review process. This is confusing and not informative as the average doesn't mean anything until the reviews are completed. A number of reviewers asked about that last year.

Added 899 day(s) ago.

New issue »Product allows proposers to change default view and shouldn't« added by Jonathan Gutow

The product still allows users to change the default view of a proposal and shouldn't. I believe this has been fixed manually on the actual sites, but should be corrected in the product as well. The fix is to turn off Acquire permissions at the root level in Modify View Template and allow only the manager at that level.

Added 900 day(s) ago.

New issue »Convert Proposal Folder to normal folder« added by Jonathan Gutow

To efficiently use csv data export we the proposal folder cannot be a large plone folder as csvreplicata has trouble reading the tree structure. This is also changing substantially in Plone 4 so we may have to adapt anyway.

Added 908 day(s) ago.

New issue »Faculty, Staff, Student groups not showing up in groupmailer...« added by Jonathan Gutow

The new groups Faculty, Staff and Students are not showing up as possible groups to mail to in the groupmailer. Is the groupmailer looking at the group list every time?

Added 972 day(s) ago.

New issue »Adjust proposal workflow to allow sharing of private proposals« added by Jonathan Gutow

The permissions on the private state in the proposal workflow should be adjusted so that they can be shared with others for editing. Thus a faculty member can initially set up the proposal and allow their student to make changes.
Necessary changes:
For Editor allow the following explicitly
Access contents information
List folder contents
Modify portal content
View

For Reader
Access contents information
List folder contents
View

Added 975 day(s) ago.

New issue »Rule: all proposals go to the Proposal folder needs to be incorporated into product...« added by Jonathan Gutow

I created the rule by hand on the ugrad site and can do the same on the grad site. However, long term so that a reinstall can be done, this rule needs to be part of the product. See issue #51.

Added 982 day(s) ago.

New issue »Change security permissions on csvreplicata on install« added by Jonathan Gutow

So that the grants director can adjust what fields are ignored without having full management rights on the site the when csvreplicata is installed set the permissions on the tool to the same as the manager. This will allow the director to follow the link "portal_csvreplicatatool/csv_settings" to the tool management page, without giving them access to everything else. Completed on ugrad site 8/3/09.

Added 1027 day(s) ago.

New issue »grants director unable to add reviewer form...« added by Jonathan Gutow

Only administrators can add reviewer forms to a proposal. It is unclear what is going on. On my test site, I have tried setting permissions so that those for the grants director match the manager for all add and edit content settings, but still get the error "do not have permissions to access @@at_base_edit_view in this context." Since they can be added from the administrator account this is just an annoying problem.

Added 1040 day(s) ago.

New issue »Update permissions on private proposal to allow director and manager access« added by Jonathan Gutow

Access contents information
List folder contents
Modify portal content
View

allowed director and manager access to all of these.

will need to update on grad site as well.

Added 1052 day(s) ago.

New issue »Transition to directorReview sets "view" permissions incorrectly...« added by Jonathan Gutow

When proposals are submitted and transitioned to the state directorReview the view permissions are set to give "members" view permission. Instead "owners" should have view permission as they do in the groupReview, panelReview and proposerReview states. All the other view permissions appear to be correct.

This is causing all proposals in the directorReview state to be visible to all logged in users. We only want them visible to the owner, director and administrators.

Added 1052 day(s) ago.

New issue »Correct fields and instructions on the proposal form« added by Jonathan Gutow

*Proposal submission form should contain the following fields (view permissions listed for each field):
**Student Proposer 1 (to be filled in by user)
  Who can view in which state:
    private/unsubmitted: original creator, uwosh.grants: Directors, Administrators
    DirectorReview: original creator, uwosh.grants: Directors, Administrators
    GroupReview: original creator, uwosh.grants: Directors, Administrators
    PanelReview: original creator, uwosh.grants: Directors, Administrators, uwosh.grants: Panelists
    ProposerReview: original creator, uwosh.grants: Directors, Administrators
    Archived: original creator, uwosh.grants: Directors, Administrators
**Student Proposer 1 E-mail (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student ID number for Proposer 1 (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student 1 Street (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student 1 City (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student 1 State (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student 1 Zipcode (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student Proposer 2 (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student Proposer 2 E-mail (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student ID number for Proposer 2 (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student 2 Street (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student 2 City (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student 2 State (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Student 2 Zipcode (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Primary Faculty Advisor (populated automatically as the submission should be from their account)
  Who can view in which state: same as "Student Proposer 1"
**Primary Faculty Advisor E-mail (populated automatically)
  Who can view in which state: same as "Student Proposer 1"
**Primary Faculty Advisor department (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Faculty Advisor 2 (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Faculty Advisor 3 (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Academic Year or Summer radio button (to be filled in by user)
  Who can view in which state: same as "Student Proposer 1"
**Title (to be filled in by user)
  Who can view in which state:
    private/unsubmitted: original creator, uwosh.grants: Directors, Administrators
    DirectorReview: original creator, uwosh.grants: Directors, Administrators
    GroupReview: original creator, uwosh.grants: Directors, Administrators, uwosh.grants: Reviewers
    PanelReview: original creator, uwosh.grants: Directors, Administrators, uwosh.grants: Panelists
    ProposerReview: original creator, uwosh.grants: Directors, Administrators
    Archived: original creator, uwosh.grants: Directors, Administrators
**Abstract (rich text field to be filled in by user)
  Description field for abstract should contain the following text: "The abstract must be 250 words or less and self-contained. Without restating the project title, it should begin with a topic sentence stating the project’s major thesis. The abstract should include, if pertinent to the project being described, the following items: 1) the primary objectives and the scope of the project; 2) summary of intellectual background (is the work scholarly?); 3) the techniques or approaches used (only to the degree necessary for comprehension). Abstracts do not usually contain citations unless the cited work is the subject of the project."
  Who can view in which state: same as "Title"
**Student was primary author check box (to be filled in by user)
  Who can view in which state: same as "Title"
**Save form data button
**In the view after save form an "Add file/upload file" button should appear next to or above save.
**In the view after save form a "Submit" button (if it could hide until a file is uploaded great).
**The view after submission should not change except that editing and uploading should not be available.

Added 1052 day(s) ago.

New issue »Make the createObj = proposal script add user to proposers and do some checking...« added by Jonathan Gutow

The site is now set up so that any logged in user can add a proposal. This is the ideal functionality. However, for later book keeping it is important that everybody who adds a proposal be a member of the group uwosh.grants: Proposers. Ideally, we also will only let faculty accounts create proposals. So:

1) The script should check that the username doesn't end in two numerical digits. If the ID ends in two digits the user should get a page with the warning, "Sorry, your account is not authorized to create proposals on this site. Proposals must be created from faculty accounts. If you believe you got this message in error please contact the site administrator." (site administrator should probably link to the manager e-mail). In the few cases where faculty have numbers at the end of their account name we will just have to create a special account for them.

2) If the username passes the test they should be added to the group uwosh.grants: Proposers before the proposal is created.

This would be a major improvement over presently requiring people to click a link to get added to the Proposers group. Even if we have to maintain this link the checking for account eligibility needs to be implimented.

Added 1052 day(s) ago.

New issue »Proposals were not all going to proposal folder...« added by Jonathan Gutow

Using the add proposal link proposals were being dumped into which ever folder the user was in. Fixed on the undergrad site by creating a rule that moves all proposals upon creation to the proposal folder. Will need to be added to the grad site.

Added 1053 day(s) ago.