📝 Description

This diagram illustrates the data flow between the components/functionalities of the CMA application from the study. This application contains functionalities such as submitting manuscripts, assigning reviewers to the manuscripts (so that they become accepted papers), recommending papers, searching for papers, etc. The diagram also shows the added components for privacy policies and consents implemented in the app.

📊 Diagram: Conference Management App (CMA) Case-Study

🔗 Link to Original Paper/Article

View Full Main Source

📝 Short Description

This diagram illustrates the data flow between the components/functionalities of the CMA application from the study. The diagram is based on the code from the study, in which the nodes show different functionalities and labels show decorators that the functions had. This application contains functionalities such as submitting manuscripts, assigning reviewers to the manuscripts (so that they become accepted papers), recommending papers, searching for papers, etc. The diagram also shows the added components for privacy policies and consents implemented in the app, which was one of the main focus of the paper.

🔤 Abbreviations

• None

📖 Extensive Description (if possible)

The left side of the diagram shows the user entering its credentials (email, username, and password) into the Flask App. From here on there are 2 possible flows of data, which depend on the user being already registered or not. In both flows the credentials flow to the Login Flask or Register Flask nodes. Afterwards in the login case the credentials flow to the Check Credentials node where they are checked and consequentially to the SQLite DB node. In the case of the registration flow the credentials flow to the After Register Hook and finally to the SQLite DB. From this node there are many data flows which are forwarded to the Current User node, from where they will flow to their respective functionality nodes. Starting from the top there is the flow of candidate_reviewers data to the Show Candidate Reviewers node which forwards it to the Calculate Conflicts node. Directly beneath the manuscripts data is forwarded to the Retreive Manuscripts node which then forwards it to the Calculate Conflicts node, which makes sure that given the manuscripts and the candidate_reviewers there are no conflicts of interest (a reviewer reviews its own paper). From this node the list of candidate_reviewers flows to the Assign Reviewer node, which does the reviewer assignment. Then the "ready to review" manuscript flows to the Review Papers node. Once the manuscript has been reviewed it flows to the Save To DB node where it is saved as a (not yet accepted) paper. Continuing with the flows from the Current USer node, it sends the user_consents data to the Policy node which forwards it to the Privacy Template where the user its able to see its current consent settings. In the next flow user_consents flow to the Remove Consents node, which then forwards the actualize_consents to the Save To DB node. Accordingly the next one is again the forwarding of the user_consents to the Add Consents node, which forwards the new_consents to the Save To DB node. Next, on the lower side of the diagram from the Current User node, there are flows from an (accepted) paper to the Retrieve Recent Papers node and View Paper node. The first one then forwards the paper to the Calculate Recommendations node which then forwards it to the Recommend Papers node and lastly to the Recommend Papers Template where the user can recommend a certain paper. In the case of the View Paper node it also receives a paper_request data from the Search Papers node and forwards the paper to the View Paper Template where the user can read the paper. The last flow from the Current User node is regarding the reviewed paper data (manuscript which has been reviewed) which flows to the Accept Paper node. Here the reviewed paper is accepted and flows (as accepted_paper) to the Save To DB node. Lastly there is a last node called Submit Manuscript which sends a manuscript to the Save To DB node.

🏷️ Label description

• Its important to notice that in the code, and thus in the diagram a manuscript is a paper which has not been reviewed. This manuscript, when reviewed, is an unaccepted paper which can then be accepted.

• 🗂️ Data Labels:

  • DataType:

    • AcceptedPaper: Paper which has been accepted
    • ConsentSettings: List of consented actions/purposes of the user
    • ReviewedPaper: Paper/Manuscript which has been reviewed
    • CandidateReviewers: List of possible Reviewers
    • Manuscript: Paper that has to be reviewed and then accepted
    • NewConsents: List of updated actions/purposes of the user after adding a new consent
    • Purpose: Purpose of the user (action he/she is going to make)

  • Credentials:

    • Email: Email of the user
    • Password: Password of the user
    • Username: User name of the user

  • RequestTypes:

    • Consent: Request to get the consent of the user to do a given action
    • Paper: Request to get a paper
    • Recommend: Request to recommend a paper
    • Candidates: Request to get the candidate reviewers
    • Review: Request to review a paper
    • Accept: Request to accept a paper

• 🏷️ Node Labels:

  • Decorator:

    • Secure: Decorator that defines that given node (or function in the code) as secure
    • UserRegistered: Decorator that defines that for the given node (or function in the code) the user has to be registered
    • LoginRequired: Decorator that defines that for the given node (or function in the code) the user has to be logged in

  • ConsentedPurposes

    • PublishPaper: Purpose of publishing a paper
    • AssignReviewer: Purpose of assigning a reviewer
    • RecommendPapers: Purpose of recommending papers
    • ViewPaper: Purpose of viewing a paper

  • ResearcherTypeAllowed:

    • Normal: Normal user is allowed to do this action (and thus all user types)
    • Committee: Committee member (or Chair member) is allowed, but not normal member
    • Chair: Only chair member is allowed

⚠️ Constraints

• Sensitive data from the user such as ConsentSettings (old or new), AcceptedPaper, ReviewedPapr, CandidateReviewers, Manuscripts, and Purpose can not flow to an insecure node:

  1. secure: data DataType.AcceptedPaper,DataType.ConsentSettings,DataType.ReviewedPaper,DataType.CandidateReviewers,DataType.Manuscript,DataType.NewConsents,DataType.Purpose neverFlows vertex !Decorator.Secure

• CandidateReviewers data can not flow to a node which does not have the consented purpose of AssignReviewer:

  2. purposes: data DataType.CandidateReviewers neverFlows vertex !ConsentedPurposes.AssignReviewer

• AcceptedPaper data neverflows to a vertes without the consented purpose of RecommendPapers or ViewPaper:

  3. purpose_recommed_paper: data DataType.AcceptedPaper neverFlows vertex !ConsentedPurposes.RecommendPapers,ConsentedPurposes.ViewPaper

🚨 Violations

• None