Database about noodle HOT 16 CLOSED

Users probably need a (salted) password for login.

from noodle.

Should user roles be many to many?

from noodle.

Should user roles be many to many?

For our last project, we decided that each user can only have one role. So student, teacher, etc.

Users probably need a (salted) password for login.

Some library called NextAuth.js deals with that. It kinda creates a new table in the schema which you can then relate to a user. We don't do authentication manually. I'm not sure if we are still using this library though.

from noodle.

Should user roles be many to many?

For our last project, we decided that each user can only have one role. So student, teacher, etc.

Users probably need a (salted) password for login.

Some library called NextAuth.js deals with that. It kinda creates a new table in the schema which you can then relate to a user. We don't do authentication manually. I'm not sure if we are still using this library though.

Surely if there was an English module and a maths module then the teachers for both should only be able to edit their own module. Maybe using roles for this would be a smooth way to do it.

from noodle.

Surely if there was an English module and a maths module then the teachers for both should only be able to edit their own module. Maybe using roles for this would be a smooth way to do it.

Indeed, this is the reason why we have roles. It's kinda like a way for us to manage privileges. For modifying the module, it wouldn't exactly be great if the teacher assigned to that module; that's because a module can take place in multiple years and it will have different years, we decided to have like a module leader or head of module that would be able to modify the module. For example, a 2017 CS2800 would be separate from a 2018 CS2800, for this reason, they would have independent assignments, timetables, teachers and students. If they were not separate, a teacher from CS2800 (2017) would end up making that assignment for all of CS2800 like 2018, 2019, etc.

from noodle.

Surely if there was an English module and a maths module then the teachers for both should only be able to edit their own module. Maybe using roles for this would be a smooth way to do it.

Indeed, this is the reason why we have roles. It's kinda like a way for us to manage privileges. For modifying the module, it wouldn't exactly be great if the teacher assigned to that module; that's because a module can take place in multiple years and it will have different years, we decided to have like a module leader or head of module that would be able to modify the module. For example, a 2017 CS2800 would be separate from a 2018 CS2800, for this reason, they would have independent assignments, timetables, teachers and students. If they were not separate, a teacher from CS2800 (2017) would end up making that assignment for all of CS2800 like 2018, 2019, etc.

Aren't a few link tables missing for that? Module users and; then an owner field on module.

from noodle.

Making a table for the roles would be a great idea actually. This would also allow us to filter types of roles for a specific set of tables, for example, roles for users assigned to each modules (student, teacher and head), roles for users in an assignment (teacher and students). Is this what you were referring too?

from noodle.

Making a table for the roles would be a great idea actually. This would also allow us to filter types of roles for a specific set of tables, for example, roles for users assigned to each modules (student, teacher and head), roles for users in an assignment (teacher and students). Is this what you were referring too?

Similar typically I use bitflag based permissions however that sounds like it would work. Maybe each module user has a role?

from noodle.

Maybe each module user has a role?

Yeah, I agree. Making the role outside of the user table would be more efficient since a student in 1 module can potentially be something like a TA for another module. However, what would the functional dependency for this be?

module_ID, module_year, module_term, module_group, user_ID → role. Something like that?

from noodle.

Maybe each module user has a role?

Yeah, I agree. Making the role outside of the user table would be more efficient since a student in 1 module can potentially be something like a TA for another module. However, what would the functional dependency for this be?

module_ID, module_year, module_term, module_group, user_ID → role. Something like that?

That doesn't seem normalised maybe module users have a role id which comes from a role table for a module.

from noodle.

Yeah, it's not normalised. I want to know if the functional dependency is correct so that the normalisation is correct. If the FD is wrong, then the normalisation would not make sense with the real world. Do you agree with the FD? If you do, I guess I can normalise it by tomorrow or something unless someone else wants to do it.

from noodle.

@djpiper28 I just spoke to @ixahmedxi and he said that we will not have that many roles anyway and that it's not neccessary to have a many-to-many relationship. Basically, since there is no student in module that can be a TA in another module, there is no point.
I also wanted to see if adding a new table for roles would make sense; but because the relationship between a user and a role is now one-to-one, it can simply be merged with the users' table which is basically the current layout.
With this new information, it seems like the database does not require any further modifications.

from noodle.

In rhul a student in X can be a TA in Y. Take third years TAing 1st/2bd years.

from noodle.

In rhul a student in X can be a TA in Y. Take third years TAing 1st/2bd years.

Yep, this is what I was about to do but it seems like our app will be a lot simpler than that. As you can see, the new FDs for what you suggested are bellow and I was about to start working on those.

module_ID, module_year, module_term, module_group user_ID -> role

This FD shows that for each module that takes place in a specific term in a year, there can be a role that can be identified given a user in some group. For example, for CS2900 in 2018 term 2 group 1, a user can have a specific role such as student; that same user can also be a TA for CS2900 2021 term 1 group 2.

However, as mentioned before, this functionality doesn't seem to be planed to be implemented.

from noodle.

I think allowing for users to have multiple roles such as the example above is an important feature. Maybe adding to the module-users link table the role works.

from noodle.

I think allowing for users to have multiple roles such as the example above is an important feature. Maybe adding to the module-users link table the role works.

I also think it's an important feature but it seems like we can add this pretty easily without making major modifications. This is what it's been said

no let's make it incremental instead of having a database that saves empty values
i don't think we will
our project is for students only and providing them a way to manage their students
studies

from noodle.