feature(website): allow users to specify their employers (corporate social responsibility)

[anthonyray]

This P.R is part of the ongoing work on the Corporate Social Responsibility project (CSR).

The first step is to start collecting company names by allowing users to fill a form with their current employers.

Summary of introduced changes

1. This P.R introduces a new collection to the database : employers
2. There's a new subsection in the /me section : work-info where a user can specify their employers and update their employment situation

1. A new employers collection

• The isCurrent field is a field to differentiate between companies a specific user currently work for and companies they used to work for.
• Firestore rules were added so that users can only see the company their current and past companies, but only theirs.
• The seed has been updated

2. The new work-info page

Follows the wireframe discussed with @ssandino

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
public	⬜️ Ignored (Inspect)	Visit Preview		Mar 14, 2024 10:39am

[github-actions]

Visit the preview URL for this PR (updated for commit 9a0ce92):

https://si-admin-staging--pr700-corporate-social-res-kolenjti.web.app

_{(expires Thu, 21 Mar 2024 10:43:37 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: b7b0969384059dce6ea8fad1ee1d1737e54e6676}

[ssandino]

It runs smoothly on my local – great job @anthonyray!

I've noticed something about how employers are linked to users. Currently, the user ID is stored directly in the Firebase (fb) collection employers. This differs from our approach how we handle a very similar case: recipients and the NGO that recommended them, which are saved in the collection organisations. In both cases, the data relationships are quite similar. Contributors, categorized as users, can be associated with multiple employers. This is akin to recipients being linked to multiple organisations that have recommended them. Conversely, organisations can recommend multiple recipients, just as employers can have multiple employees. For the recipients we solved it with references (see firebase doc) saved directly with the recipient collection (data field organisation).

Then there is the question of how to proceed and evolve from the prototype to the next version. You might already have a plan; otherwise, some things that come to mind include:

• Showing the recipient collection alphabetically ordered on the webpage .../csr. Can be really just the names for now.
• Showing the list in the admin tool as own tile and list (like we show the NGO in a list). This will allow us to handle the data directly in the admin tool and to add also manually new employers in the future.
• Using the newly populated fb collection employers as a data source for the amended form field to enable autocomplete. If there is no existing match, the entered value should be saved as a new entry in the employers collection. However, a quick research shows there seems no out of the box solution from the frameworks we use shadcn or tailwindcss.

[anthonyray]

For the recipients we solved it with references (see firebase doc) saved directly with the recipient collection (data field organisation).

I will change the way I store userIds to use firebase references.
This P.R is just a chunk of the work needed to complete the Corporate Social Responsibility (CSR) project, let's discuss the next steps :

* Showing the list in the [admin tool](http://localhost:3000/) as own tile and list (like we show the NGO in a [list](http://localhost:3000/c/organisations)). This will allow us to handle the data directly in the admin tool and to add also manually new employers in the future.

I consider this to be the next logical step. I would like to provide a visual interface allowing to check newly entered employer values (and possibly correcting them).
This tool would ensure that the dataset we build on companies is clean.

Showing the employers collection alphabetically ordered on the webpage .../csr. Can be really just the names for now.

This would then be the next step, once we gather enough data on employers.

* Using the newly populated fb collection `employers` as a data source for the amended form field to enable autocomplete. If there is no existing match, the entered value should be saved as a new entry in the employers collection. However, a quick research shows there seems no out of the box solution from the frameworks we use [shadcn](https://ui.shadcn.com/docs/components/combobox) or [tailwindcss](https://tailwindcss.com).

Also, this could be implemented in parallel.

[ssandino]

Sounds like a plan!

[ssandino]

as discussed yesterday with @mkue @andrashee : this PR from @anthonyray would be good to be reviewed.

Long-term vision: Understanding where some of our contributors work allows us to more effectively highlight these companies and explore potential collaborations. Additionally, there are companies that have supported us through donations (e.g., GitHub, DEZA) or by providing software for free (e.g., Webstorm), which should be acknowledged appropriately – and the list of companies can be extended with the sponsors. While creating individual pages for each company is not the objective of this PR, it is part of our long-term vision. This PR lays the groundwork for eventually developing company-specific pages.

A prime example is Stripe, which excellently showcases companies that donate 1% to climate initiatives through their program. See here for the page of the Swiss company Sparkable.
Good example: Who does that really well is for example Stripe who makes a page for every company who donates 1% to climate with their program. See here for the swiss company Sparkable.

[mkue]

fyi @anthonyray: I try to find time to look at this in the upcoming days.

[mkue]

The UI part looks good to me. I would maybe even move it to the "Personal Info" section, I think it would fit well there. What do you think @ssandino?

The data modeling might not be perfectly suited for what we want to achieve. I think we should link from the user to an entry in the employer collection, i.e. have a field employer_path: DocumentReference on the User interface, and not vice versa. As far as I understand, we would like to be able to show that multiple contributors work for the same company in the future.

Do I understand that correctly, @ssandino and @anthonyray?

[ssandino]

we would like to be able to show that multiple contributors work for the same company in the future.

Yes

[anthonyray]

The data modeling might not be perfectly suited for what we want to achieve. I think we should link from the user to an entry in the employer collection, i.e. have a field employer_path: DocumentReference on the User interface, and not vice versa. As far as I understand, we would like to be able to show that multiple contributors work for the same company in the future.

Yes, this is correct. However, I feel like the most common operation we are going to perform is to compile statistics on employers.

Let's take an example and suppose I want to get the list of employers that were added this month.

Following your suggested database structure, I first have list each user, use their employer_path field to perform one query per employer in the Employer collection, then filter the results based on the last_updated_date field of the employer.

I feel like that with the current structure, the main operations which are basically compiliing statistics on employers, require less database queries.
In addition to that, this structure allows to have a one to many relationship between the user and their employers.

[ssandino]

Great work @anthonyray. I briefly tested the input mask in the dashboard along with its main functions (add, archive, delete), and everything works as expected:

[ssandino]

I feel like that with the current structure, the main operations which are basically compiling statistics on employers, require less database queries.

The discussion about the DB structure is something for you, @mkue and @anthonyray, to consider. No opinion on this. One thought: As we plan to publish the list of employers that have contributors on the website .../csr (refer to the discussion above), which relies on the employers collection, it might necessitate making the collection publicly accessible, right? If that's the case, then all user-ids stored alongside the employers would be openly accessible. Is this safe? Maybe there are ways to prevent this or it's not an issue. But at least it's discussed ;-)

[anthonyray]

The high-level approach I envisionned about the data displayed on the csr page is the following:

• Collect user's employment history in the employers collection (which will remain private)
• On a periodic basis, we compile a dataset of employers (merging companies that seem similar), and associated stats (TBD) in an offline manner.
• This dataset is public, and is used to display data on the csr page

[mkue]

ok, that works too! but do we need a separate main collection then? i think it would be cleaner and easier to create a subcollection in the user document. those subcollections can then easily be queried with a collection group.

we could then have a public collection with employers, and build a process that links the data from the private subcollection to a public collection.

something like this:

users collection (private):

doc1: {
    employers: [{
        employer_name: "Adidas France",
        is_current: true,
        employer_path: "employers/doc1" // set by linking process
    }]
},

doc2: {
    employers: [{
        employer_name: "Adidas Switzerland",
        is_current: true,
        employer_path: "employers/doc1" // set by linking process
    }]
},

employers collection (public):

doc1: {
    name: "Adidas"
    contributors_count: 2 // set by process that links from users collection
}

does that make sense?

[anthonyray]

Much better ! Thanks for your insights! Working on this!

[anthonyray]

• Changed Database structure to add an employers subcollection to the users collection
• Updated security rules
• Updated database seed

[mkue]

This looks great now! I added one comment, but then this can be merged!

Thanks for doing this @anthonyray!