2022-03-01 Meeting notes

Sprint 1 / Spirt 2 discussion with Max

• Overview - Max is skimming through our Sprint 1 work. Questions about how to get invoices - team has to decide this. This API is public - we will need authorisation etc etc, may be difficult to link to the file system. Make another end point that user regos - gives them a token. Everyone has a different API -we have to link up with other people - there's a chance that it won't work with each other - would be a problem with everyone.

• Write up a “middle” - make input and output of API very basic - not as specific.

• Put a universal password on the token - send a request - cannot be a random individual.

• Can we have it open to everyone? Make everyone pay for the API xd.

• Performance : minimal amount of time to be complete.

• Can we direct the calls - for people to access API - Heroku is free - and has automatic git integration.

• Log our tasks - do we need to do this on a database - scalability - do we want it on a file system. Joshua has had experience doing this → use SQLite. AWS free SQL servers. SQL Alchemy on python to merge.

Data Modelling

• Data is the login

• If we want to store the XML files, can store this in the database - would this be apart of storage? - another section (refer to spec).

• Python - class - may need a UML diagram. Purefly just functions - do all the logic in the function. Have a diagram. Implementation may be more complicated than it seems currently.

• Technical designs - determine what the model should look like.
  

Non functional requirements

• Tips : Creating user stories - “As an individual using the API?” - sensitive information - do not want this available to everyone. Privacy issues. Do not want random individuals to have access.

• Who's is hosting : we are hosting the API?

• NOT storing XML but transaction report. who, when, how big the file was, take basic information e.g. name. Have a brief overview of what occurs. If we dont keep the XML

• XML : take it in the UBL format - validation. Assumptions - don't check that its has been validated - and assume OR check that it has been validated - assume that it is validated (in the spec)

• Emails : getting this out of the XML file. One example does, other doesn't. Take input of file separately - give us email or find in XML : Yes, dig into XML - can put into parameters - if we dig in then we cant do multiple recipients? 3 email in the invoice - client and consumer. 3 in the ATO example.

• One of our epics is sending to multiple recipients - if we dig through, and there is only 1 client, then yes delete? or keep. They want us to dig this into the XML - doesn't matter what the file sender is.

• If we change the epic now, is that okay?

Requirements

• Completing the requirements page →

• Make reuqiremtns for seicirty, authenticity and performance

• Have an API that not everyone can use -

• Issues with a lack of privacy - must be protected (from spec)

• No one is going to use this, this spec requires us to save it.

• We have an admin account / email / token and then individuals will use the API - register them. Have to manually go through - allows for it to be secure + not very efficient.

• Authenticity - can priorities our own account.

Tickets

• Requirements have all changed - thus we need to change the issues that were created at the end of Sprint 1

• Have to create issues - find email in XML , add more technical tickets

• Come to a conclusion of authentication - need to write requirements for this

Timeline

• Timeline : write up our requirements, Write design our database, make our ER diagram for the database, design our interface, write up a mini starter for UML, then start coding

Delays - from waiting, can also use Heroku database.

Register the SQLdatabase in async.

Do not have to worry about algorithm - performance tricks