You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Of each user who requests to be signed up his username and the status associated with his application are added to a table in the database.
Please note: the database is persistent, therefore it is not removed after a script interruption.
Whenever the user has decided to subscribe, the check must be asked before the process begins, in fact a first database query about the user's username needs to be made within the main in the function wrapper.
Database checking
If the username of the user isn't in the database:
the script adds an entry to the DB (username and status) and the signin up process is started (launching dispatcher.py).
If the username is in the DB:
If he already asked Resina to be signed up ...
... but the executive request has not been sent:
query.data = str(ISCRIZIONE),
the signing up process is started.
... but the executive request has not been accepted from the executive group:
signing up process is not started,
user is notified.
If the request as been accepted from the executive group ...
... but the subscription process has not been completed:
signing up process it resumed from the last point.
After each step the process status needs to be updated in the database.
Note: If it is not possible to create an account (Nuvola or Baserow) or insert the entry in the membership book, we have two choises:
undo previous actions and mark the user as unsubscribed;
terminate all the operations whatever are the outcomes and notify the new member about not completed ones.
Handlers structure
In the article describing the default behavior of an handler it is said that two users are handled separately in chronological order of request. Therefore, if a user A requests to be signed up, when a user B is already performing one of the subscription steps, it is necessary that the current function for user B is completed before the user A request is handled.
As the handlers have been structured, the termination of the function invoked by the handler via user B may cause changes on the pending request of user A, since currently handlers are added independently.
⬆️ Needs to be verified
The management method described above should permit simultaneous registration of multiple users.
The text was updated successfully, but these errors were encountered:
Persistent database has been integrated. Furthermore, Resina can now handle multiple users at the same time thanks to a temporary created dictionary with which the bot can process the requests.
Using database and ConversationHandlers
Fixing idea
Of each user who requests to be signed up his username and the status associated with his application are added to a table in the database.
Please note: the database is persistent, therefore it is not removed after a script interruption.
Whenever the user has decided to subscribe, the check must be asked before the process begins, in fact a first database query about the user's username needs to be made within the main in the function wrapper.
Database checking
If the username of the user isn't in the database:
If the username is in the DB:
After each step the process status needs to be updated in the database.
Note: If it is not possible to create an account (Nuvola or Baserow) or insert the entry in the membership book, we have two choises:
Handlers structure
In the article describing the default behavior of an handler it is said that two users are handled separately in chronological order of request. Therefore, if a user A requests to be signed up, when a user B is already performing one of the subscription steps, it is necessary that the current function for user B is completed before the user A request is handled.
As the handlers have been structured, the termination of the function invoked by the handler via user B may cause changes on the pending request of user A, since currently handlers are added independently.
⬆️ Needs to be verified
The management method described above should permit simultaneous registration of multiple users.
The text was updated successfully, but these errors were encountered: