Dockerize application

[brcb20]

Improve local stack by containerizing the application, provide a local Postgres instance (to facilitate the creation of migration scripts that require manual intervention), and a mail server/client (to visually edit outgoing e-mails).

[tsdobbs]

UPDATE: Problem below was simple - had to authorize in Windows that Docker could access C: drive.

---

Received error on docker-compose up -d --build:

.
.
.
Successfully built fd089c314940
Successfully tagged artbot_artbot:latest
Creating artbot_maildev_1   ... done                                                                                    Creating artbot_artbot-db_1 ... done                                                                                    Creating artbot_artbot_1    ... error                                                                                   
ERROR: for artbot_artbot_1  Cannot create container for service artbot: b'Drive has not been shared'

ERROR: for artbot  Cannot create container for service artbot: b'Drive has not been shared'
ERROR: Encountered errors while bringing up the project.

Looking into it, but any advice in the meantime is appreciated.

[tsdobbs]

Bug: when user submits a second artpiece while first is still active (Status = Submitted), artpiece is accepted into db and labeled status = Awaiting Payment, but user receives message "Try submitting again once your other artpiece is finished", with no opportunity to pay.

Opportunity to pay can and will be implemented, but what is the mechanism to clean this up if no payment happens?

[tsdobbs]

Schema question: What is the value of having a separate Confirmed column instead of adding a category to the Status column like "Submitted" followed by "Confirmed", or similar?

[tsdobbs]

Bug: when user submits a second artpiece while first is still active (Status = Submitted), artpiece is accepted into db and labeled status = Awaiting Payment, but user receives message "Try submitting again once your other artpiece is finished", with no opportunity to pay.

Opportunity to pay can and will be implemented, but what is the mechanism to clean this up if no payment happens?

Cannot recreate, which is almost more concerning.

[brcb20]

Bug: when user submits a second artpiece while first is still active (Status = Submitted), artpiece is accepted into db and labeled status = Awaiting Payment, but user receives message "Try submitting again once your other artpiece is finished", with no opportunity to pay. Opportunity to pay can and will be implemented, but what is the mechanism to clean this up if no payment happens?

Cannot recreate, which is almost more concerning.

This branch does not have any code related to payments. However, when you start the docker container, it creates a volume that is linked to your local file system. The root is the application directory. If you change the content of the application directory by checkout another git branch for example, those changes will be reflected in the docker container.

UPDATE: I will write tests for all endpoints

[brcb20]

Schema question: What is the value of having a separate Confirmed column instead of adding a category to the Status column like "Submitted" followed by "Confirmed", or similar?

When I have the admin panel up and running, I planned on removing the status column entirely. If an artpiece is confirmed, it will be assigned to a print job (which is equivalent to updating the status to "processing") and then each print job will have a list of more specific status updates. There are some things that need hashing out but we can discuss them later.

[tsdobbs]

Seems sensible

On Tue, Jan 21, 2020, 9:25 AM Benjamin B notifications@github.com wrote:

Schema question: What is the value of having a separate Confirmed column instead of adding a category to the Status column like "Submitted" followed by "Confirmed", or similar?

When I have the admin panel up and running, I planned on removing the status column entirely. If an artpiece is confirmed, it will be assigned to a print job (which is equivalent to updating the status to "processing") and then each print job will have a list of more specific status updates. There are some things that need hashing out but we can discuss them later.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cclrobotics/ARTBot/pull/44?email_source=notifications&email_token=AEB3IRXL7WWJOUSHWJNCGQTQ64VZNA5CNFSM4KGXQLV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJQRXSA#issuecomment-576789448, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEB3IRRXP5BT64FZ443HZETQ64VZNANCNFSM4KGXQLVQ .

[tsdobbs]

Bug: when user submits a second artpiece while first is still active (Status = Submitted), artpiece is accepted into db and labeled status = Awaiting Payment, but user receives message "Try submitting again once your other artpiece is finished", with no opportunity to pay. Opportunity to pay can and will be implemented, but what is the mechanism to clean this up if no payment happens?

Cannot recreate, which is almost more concerning.

This branch does not have any code related to payments. However, when you start the docker container, it creates a volume that is linked to your local file system. The root is the application directory. If you change the content of the application directory by checkout another git branch for example, those changes will be reflected in the docker container.

UPDATE: I will write tests for all endpoints

Re: Tests - GREAT!

W/r/t the submission status issue - yes, on examination this was an accidental merge to the working Paypal branch I'm developing. Will reset head and check again.