Develop a plan to complete the attributes functionality

[mrsbluerose]

The attributes functionality isn't complete yet. For instance, in ReviewDecisionService::saveReviewDecision(), we save the decision of the phrase reviewer (Accepted, Nonsense, Vulgar), but we don't do anything with it. We should be updating the tables that associate the phrase with the user if it is valid, and add it to the rejected_* tables if not.

Ensure the entire Create Attribute process works:

• UIs initial call to associate it with the user
• the scheduled job which calls our DictionaryAPI to verify the words
• being placed in queue for the Phrase Reviewer
• the Phrase Reviewer submitting a decision
• that decision causing the appropriate final tables for the phrase to be updated.

Review the work to be done and create issues. Consult in meetings for help breaking the work down.

[mrsbluerose]

Notes from meeting 9/26:

Current AttributesAPIController logic flow:

POST: applyPhraseToUser
    if phraseService.isPhraseValid (checks if missing verb/noun, 
    any word previously rejected, phrase previously rejected)
        yes: 
        if phraseService.applyPhraseToUser
            yes: 
            if isPreviouslyReviewed (and approved)
            (checks if phrase has already been approved)
                yes: 
                add to user, return true
                no: 
                add user and phrase to toBeReviewed
****                default return false
            no: 
            send notification, returns false
        no: 
        sends notification, returns false

• [x] Fixes needed (new ticket #289 ): **** logic from service should return true/false for whether phrase was approved or added to ToBeReviewed Have Api return new dto - success, error, approved, rejected, in review fields Check exception, bad request and return in error Add third Notification for in review

Current ToBeReviewed checker service:

• gets all phrases "ungroomed"

• processes them for parts of speech

• if it matches, they are updated as "groomed"

• if it does not match, they are added to rejected phrases and deleted from the toBeReviewed repo

• [ ] ToDos: send notification to user(s) if the checker rejects a phrase. (ticket)

Current ToBeReviewd logic:

• get next phrase to be reviewed

• reviewer approves or rejects the phrase

• [ ] ToDos:

• verify the review process is complete (phrase saved where needed) (ticket if needed)

• notify user when phrase is approved or rejected (ticket)