1. write a separate management script with help of old script
2. check constants taken in old script and check if they match in new records eg: property

once we complete #10, these tests should run every time a pull request is filed, to make sure that existing APIs are not breaking due to new changes.

AS a data donor, I want to upload my data using a Web UI or a RESTful Web API.

• copy it from the online version
• implement it in the backend
• test locally if it works by poining the wikidata plugin (installed on your wikidata account!) to your local server and check if it is working

As a developer, I want to see existing facts.

• As a dev, I want to see fact candidates from the new service retrieved via RESTful call for a specific Wikidata entity (e.g., GET /facts/Q1106)

we need to implement Oauth via Wikidata instead of MediaWiki

1. Do not show accepted facts again to any user.
2. Do not show rejected facts to users who rejected them.

Context

The new WikidataComplete web service needs to be compatible with the old one.

flowchart LR;
subgraph firstiteration["first iteration"]
  direction LR
  WikidataGadget[["existing\nWikidataComplete\ngadget"]] -- Restful\nrequest --> NewService["new\nWikidataComplete\nweb service"]
  NewService -- Restful\nrequest  --> ExistingWikidataComplete[["existing WikidataComplete\nweb service"]]
  NewService -- store\nprocess\ninformation --> Database[(Database to store\n additional information\nabout the process,\ne.g., the actions per user)]
  NewService -- deploy\nautomatically --> DeployServer
  DeployServer>http://demos.swe.htwk-leipzig.de/ ]
end

style firstiteration fill:#fff,stroke:#333
style WikidataGadget fill:#ccf,stroke:#333
style ExistingWikidataComplete fill:#cfc,stroke:#333
style NewService fill:#fcf,stroke:#333
style Database fill:#ffc,stroke:#333
style DeployServer fill:#cff,stroke:#333

Thereafter, we will allow data donations.

flowchart LR;
subgraph seconditeration["later iteration"]
  direction LR
  WikidataGadget[["existing\nWikidataComplete\ngadget"]] -- Restful\nrequest --> NewService["new\nWikidataComplete\nweb service"]
   ExistingWikidataComplete[["existing WikidataComplete\nweb service"]] -- donates Wikidata\nfact candidates\nvia Restful request  --> NewService 
  NewService -- store\nprocess\ninformation --> Database[(Database to store\n additional information\nabout the process,\ne.g., the actions per user)]
  NewService -- deploy\nautomatically --> DeployServer
  DeployServer>http://demos.swe.htwk-leipzig.de/ ]
end

style seconditeration fill:#fee,stroke:#333
style WikidataGadget fill:#ccf,stroke:#333
style ExistingWikidataComplete fill:#cfc,stroke:#333
style NewService fill:#fcf,stroke:#333
style Database fill:#ffc,stroke:#333
style DeployServer fill:#cff,stroke:#333

Definition of Done (DoD)

• @D063520 @gabinguo Please provide an API description of the existing web service (green)

• @lalit97 Please implement the new web service (magenta) which is a wrapper for the existing web service (green) (see also #11 )

  • i.e., each request to the new web service (magenta) is translated into a request to the existing web service (green)
  • hence, the following should be true: the new web service can be used as backend for the existing WikidataComplete Gadget (blue) (only the web service URI needs to be changed), i.e., it behaves exactly the same
  • @lalit97 the requests to the existing web service are in a separate Python module (i.e., your web service should consist of at least two Python classes)
  • @lalit97 your common.js was changed to point to the new web service, in the next meeting show that you can add facts like with the existing web service

• (skipped) @lalit97 create a Dockerfile for the new web service (magenta)

• (skipped) @lalit97 after having finished the new web service inform @MindMaster98, he will provide a GitHub action to deploy the new service automatically to the demos server (cyan)

  • the Docker image of the new web service is pushed automatically to Dockerhub
  • the Docker container is automatically deployed on http://demos.swe.htwk-leipzig.de/
  • the URL of the new web service on http://demos.swe.htwk-leipzig.de/ is documented here in a comment

• @lalit97 the API was documented using OpenAPI

  • the API documentation of the new service should be exactly the same as the old API

• (skipped) @lalit97 make application parameters configurable via argparser or similar (see example)

• the implemented functionality is tested (automatically) using a unit test

• the version of the artifact was incremented (using Semantic Versioning -- ask @anbo-de if you are unsure what increment should be used) and documented here in a comment (use GitHub releases functionality)

  • the first version should be 0.1.0

• the documentation was checked and was updated if necessary, updated documentations are linked here in a comment

• the corresponding commit was mentioned here in a comment

As a user of a WikidataComplete Web UI, I want to log in using my Wikimedia account.

Remark: An OAuth2 mechanism would be preferred.

POST API endpoint needs an example in the Open API description.

DoD: A user can instantly recognize by an example how to use the data donation API works.

As per discussion with Andreas and Guo last to last week, we need 2 new fields in the table for implementing accept, and reject APIs and showing question text.

(1) feedback field for collecting feedback from editors
default = None
can be None/True/False

correct/ published (old schema) --> feedback (new schema)
(correct or published fields from the old schema should be mapped with feedback in the new schema for the existing fact records)

published = True -> Feedback = True (current date)
published = False -> Feedback = False (current date)
published = None -> Feedback = None (we have not received feedback yet. date = empty)

example feedback = {"feedback_date": 01-01-22, "feedback": boolean, "user_id": wdtId}

(2) question (old schema) --> meta_information (new schema)

meta_information = { # replacement for question field
"question": "" # current, donations can have anything
}

• facts detail and list API should not include accepted and rejected facts.
• test APIs by reloading the page in UI after accepting and rejecting facts. The page shouldn't break and API should not return accepted or rejected facts.

refer
https://zellwk.com/blog/github-actions-deploy/
https://www.advantch.com/blog/how-to-deploy-your-python-app-to-a-virtual-private-server-vps-using-github-actions/

• For all OpenAPI functions, at least one test was defined.
  • Each test that is sends information reads the payload of the message from a JSON file that is stored besides the test classes (s.t., the data is separated from the test implementation)

(optional for this milestone)

DoD

• As a user, I want to login and see the upload form.
  • integrate login from #45 into the Web UI #53
  • Requirements:
    • menu items:
      • show link to highscore of the current user #54
      • show link to upload form
      • show account information of the current user
      • show logout button
• Bootstrap was integrated into the React frontend
  • use a standard theme (to have good visual appearance)
  • might be established using https://react-bootstrap.github.io/
• the code was deployed automatically on https://datacompletewiki.toolforge.org/

Static files not loading on Toolforge due to which swagger docs and DRF browsable APIs are loading HTML only.