[RFC00010] Minimal Dictionary Management

[lobsam]

Table of Contents

• Housekeeping
• Named Concepts
• Summary
• Reference-Level Explanation
• Alternatives
• Drawbacks
• Useful References
• Unresolved questions
• Parts of the system affected
• Future possibilities
• Infrastructure
• Version History
• Recordings
• Work Phases
  • Documentation
  • Implementation
  • Deployment
  • Testing

Housekeeping

This [RFC00010] is related to RFW00010 and is request Type-A

Named Concepts

Type-A : Types of RFWs which re-arranges or extends something that is already built.

Hasura: Hasura is an open-source engine that allows you to instantly access and manipulate your data over the GraphQL API. It provides real-time GraphQL APIs on new or existing databases, which means you can quickly build applications without worrying about designing and managing complex backend infrastructure.

Vue3: Frontend Framework which allows easy and quick building of web apps.

Summary

User can able to create, update and delete Dictionary that is associated with their account.

Reference level explanation

Dictionary Management involves storing of dictionary data in posgresql database and it can be accessed using GraphQL API. GraphQL API should be able to view, create, delete, update dictionary.

Dictionary table has the following fields:

• id(primary key)
• name
• organization_id
• access_mode(public or custom)
• source
• target

Frontend and User interface

User can able to create Dictionary that is associated with their account. This can be done by going to my.lopenling.org and clicking the user's account avatar in the right upper corner of the viewport. From here the user has the option to select Glossary which takes them to the administrative view for managing glossaries. The administrative view for glossaries involves two things:

• Being able to add and remove dictionaries

  • This has two parts. First, there is the ability to add and remove dictionaries that are native Lopenling dictionaries. Second, there is the ability to add and remove custom dictionaries. In terms of native dictionaries, between zero and all available can be added. In terms of custom dictionaries, up to three can be added (i.e. if the user at any time tries to add more than three, it will not be allowed). Moreover, custom dictionaries can not exceed the length of 100k entries. Native dictionaries can have any number of entries.

• Being able to manage read rights for dictionaries

  • All dictionaries, both native and custom, can be subjected to read rights. By default, all added dictionaries are visible to all users in the organization. Any dictionary, native or custom, can be restricted to be visible only to selected users.

OPTIONS TO CREATE DICTIONARY BY USERS: There are three options to upload/create dictionary and all the above dictionary field are must requied:

• create dictionary that has no content.
• create/upload dictionary using API : here backend api handles the insertion of content
• upload dictionary using file uploader : here the format of dictionary need to be .csv

Database Setup

Dictionary management use Hasura to store dictionary data. Dictionary table has the following fields:

• id(primary key)
• name
• organization_id
• access_mode(public or custom)
• source
• target

Authentication

N/A

Alternatives

N/A

Drawbacks

N/A

Useful References

Hasura Vue3

Unresolved Questions

NA

Parts of the system affected

• Which parts of the current system affacted by this request?
  • Hasura database will be change as dictionary table is included.
• What other requests are related with this request?
  • RFW00010
• Does this request depend on fullfillment of any other request?
  • This request depends on fullfillment of any other request RFC0008

    Future possibilities

Infrastructure

• Dictionary management uses all the Infrastructures provided in RFC0008

Version History

History of changes made to this RFC NA

Recordings

List of audio recording of related discussion. NA

Work Phases

Implementation

Non coding Preparation :

• [x] Planning

Implementation :

• [x] Create a Dictionary Table in Hasura
• [x] Assign access permissions in Hasura for dictionary Table
• [x] Able to create Dictionary without content
• [x] Able to create/upload dictionary using API

Testing

• [x] Unit testing

[mikkokotila]

@lobsam can you explain why we have to create the following:

• Able to create Dictionary without content
• Able to create/upload dictionary using API
• Able to upload dictionary using file uploader

After all, we already have a working dictionary management backend. Why must we deviate from that, and not simply use the functionality we already have to meet these objectives?