Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a request access form for a candidate (part 2 of candidate's CenterID refactoring) #4058

Open
4 tasks
cmadjar opened this issue Nov 5, 2018 · 3 comments
Assignees
Labels
Category: Feature PR or issue that aims to introduce a new feature Language: SQL PR or issue that update SQL code State: Stale PR that has had no recent activity, needs to be triaged for review or closure to proceed

Comments

@cmadjar
Copy link
Collaborator

cmadjar commented Nov 5, 2018

This will be part 2 of the future for the CenterID field of the candidate table plan (as discussed in September 2018 with @samirdas @driusan and @ridz1208, see meetings notes).

TODOs:

Create a form that will be used to request access to a candidate from another site when the candidate is switching sites so that the data entry people can have access to that candidate.

  • Creation of a new table with CandID, CenterID, Project, UserID, Approval (Y,N) and the type of access (view other sites visits for example)
  • For the type of access, the field behaviour would be:
  1. view candidate metadata + create time point if data entry permission (default behaviour)
  2. view the list of all the visits for that candidate (not clickable when not at the Users's site)
    Note, we might need a separate table in SQL candidate_access_type
  • Would only see all the visits listed (link disabled for other site so cannot see and change the data already entered)
  • [ ]Eventually, we will create a similar table for SessionID, CenterID, Project, UserID, Approval (Y,N) and type of access

Notes:

  • modules/create_timepoint/php/create_timepoint.class.inc function _hasAccess will need to be modified as it uses the candidate's RegistrationCenterID in order to be able to create a new visit for a candidate. Will have to take the other tables into account in that query

Future labels for the PR:

  • SQL
  • [branch] major
  • Add to release notes, Document at release and Notes for existing projects*

Comments from the first PR that should be done in this part 2:

@cmadjar cmadjar added Language: SQL PR or issue that update SQL code [branch] major labels Nov 5, 2018
@johnsaigle johnsaigle added the Category: Feature PR or issue that aims to introduce a new feature label Nov 13, 2018
@cmadjar cmadjar self-assigned this Jan 18, 2019
@stale
Copy link

stale bot commented Jan 8, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the State: Stale PR that has had no recent activity, needs to be triaged for review or closure to proceed label Jan 8, 2020
@cmadjar
Copy link
Collaborator Author

cmadjar commented Dec 6, 2022

@driusan @ridz1208 could we assign this to someone else?

@driusan
Copy link
Collaborator

driusan commented Dec 6, 2022

You'll get to it eventually, I believe in you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Feature PR or issue that aims to introduce a new feature Language: SQL PR or issue that update SQL code State: Stale PR that has had no recent activity, needs to be triaged for review or closure to proceed
Projects
None yet
Development

No branches or pull requests

4 participants