Implement endpoint to store the builder onboarding seen status
See original GitHub issueFor the new builder onboarding (see https://github.com/CartoDB/cartodb/issues/8887) we need a new endpoint to store the seen status of the screen. This way, if the user checks the Never show me this message
option we’ll set certain flag to true in the user model, and we won’t disturb he or her again.
Issue Analytics
- State:
- Created 7 years ago
- Comments:11 (11 by maintainers)
Top Results From Across the Web
Onboard a REST API without code changes required
For a complete list of methods to onboard a REST service natively to the API Mediation Layer, see the Onboarding Overview.
Read more >Microsoft Defender for Endpoints Onboarding Requirements ...
The script can be obtained from the MDE Security Center in the Onboarding tab. This strategy is recommended only in very small environments...
Read more >Building a Secure Onboarding App with Box Platform
To implement this workflow, we will build a system with four parts: Mobile App: This is where the user will submit a new...
Read more >Onboarding | Zoho People
To view reports on employees, go to Reports, and then, Employee. Under reports, you will be able to see the status of the...
Read more >CRM just for Customer Onboarding| Bigin Templates
Bigin for Customer Onboarding allows you to stay on top of all your customers, their needs and how far along they are from...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Merged!
You should be getting the notifications in a
builderNotifications
variable. The API to update them is:Let’s try to agree on the format of the data that’s stored inside. Although the backend won’t be doing anything with it now, it would be good to have an extensible an easily parseable format in case we need to start doing so in the future (thinking of statistics gathering). I propose something like this, but you know the needs better than anyone:
We have a categorization to easily separate onboarding from analyses, and inside each key we store if we want to show the message or not. It is inside a dictionary to allow expansion, which I think could be useful (but maybe I’m overengineering this).
👍