Set up Sprint 2 formatting on confluence and create issues for the next 2 weeks. Set soft deadlines
Understand Sprint 2 Spec (everyone on the team)
\uD83D\uDDE3 Discussion topics
...
Time
...
Item
...
Presenter
...
Item
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.