When a user adds a group to a new flat, it's likely the same as some group in the existing flat. In such a case, it would be convenient to copy all the group items from the existing group.

So, at UI some suggestion is needed, and the corresponding endpoint should be provided by the backend and used by the frontend.

This issue is already implemented at the backend, the corresponding closed PR can be found in "mentioned".

It's not a priority, but it would be great to have CI, including

• build check
• tests pass check

Currently, the way errors are compared in tests is their error messages comparing. It is quite reliable, but perhaps comparing types/objects would be better, e.g. simple assert.Equal(t, err, test.expectedError). Consider the possible variants, find out what are the best practices.

When a user creates a new flat, checklist elements likely are the same or at least intersect with others already added. In such a case, it would be convenient to copy all the groups and group items from an existing flat.

So, at UI some suggestion is needed, and the corresponding endpoint should be provided by backend and used by frontend.

When a user wants to add groups to a new flat, they're likely the same as groups in any existing flat. Generally, some suggestion is needed to fulfill group list with some template.

1. Handler to get all flats that have a certain group (by group id), return flat models but not just ids
2. Amend AddGroupToFlat: add flat id parameter from which to copy; if nill -- don't copy

Resolves #21

For example, here should be a bad request, so db exceptions need to be handled

2024/01/17 20:19:59 /app/internal/repository/group.go:102 violates foreign key constraint
[108.438ms] [rows:0] INSERT INTO "flat_groups" ("flat_id","group_id") VALUES (0,1)
2024/01/17 20:19:59 error adding group to flat: violates foreign key constraint
reponse body: {"message":"Internal Server Error"}

It would be cool to provide users with predefined groups & items set.

So, it's required to come up with common groups/items, and add corresponding functionality to backend and frontend.

It would be easier to compare flats by having a summary for each, such as the count of items marked as ok, not ok, and other relevant categories.

In UI, embed clear and accessible summary numbers for each flat. Provide the corresponding endpoint at the backend and call it at the frontend.

In case when some entity doesn't have access to other, NoAccess error is produced. E.g.:

• user has no access to flat: {Msg: "access", Field: "userId,flatId"}
• flat doesn't contain group: {Msg: "access", Field: "flatId,groupId"}
  ...
• there is no item in particular flat's group: {Msg: "access", Field: "itemId"}

Consider more suitable error fields/messages.

Currently, a new auth token is being generated on each login. There is an issue when the user logs in on several devices simultaneously -- the second token will rewrite the first one and the user will be logged out at the 1st device.

Check the auth token existence first, then generate the new one if there is a null.

Here is a logging middleware, which produces verbose logs but not quite human-friendly. Consider some logging libs and technics to improve it.

DELETE /groups/:id doesn't delete the group completely but hides it. Such implementation allows to hide a group from user's search list, and to keep the former in users' flats.

Problems start when creating a new group or updating an existing group with the hidden group's name. In the first case, it's needed to unhide the group somehow. In the second one, to consider the appropriate implementation.

❗ Same for items

When authorization fails, looks like Access-Control-Allow-Origin header is not sent. As a result, the frontend gets a CORS policy violation error. Seems that CORS and Auth echo middleware don't get along. Perhaps, auth wipes out CORS headers.

Research and fix needed

For secure communication, HTTPS is a must-have.

Frontend is already hosted via HTTPS, so it's required to protect communication between backend and frontend.

Possible options: Yandex Cloud Serverless Containers, Google Cloud Run (Firebase)

The existing schema is outdated, update it

Add openapi schema to discuss with frontend

The current error handling in the application needs improvement, especially in providing clear and user-friendly error messages.

At the backend, refactoring error responses sent is needed, as well as debugging authentication error responses that don't send headers properly.

The frontend requires an implementation of a logic for displaying user-friendly error messages, as well as handling error responses.

For now, it was decided to simplify authentication and authorization and use Bearer instead of Google (or any other service) OAuth 2.0

So it's required to provide auth/register, auth/login, and auth/logout handlers

• Set default value properly: use constructor + SetDefaults
• Rename fields (ask frontend)