andrewpoppe / redcap-pro Goto Github PK

Currently hard-coded in reset-password.php

$pw_len_req = 8;

With links to the project, # of patients enrolled, # of users, etc

i.e., ideally don't access SESSION variable except from auth class

Disallow users from manually changing hidden values in form and submitting to take actions they shouldn't be able to, e.g., changing email address for participants that are not enrolled in the study or are not in the correct DAG

Manage

• Each page checks role
• Each function checks that combination of project, user, participant, and DAT is appropriate (e.g., even if participant is enrolled in study and user has appropriate role, don't allow user to take action on participant if they are in the wrong DAG)

• #30

Needs to be logged:

• EM enabled in system
• EM disabled in system
• EM enabled in project
• EM disabled in project
• Participant registered
• Participant opens password set email
• Participant sets/resets password
• Participant initiates password reset email
• Participant initiates username email
• Participant enrolled in project
• Participant disenrolled from project
• Participant logs into survey
• User added
• User role changed
• User initiates password reset

All errors/failures to perform any of the above need to be logged:

• EM enabled in project
• EM disabled in project
• Participant registered
• Participant opens password set email
• Participant sets/resets password
• Participant initiates password reset email
• Participant initiates username email
• Participant enrolled in project
• Participant disenrolled from project
• Participant logs into survey
• User added
• User role changed
• User initiates password reset

timeout time, timeout duration, password complexity, etc

consider this

Enroll should not allow searching but rather user should only see particpant information if they enter complete email address.

• Change search functionality
• Change instuctions on enroll page
• Change README instructions
• Change Home page instructions

• Should be able to be requested by the participant
  • How?
• Should be able to be done by REDCap admin

Require setting the FROM email address in system settings

And fill in as many of the log details as possible (minus identifying info of participants)

Now that text is translatable, remove the "Patient Reported Outcomes" from the logo

Some buttons are blue, others red

Currently it is only logged in the project in which that change was made.
As this can have potential implications for authentication, it should be noted in all logs

1. Should this be achieved by sending separate logs to every project the participant is enrolled in?
   Pros:
   * No changes needed in the way the logs page works in the projects
   * Easy to implement
   Cons:
   * Multiple logs in the system logging page

2. Or for the project to be able to "listen" for email-change events in its logs.
   Pros:
   * No changes needed in the logging code itself
   Cons:
   * Seems prone to bugs and fragility... When I enroll a participant into my project, do I suddenly see all previous email changes for that participant? Or should the date of enrollment into the project be consulted? What if they are disenrolled and then re-enrolled? If I disenroll a participant, do I stop seeing email-change logs that have already happened?

Seems like #1 is the way to go

file structure should make sense

green checkmark or something

change to png?

currently 2 = monitor, 1 = regular user
switch those

Log everything:

Project:

• Enabling Module
• Disabling Module
• Configuration saved (or just remove config altogether, see #54
• Reset Password
• Change Name
• Change Email
• Disenroll
• Search on enroll page
• Click name on enroll page
• Submit Enroll form
• Submit Register page form
• Submit Study Staff form
• Change settings
  • Include what changes were made
• Exporting logs

Control Center:

• System enable
• System disable
• Configuration saved
• Reset Password
• Change Name
• Change Email
• Reactivate/Deactivate Participant
• Exporting Logs

Then incorporate in emails etc so participants have someone to contact.

Fully describe EM

ADMIN

• Overview / Description
• Installation
• Enabling EM in System
• Control Center functionality
• Enabling EM in a project
• USER: Project Settings
• USER: Managing Staff

USER

• Project Settings
• Managing Staff
• Registering Participant
• Enrolling Participant
• Manage Participants
• Action Tags: prefill user information in data entry forms

PARTICIPANT

• Setting password
• Password reset
• Logging in
• Email/Username reminder

Can be simple datatables - level 3 only

in project and in cc

• Describe how the text translation works
• List currently supported languages
• Describe how to submit additional languages

should be "in this system" or the like as opposed to "in this project"

• Should detect which DAG a user is in
• Participants should be placed in a DAG when enrolled
• Participant tab should populate only with participants in same DAG as user
• Login should check if survey DAG matches DAG of participant
• Participants table should have column for DAG
• Make sure data entry form selector only shows participants from correct DAG
• Users not assigned to a DAG should have dropdown choice of DAG when enrolling
• Participant tab should have dropdown to select which DAG for users in multiple

Probably add validation function when project settings are saved (see CAS Login module for reference)

save the preference as a cookie

What should be here? Pertinent sections of README?

• Email change
• Password change
• Name change

• Participant-facing pages
• config file
• All pages

Table with # of participants, # of users, etc

Must respect system and project settings, as with login screen

I don't like this page depending on a VSCode plugin to recreate...
Instead, link directly to a markdown file on Github and let Github handle rendering to html

• Create simple markdown doc
  • Brief intro
  • How to use
  • What it is like for participants
• On home tab, link directly to Github page for that doc
• Erase current home.html

REDCap Admin only (and participant-initiated as well?)

1. Admin initiates change (saves new email address)
   1. New email address saved in table
   2. Account is deactivated
   3. Email is sent to new email address for verification
2. User clicks link in verification email (and then signs in?)
   1. Account is reactivated