Groups of course units

[jose-carlos-sousa]

Currently, there are no course unit groups in TTS. This PR introduces the concept of course unit groups by adding two new tables:

1. course_group
2. course_unit_course_group

These tables establish a many-to-many relationship between course units and course groups, enabling more flexible course organization and management.

Scraping Process

1. Course Page
2. Course Plan Page

The course page has the course plan url and the course plan page has tables with the groups

[thePeras]

I think it not a very idea, in terms of scale, to hard coded the groups in the database and a more generic approach should be followed.

What is the different between "Competências Transversais" and "Optativas"? The name?

The groups feature are useful not just for "Competências Transversais/Optativas", but also "Ramos" which many masters have. Example

I know this makes the task so much difficult, but I wanted to you to remember how big the job you are dealing with, and how important it is for the expansion of the project to others courses and faculties.

[jose-carlos-sousa]

I think it not a very idea, in terms of scale, to hard coded the groups in the database and a more generic approach should be followed.

What is the different between "Competências Transversais" and "Optativas"? The name?

The groups feature are useful not just for "Competências Transversais/Optativas", but also "Ramos" which many masters have. Example

I know this makes the task so much difficult, but I wanted to you to remember how big the job you are dealing with, and how important it is for the expansion of the project to others courses and faculties.

My first idea to deal with this issue was to create 2 tables one for groups and another to map groups to course units allowing a many to many relationship which I think would be more generic and versatile. During the meetings I got the idea that the vast majority of groups were either competências transversais (where you can choose one) or optativas (where you can choose a certain number) and therefore I decided to go with the easier approach of just adding a group attribute to the course unit. But given that we want to expand to other courses where there will be many other groups (probably) like the one you refered , I believe an approach closer to my initial idea would be better.

[thePeras]

My first idea to deal with this issue was to create 2 tables one for groups and another to map groups to course units allowing a many to many relationship which I think would be more generic and versatile. During the meetings I got the idea that the vast majority of groups were either competências transversais (where you can choose one) or optativas (where you can choose a certain number) and therefore I decided to go with the easier approach of just adding a group attribute to the course unit. But given that we want to expand to other courses where there will be many other groups (probably) like the one you refered , I believe an approach closer to my initial idea would be better.

I like your initial approach. Besides looking an overkill solution for this first phase, it will help scale next

[tomaspalma]

I don't know if it makes sense to be a many to many relationship between a course unit and a group, but in terms of scalability as you pointed out it may make sense, so it's ok to do that.

A group is different from a branch. A group can be inside a branch, so they are not the same thing. Is your idea to include branches in the table that maps course units to groups?

By mixing groups and branches up in the same table won't we lose the possibility of having distinct behaviour in the future? (because we may want to display them differently in the frontend)

[thePeras]

A group is different from a branch. A group can be inside a branch, so they are not the same thing. Is your idea to include branches in the table that maps course units to groups?

By mixing groups and branches up in the same table won't we lose the possibility of having distinct behaviour in the future? (because we may want to display them differently in the frontend)

You are absolutely right. I didn't see the groups inside the branches, but they exist. So a branch is a whole other story we may be aware of.

I still think writing the name of the group directly to the database is not the best approach, and inclined to a many-to-many relationship. I don't know if we will get a surprise of finding another group type later.

[jose-carlos-sousa]

A group is different from a branch. A group can be inside a branch, so they are not the same thing. Is your idea to include branches in the table that maps course units to groups?
By mixing groups and branches up in the same table won't we lose the possibility of having distinct behaviour in the future? (because we may want to display them differently in the frontend)

You are absolutely right. I didn't see the groups inside the branches, but they exist. So a branch is a whole other story we may be aware of.

I still think writing the name of the group directly to the database is not the best approach, and inclined to a many-to-many relationship. I don't know if we will get a surprise of finding another group type later.

I looked into the different group names that the scrapper ran into and there are more than I had first realized some groups that have "Opção" in the name are actually optativas others have "Opcão" but are closer to transversal it is kinda hard to find a criteria that works for all.

When I first implemented that I looked mostly into the scenario of LEIC/MEIC. In addition there are things that look like groups but aren't like "Teses", "Workshops" etc and sometimes there is stuff like "Qualquer UC UPorto".

Imo the many-many approach would support all these cases even the "Qualquer UC" ones, the current one doesn't really seem feasible because the distinction between an optativa and a transversal from the name of a group is not clear.

An alternative would be just having an attribute isMandatory in course unit and don't make the distinction between Optativa and transversal but that approach would prevent us from distinguishing between groups on the frontend. some cases.

[jose-carlos-sousa]

Should groups with no course units be included? By this I mean groups like "Qualquer UC uporto"

[tomaspalma]

The goal is to allow the frontend to show course units by each group.

If there is a group without course units it wouldn't be shown in the frontend, so I don't think that is needed for the scrapper to include those groups

[jose-carlos-sousa]

There are some other weird cases for instance groups of type "Dissertação" are a bit strange sometimes they only have one course unit other course groups of type "Dissertação" might have 2 where each course unit is an "alternativa". I think I will keep every single group that has one or more course units including the case of "Dissertação" as each "alternativa" is actually a different course unit.