Overhaul The User Management Dashboard

Projects ID Dashboard
,
1

I am setting this up so that all posts are in one thread.

@dmytro.trifonov, please keep all posts on this thread. I have invited all relevant people. I would like by Sunday – that you have listed your plan here.

2

Hello Robert, and devs!

GSoC is coming, and here is some my points about implementing OpenMRS ID - User Dashboard project:

  • User dashboard will be implemented as a separate module, it will be placed under ‘app/user-dashboard’ folder in the project;
  • On a client side we will use React Material-UI library, for making our front-end in material design style;
  • On a server side we have to implement REST API for getting list of users, spam filters, and other data, making actions (such as block spam users, fix user profiles which are not presented in LDAP or MongoDb)

Later I will add list of React components, and UI components structure.

Will wait for feedback from devs

Thanks, Dmytro.

1 Like
3

It might be worthwhile also to do server-side rendering, which is handy. So rather than doing this UI first then backend – work on both frontend and backend in tandem (if that makes sense). While we do not need to worry about SEO – we should do (and I’m strong on this). @michael, @ryan, @maany – do you have opinions? I think server-side rendering is a requirement, not a suggestion.

4

(I have no real idea about this project, so take my advice in that context…)

I would assume that the ID user dashboard needs be rendered in one way only.

I don’t see why you’d spend extra effort optimizing to shave milliseconds off the load time.

5

So, our decision will be the server-side rendering, right?

6

i think so – I disagree with @darius (respectfully of course).

Also, if you have time – I got some free yubikeys – which I would be glad to mail to both you and @plypy if you so choose…@plypy – would china allow them? it seems to be insanely simple to implement. We’d do it the way github did it, where people opt-in for 2FA. If you don’t – it’s not a huge deal – I just wanna play with them!

8

@dmytro.trifonov,

Here’s how this summer is going to work – it starts on Monday:

  • In addition to your weekly blog posts, I’d like you to participate in the daily IRC scrum meetings.
  • I expect (at least) weekly Pull requests – you won’t be directly committing to the repo – if you encounter an issue, notify me on telegram (I will look) there, everything MUST be public. If you go any longer than that without making a PR I will worry progress is not being made. Please make your PRs against the gsoc2016 branch.
  • Please post a revised timeline here BEFORE Monday, preferably post it to your blog as well.
  • On Friday of every week, let’s aim to post a progress report – let’s keep this on this topic.
  • Let’s also make tickets for each milestone in your revised timeline, you can go ahead and make those if you choose, but do so before Monday.

None of this is written in stone. Let’s have some fun! You should be able to just run mongodb and mailcatcher by doing docker-compose up -d mongodb mailcatcher – this will start the mongodb and mailcatcher containers, but not the web container, which the app runs in. OpenLDAP needs to be run separately – and via vagrant up – I assume you loaded the groups into mongodb – but if you did not run node build/store.js with the mongodb container running.

2 Likes
9

Thanks for your notes, Robert!

10

The example config has all the settings configured for you. So you’re good to go.

1 Like
11

Link to my blog, where I will publish project status updates asap: http://dmytro-trifonov.blogspot.com/

1 Like
12

Good post :slight_smile: – I still wanna see a timeline – we can revise it but I wanna see some idea of your milestones? What will your midterm milestone be? What will your final milestone be? This is how I will determine if I need to pass/fail you :wink: – I don’t want to fail you at all – but I need some metric. Please have this ready soonish. You didn’t do everything I asked you to do in preparation for the project ;)…

This MUST be done by tomorrow 23:59 UTC – just so we’re clear with expectations for the midterm and final evals – I need some metric. First however, create the tickets and then we’ll use those to set up what tickets need to be completed prior to the midterm/final evals. I don’t want to have to have to ask over and over again :slight_smile:

13

What do you mean under ‘timeline’ ? I have a timeline in my proposal, maybe you want more details?)

What can you recommend me regarding tickets strategy - are they must be detailed (one ticket for every small task), or ticket may include a lot of tasks (one ticket for multiple tasks, that makes one big feature)

14

I’d like to see what you plan to accomplish by the midterm evals and what you plan to accomplish as your final deliverable. There are plenty of nuances with this project. it’s entirely up to you. This should have already been done…

Ideally, I would like small tasks. This is handy for you to reference in your blog posts and for me to track your progress.

15

@dmytro.trifonov,

One other thing: go ahead and make a new repo – for the new user management dashboard. We’ll move it to the OpenMRS org after GSoC ends.

16

New repo for a user dashboard module, right? I believe, it will be separate from main application.

17

Yes, in this case, now that i think about it – just commit right-off and I will review it when you’re ready. Please comment the repo here please. I’ll likely look at it over the weekends.

18

Which repo name will be better: ‘openmrs-contrib-id-dashboard’ or ‘openmrs-contrib-id-user-dashboard’ ?

19

I prefer openmrs-contrib-id-user-management-dashboard – I know it’s long but it’s descriptive. Neither one of those is descriptive enough for my tastes.

1 Like
20

Thanks, Robert!

Some later I will post there my timeline, with issue list, and after you approve I will create them.

1 Like
21

Just go ahead and bootstrap – so long as I see some progress – I’m happy.