[RFW0005] Minimal User-Management

[mikkokotila]

Table of Contents

• Housekeeping
• The Problem
• User Story
• Request Type A/B
• Owner
• Summary
• Is This Really Necessary?
• Motivation
• Named concepts
• Examples, Risks & Assumptions
• Success Metrics
• Conceptual Design
• Drawbacks
• Alternatives
• New Data
• Business Release Date

Housekeeping

NA

The Problem

In order for any basic online application to make sense, there first needs to be minimal user management.

User Story

With this, we will be able to create, update, and delete user accounts.

Request Type A/B

Type A: This request creates something entirely new.

Owner

mikkokotila

Summary

Here we will build a simple system for to do three things:

• Create new users
• Update current users
• Delete current users

Is This Really Necessary?

This is necessary. We currently don't have any way to manage users.

Motivation

In order for the concept "user" to make sense, a minimal user management functionality is required.

Named Concepts

NA

Examples, Risks & Assumptions

1. Explain concretely what will manifest as a result of this RFW.

There will be two views based on Table with Modal where the table itself has the data, and the modal is used for editing the data.

2. Explain how is it different from what is already manifesting i.e. what we already have?

We don't have anything to this extent.

3. Explain what users/brands will experience as a result of this RFW. How will they feel as a result of it? How will they benefit as a result of it?

Admins (both the maintainers of the system as well as admins of user organizations) will have the ability to create, update, and delete user accounts.

4. If applicable, provide sample messages for any new messages the system will display as a result of this RFW.

NA

5. Define what is out of scope in this request.

NA

6. What are the data protection, privacy, and security assumptions made for this request (for example, should this be GDPR, compliant, etc)

GDPR

7. Explain how this user story will be supported (i.e. customer support - if the user story fails technically, how will the user be supported).

There will be no support at this point.

8. Explain how this user story impacts revenue or billing (if applicable).

NA

9. State any additional risks identified as a result of this user story.

• Privacy issues (e.g. GDPR)
• Security issues

Success Metrics

We are able to create, update, and delete users.

Conceptual Design

There will be two views based on Table with Modal

The table will be the initial view in the URL path https://my.lopenling.org/user-management. For now, it does not need to be password protected.

There are several columns for each row:

• username
• first name
• last name
• email
• company
• edit (this is a functional column)

When clicking the icon in the edit column of the table, a model is displayed for editing the data. In that modal, in addition to the data fields, there is a button for deleting the user.

If a user is deleted, another prompt will be displayed which shows the email of the user and asks to type the email to confirm deletion.

All columns are sortable.

Moreover, there is a button "Create User" for creating new users. When creating new users, the same modal as for editing users is opened, but its heading will say "Create New User" instead of "Edit User".

Drawbacks

NA

Alternatives

NA

New Data

There will be user data. This has to be managed in a GDPR compliant way.

Business release date

This is a precursor to RFW0006.