Save sidebar preference when collapsing/expanding

[jackcmeyer]

🚀 Feature Proposal

When the sidebar collapses or expands, I would like the setting saved so that when I refresh the page or when I use a different device, that setting is saved.

Technical Notes

• Add a new database "user"
• Add new user preferences object for the user
• Add new redux action
• Save the user preferences when the user expands or collapses the side bar

[ghost]

I wonder if saving the preference would be enough per cookie, rather than per user?

[matteovivona]

Good question @kumikokashii. In the first case, the settings would be saved on the browser, in the other case the user could bring back his settings on another browser/PC too.

[ghost]

I came up with this use case. User was on Desktop and let's say had all of sidebar expanded. The same user goes to another hospital and uses Tablet to log in. Screen size is much smaller, and he/she may not want all sidebar expanded? Mobile has no sidebar.

[fox1t]

I think this issue has to be split in two:

1. user settings object inside user's record saved in db
2. sidebar preference: we have to save also the viewport of the preference so we can address what @kumikokashii said. I think we can let the user decide per three different views:
3. desktop
4. tablets
5. mobile (for this specific settings, mobile will not be selectable)

[matteovivona]

This feature seems to me more something for version 2.1. Am I wrong?

[ghost]

This feature seems to me more something for version 2.1. Am I wrong?

Agree ✋

[fox1t]

No, you are not. We will have many of these, let's call them, "settings". However we have to finalise the document that explains the user story, before the release of 2.0.

[elveskevtar]

Hey all! I see that you have decided to save this for a later milestone. I was thinking about taking a crack at it over the next two weeks and was wondering if that would be advisable by the team?

If so, the document that @fox1t mentions would be useful to see.

[elveskevtar]

Just some clarification on the tasks involved:

1. There does not seem to currently be any implementation of "users". There are language settings which are powered by i18next from my understanding and that seems to be browser based.
2. This task would mean adding users schema for the db located in the core/server repos?
3. Does this task involve creating a sign on system for the user, and if so, what would that look like? Google OAuth? Register with HospitalRun specific credentials? Provisioned to users by the HospitalRun team?

I'll get started testing the persistence of this setting by mocking the source of truth (where the setting will be saved per user) for now.

[elveskevtar]

So after some more investigating, I see that the demo on the HospitalRun website actually has an authentication and user system. Is this part of the 1.x releases and just has not been updated for the 2.0 release yet?

[fox1t]

Hi @elveskevtar,

1. We are in the process of defining the user entity: our users are CouchDB users that handles both authentication and data. May I ask you if you have any experience with CouchDB?
2. Yes, we need to add database user schema representation to core repo, however it depends on point 1
3. Yes: first we are going to define our registration and login process. We need to support our own login (internal) and also external one: the internal is handled by couchdb itself and this is the first we are going to develop. After the internal is working like expected we are going to add external ones: we going to develop a custom server side plugin that reaches external systems, authenticate the user and adds the JWT/token to couchdb to authenticate the user.

[fox1t]

So after some more investigating, I see that the demo on the HospitalRun website actually has an authentication and user system. Is this part of the 1.x releases and just has not been updated for the 2.0 release yet?

The 1.0.0-beta has several issues about how it handled the authentication. We are building it ground up in order to support what i mentioned in my last reply here.

[elveskevtar]

Thank you for the quick update! I don't have experience with CouchDB but I do have experience with NoSQL databases. I took a look at the json models to define the schema for it in core and it looks pretty intuitive.

As for authentication, that makes sense. Will users need to be connected to the internet to authenticate at first or is that the point of the external login? I have significant experience in making auth systems but that task is probably a little beyond me as a first time contributor.

Regardless, where would you recommend that I start? I think that I could get the persistence working while the user schema is fleshed out.

[ArtemGoldsmith]

Hi guys. Any update on this issue can I take it?

[avigpt]

Hi @blestab @fox1t @tehkapa @jackcmeyer @morrme, could I please take this on?

[morrme]

@aguptamusic Sure !

[morrme]

@ArtemGoldsmith sorry that we missed your message!

[avigpt]

Update: I'm holding off on this issue because @jackcmeyer says:
"The core team is deciding to move away from CouchDB/PouchDB in favor of some more modern offline-first practices, such as RxDB + GraphQL sync. Since this migration will be a large effort, we simply removed the login stuff along with removing the code that made syncing happen. It appears that we have left behind some of these artifacts."