fence_service

Description:

fence service

permissions #
explain standard user journey #

The boss (company/entreprise/franchise) signs up throught the webapp
Authentifies, and get a Bearer token with firmCreation permission
The boss creates a Firm
Authentifies again with refresh token to get lastest admin permissions on this firm
The boss creates a 2nd boutique
The boss setup/imports articles, contacts and past tickets if any
The boss creates users

explain chains #
A Chain is a group of boutiques
Boutiques in a chain share the same article catalog and contact directory
A boutique belongs to a single chain

| Chain1 | _______
| BTQ1 | | Chain2|
| Dev1 | | |
| BTQ2 | | BTQ4 |
| Dev2 | | Dev4 |
| BTQ3 | | BTQ5 |
| Dev3 | | Dev5 |
|________| |_______|
User 'Lili', being the boss, can access Chain1 and Chain2 and their boutiques
To create tickets in a boutique she can either :
- Log into a boutique's device (i.e. being physically in the boutique)
- Log in the web app and select the chain and the boutique
User 'Michael' is Chain1's manager
He has permissions over BTQ1, BTQ2 and BTQ3, but not in Boutique4 nor Boutique5
Like Lili he can create tickets by login to a boutique's device, e.g. go to boutique1 and use device1
Or using weebi_web
explain devices #
A device (e.g. android phone) is like a cash register
It needs to be assigned to a chain and a boutique
Why such constraints ?
First, manipulating the same device for different businesses is very error prone,
switching boutiques is also error prone
The device (weebi_app) keeps in local storage : articles, contacts and the boutique's tickets
login in and out of each chains would burn data uselessy redownloading the same things
What about the boutique constraint ?
1 device == 1 boutique limits edge use cases for the weebi_app
The PoS app is designed to be used in a single boutique,
Changing this behaviour would require rewriting logic around ticket creation
This constraint also brings more ticket traceability (1 ticket == 1 device)
If the manager / the boss need to create tickets from different boutiques, chains
They will be able to do it from the web_app, which is designed to handle multiple chains and boutiques
Timestamps ? #
DateTimes are used for flutter apps objects (article, boutique, contact, ticket)
Timestamps are not used on purpose for these objects :

on retrieval the UTC value is converted back to the timezone in effect in the session
Timestamp in dart != proto != mongo
DateTime iso String are easier to read

But Timestamps are used for server objects such as user, chain etc
Watch out the class used is not the one in mongo but in protobuf
import 'package:protos_weebi/protos_weebi_io.dart' show Timestamp
simply use extension .timestampProto ex : DateTime.now().timestampProto
Restrictions permissions = {'uniqueId' : 'pierrot', 'boutiqueId' : 1, 'permissions' : [] };
The upcoming use case is linking boutiques together in a Chain
With permissions set manually at first.
jwt refresh explained #
// client app
// if access token is expired
// use the refresh token on the route authentication/refresh
// and provide the refresh token (that was saved previously in secure_storage)
// server will reply with 1 access_token and 1 new refresh
// use the access_token to auth
// again save the refresh_token in secure_storage
ObjectId vs ids #

Since mongodb does not create _id for nested objects we still need to create ids manually
making the case for a simple handmade id, i.e. milliseconds since epoch saved as a string
Also I did not find a simple way to parse Mongo ObjectId using .mergeFromProto3Json()
Which incentivized me to use my own id based for objects such as firm and user

mongodb mongodart #
stange error message on update "getLastError"
getLastError command has been deprecated in MongoDB and is no longer supported. (as of MongoDB 4.4)
ignore