Improvement - Behavior - Color code for user should be based on user role

[franck-boullier]

Today in PR41 each user is displayed with a different color code. This works well and is useful

A interesting way to use color code would be to have the same color code for each user in the same role for the unit (ex: blue for all user with a property management role for the unit).

This is not key for the MVP but would be a nice additional feature as we move forward.

[kaihendry]

You could hash the role and use that as a colour? E.g. https://hendry.jsbin.com/yojoki/quiet

[nbiton]

Nicr idea, but I think the color needs to match with the general color scheme

[nbiton]

I used two colors that appear on Kiat's designs, and generated additional ones that match them using https://coolors.co

[kiatlim]

Just saw this thread and thought its interesting, for the color codes, actually i chose the colors quite randomly, so long its dark in shade and can fit white text. I suppose we can use the ones that match what we have and just assign it to different roles, since we only have a few roles now.

Good to park this as future enhancement. Is there a label for that?

[franck-boullier]

@kiat I just added the "enhancement" label

[franck-boullier]

In PR #112: the color code for the same user is different when:

• User is the same
• User is involved in the case in several capacity, example: user is the Reporter AND the Assignee. This is counter intuitive...

[mariorodriguespt]

I’m having an hard time understanding if I should “solve“ this issue.

After play around with the codebase, I found that the application heavily depends on Bugzilla and I really doubt this approach will be sustainable.

I added some cases, invited users, ( I mean tried because it is not working ), signup several times and the Mongodb is almost empty. I don’t have any information about roles in Mongo and this is only to get worse over time. I’m assuming that this application want to use Meteor’s real time capabilities for the chat BUT we need to store the case chat in Mongodb, not in Bugzilla's MariaDB. Otherwise I don’t see the point of Meteor being used here frankly.

Having in consideration the current functionalities implemented, would be very trivial to implement it without Bugzilla.

Maybe I’m missing something that prevents me from understanding this tight integration with Bugzilla. I would definitely love to get some insight on this.

[franck-boullier]

@mariorodriguespt Yes the overall app is very BZ dependant today for a number of things

That being say the source of truth for user role is in the MEFE and then passed down to BZ It is safe to query the mongodb to get the user role for the MEFE (MEteor Front End - I know I need to post our glossary in the documentation and will do)

This is the most sustainable and future proof approach

The BZ integration gives us a ton of built in functionalities: fine grain user permissions, security, searches, reports, history, and the list goes on

[franck-boullier]

Also the default environment has 0 case today and only a few users yes, we need to beef this up so that it's possible to play around with various scenario

There are a few issues in there which document that and we are working on that

[kaihendry]

@mariorodriguespt It would be better to open a new issue questioning the architecture, than pollute this issue with a discussion not really relevant to the task at hand, of making roles easier to identify by colour.

[mariorodriguespt]

@kaihendry Yep, I think it worth discussing the overall architecture of the app.

This issue requires me to write some hooks to populate MariaDB and MongoDB so that things stay in sync. I'l' take a deeper look at SQL database and I'll create a mapping for users in MongoDB.

[kaihendry]

@mariorodriguespt Sounds like your solution is seriously over engineered to me if you need to write "some hooks to populate MariaDB and MongoDB so that things stay in sync" to solve this issue.

In my mind the ultimate source of truth is the Bugzilla DB, but I am the Devops guy, so I what do I know? ;)

[franck-boullier]

@mariorodriguespt No need to do sync between mongo and BZ at this point: changes in a user role is beyond the scope of this issue but I like that you considered that!

@Kaihendry source of truth depends on what info your are looking for actually Some things are stores in the MEFE because the BZFE can't handle these and it makes more sense to have Mongo as the source of truth (ex: address for a unit)

[mariorodriguespt]

@kaihendry In a way you're right. In my view, making an internal REST call to bugzilla everytime you want to check the user role/anything else seems like an overkill to me. In meteor you've access to Meteor.user() to get the user document in Mongodb but if we need to make a REST call you don't collect the benefits of Meteor at all.

That chat interface works really great in real time in Meteor if you use MongoDB, you get this for free. If you use bugzilla, now we need to run a cron job every 5 seconds just to send the messages or something else.

Seems like that Meteor is more of a middleware here instead of an application server.

[franck-boullier]

The single source of truth for the role is meteor/lingo No need for a REST call to the BZ here just get this directly from mongo

[franck-boullier]

BTW most of your questions are valid and interesting and should help you understand the nitty gritty details of the choices we made (And we do NOT do cron jobs) but these are way beyond the scope of this issue

This is really a simple case which you can solve 100% by just slightly altering the Meteor code.

[mariorodriguespt]

Still on this, I'm taking a while since because I'm reading docs and understanding the schema. I found tables like ut_role_types, is ut_ a prefix for tables manually created that belong o Unee-T ?

[franck-boullier]

yes 'ut_...' tables are Unee-T specific table. This table stores the list of the roles we are using in Unee-T and a few additional info about these roles Wondering why you need to do anything in the BZ DB for that issue though 🤔, keep in mind that the source of truth for a role for a given user is in the MongoDB, and NOT in the BZ db

[mariorodriguespt]

I was able to find the roles in SQL database but not in Mongo.

I don't believe the source of truth is Mongo but Bugzilla itself. Lets take a look at the following code:

[`${collectionName}.insert`] (params, { newUserEmail, newUserIsOccupant }) {
    if (!Meteor.userId()) {
      throw new Meteor.Error('not-authorized')
    }
    if (Meteor.isServer) {
      const { bugzillaCreds: { token } } = Meteor.users.findOne(Meteor.userId())
      const { callAPI } = bugzillaApi

      let unitItem
      try {
        const requestUrl = `/rest/product?names=${encodeURIComponent(params.selectedUnit)}`
        const unitResult = callAPI('get', requestUrl, {token}, false, true)
        unitItem = unitResult.data.products[0]
      } catch (e) {
        console.error(e)
        throw new Meteor.Error('API error')
      }

      // Checking the role is valid
      const relevantRole = unitItem.components.find(({ name }) => name === params.assignedUnitRole)
      if (!relevantRole) {
        throw new Meteor.Error(
          `The designated role "${params.assignedUnitRole}" does not exist on the unit "${params.selectedUnit}"`
        )
      }

1. We use Bugzilla API to fetch the unit
2. We use Bugzilla to check if the role is valid

When I wrote about syncing about Bugzilla's SQL database with Mongo, I was referencing to this. Even if I store the role in MongoDb, if it's not present in Bugzilla it will fail. So either we sync or switch the approach.

[mariorodriguespt]

How can I get a user's role for a given unit/case in MongoDb?

[nbiton]

Hey @mariorodriguespt , you shouldn't worry about diving into such low-level concerns for this task. Generally, the user roles in the scope of a unit are resolved by querying both Bugzilla's API and the invitations collection in Mongo, and combining the results. If you're interested in seeing how that is done (although unnecessary for this task), you can review the getUnitUsers function. For this task, you should look into a data structure already present in the UI (but retrieved by the above), which is the unitUsers property of the Case component. You can see that it is being used to create caseUserTypes which matches the user by email to resolve its role, and also passed down to CaseDetails where it eventually trickles down to UsersSearchList which uses it to label the presented users with their corresponding role in the associated unit. You can pass unitUsers to CaseMessages as well, and then use it in all the related case components to determine to colors used for each user.

I'll be happy to explain anything else related to this I might have omitted.

[franck-boullier]

Tested and works in PR #215