You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
id actually represents the filterId in shifts.json, again, why not use id from shifts.json?
The name should be the full name of the subject and there should be a second short_name parameter for the short name itself. shifts.json should not contain the name of the subject, the code should instead lookup the name of each subject in the filters.json file, using id as a foreign key.
Meaning: an event with no subjectId field would automatically be interpreted as a regular event and be shown to everyone. By default these events would all have the CeSIUM signature color, since it is also the primary color of Calendarium.
For an event associated with a subject, but made by CeSIUM:
{
"subjectId": <LI1-subject-id>,"title": "Showoff LI1",
"location": "CP2 - B1",
"link": "",
"from": "2024-11-10 09:00",
"to": "2024-11-10 11:00",
"color": "#ed7950"// a color can optionally be enforced to override the default color chosen by the system or the user.
}
This event would only be shown to students that have the LI1 filter enabled.
For an event associated with a year:
{
"year": 4,
"title": "Apresentação Perfis Mestrado""location": "...",
"link": "...",
"from": "...",
"to": "...",
"color": "..."// optional: by default it will be the primary color (CeSIUM orange)
}
This event would be shown to any student that has at least one subject from year 4 selected. This can simply be checked by crossing the information from the subjectIds the user has selected with their year value, if any year value from the list of subjects matches the year value from the event, you show it.
For easier management of years and semesters:
{
"1": {
"1": ["1234", "1234", "1234"] // list of subjectIds from 1st year 1st semester"2": ["1234", "1234", "1234"] // list of subjectIds from 1st year 2nd semester
}
},
"2": {
(...)
},
(...)}
The text was updated successfully, but these errors were encountered:
diogogmatos
changed the title
refactor: shifts/filters data structures
refactor: shifts/filters/events data structures
Nov 12, 2024
Would be good paired with #258
Currently a single shift has the following information:
"title": "Inteligência Artificial"
is repeated for every shift from this subject.id
is not used anywhere in the project, onlyfilterId
is used. Why not useid
instead offilterId
?.theoretical
isn't used anywhere.Meanwhile, this is the information for this subject in
filters.json
:id
actually represents thefilterId
inshifts.json
, again, why not useid
fromshifts.json
?name
should be the full name of the subject and there should be a secondshort_name
parameter for the short name itself.shifts.json
should not contain the name of the subject, the code should instead lookup the name of each subject in thefilters.json
file, usingid
as a foreign key.This would be a cleaner alternative to both:
And for event information:
For an event not associated with a subject (ex: CeSIUM):
Meaning: an event with no
subjectId
field would automatically be interpreted as a regular event and be shown to everyone. By default these events would all have the CeSIUM signature color, since it is also the primary color of Calendarium.For an event associated with a subject, but made by CeSIUM:
This event would only be shown to students that have the LI1 filter enabled.
For an event associated with a year:
This event would be shown to any student that has at least one subject from year 4 selected. This can simply be checked by crossing the information from the subjectIds the user has selected with their
year
value, if anyyear
value from the list of subjects matches theyear
value from the event, you show it.For easier management of years and semesters:
The text was updated successfully, but these errors were encountered: