Fix and improve user, group, role and provider handling

Description

This is an umbrella issue for a set of related fixes to user, group, role and provider handling.

Some slides which describe this work presented at the Opencast Valencia 2017 Conference:

https://www.slideshare.net/smarquard/opencast-valencia-2017-users-groups-roles-acls-and-providers

Activity

Show:
Sven Stauber
January 27, 2017, 11:57 PM

Makes sense. Probably haven't thought about this since in our setup, users are not created manually and we therefore only use the group dialog to add users to groups.
We have also missed a reasonable way to find out what groups a user belongs to.

Thanks for investing time in moving Opencast forwards. We are looking forward to your contribution!

Best,
Sven


You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@opencast.org.

Rubén Pérez
January 28, 2017, 12:44 AM

Hi,

I'm very sorry, Stephen, but I did not really understand your answer.
Could you please ellaborate? Thanks for your patience!


You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@opencast.org.

Rubén Pérez
January 28, 2017, 1:21 AM

Hello,

You have yourself explained to me (perhaps in the comments of the JIRA
ticket) that every user belonging to group X has automatically the role
ROLE_GROUP_X assigned. That functionality is already there. Then we
modify the Java code parts where the group_member table is looked up and
instead check for the existence of the ROLE_GROUP_X instead. The only
"data migration" necessary there is to delete the table.

On the other hand, the comment saying "no benefit for users at all" with
a derogatory meaning is completely out of place. If we only focused on
changes that provided immediate value for users, then we would have
terrible, unmantainable piece of sh... oftware. The changes that do not
affect the user experience directly (say, for instance, migrating to
Karaf), always end up affecting the user experience sooner or later.
Better design should be a goal on its own, because a good design means
cleaner code, which means code more readable, which means easier
maintenance and also means faster refactors and better testability,
which mean shorter release cycles, which mean better overall quality,
which means both developers and users are happy.
A user won't see that each mediapackage has its own copy of the series
information or is not aware of the ACL mess that Osnabrück is currently
trying to fix. That does not make contributions to fix those problems
less valuable than changing two UI dialogs to improve the user experience.


Rubén Pérez Vázquez

Universität zu Köln
/Regionales Rechenzentrum (RRZK)/
Weyertal 121, Raum 4.05
D-50931 Köln
✆: +49-221-470-89603


You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@opencast.org.

Sven Stauber
January 28, 2017, 2:29 AM

Hi Ruben,

As far as I know, the group role is dynamically assigned by the GroupProvider (or whatever name it has). If you delete the mh_group_member table, group member ship information will be lost. Also, the change should (hopefully) take into account the multi-tenancy capabilities of Opencast.

Note that this would also imply an interface change: The current interfaces (both REST API and External API) allow it to put users that don't yet exist in Opencast into existing Opencast groups.
In our case, changing this would break ILIAS, Moodle and OLAT. It is true that this is one of the things that we will need to improve in the future, but at the time we did it, we simply had no feasible alternatives due to non-technical constraints.

Anyway, I very much hope that the community has other priorities than to break our setup.

But maybe we would then have users... just kidding

I do agree with you that maintainability is important. What surprises me, however, is that developers sometimes tend to focus on actually working code while there is quite a large number bugs, usability issues, graphical design flaws, missing functionality, etc.

Best,
Sven


You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@opencast.org.

Rubén Pérez
January 28, 2017, 4:18 AM

Hi Sven,

The solution I proposed works inherently with the multitenancy
capabilities, because the roles exist within an organization (you need
to provide an organization in order to create a new role --a new Role
object, that is--), so a ROLE_GROUP_XXX points always to the Group XXX
of the Organization YYY, which is a property of the role itself
(although not explicitly indicated in its name).

But of course the main goal I advocate for here is consistency. Using
the role and the role only seems like the simpler solution that covers
all the problems /that I can think of/. Obviously, if there are other
concerns that cannot be solved without a database table, then we have at
least to fix it and make operable in a multi-tenant setup. As Einstein
said, everything should be made as simple as possible, but not simpler.
I can understand that this could be necessary for a certain institution
scenario and as a "quick and dirty" hack where the administrators are
fully aware that this is a bad design but it solves other problems that
are more urgent to them. But it blows my mind that that "hack" made it
into production code. Perhaps it has served its purpose, but with all
due respect, I think this should have never made it into the official repo.
That fact that we have a problem with more and more constraints just
makes it more challenging (and rewarding) to solve
Fully agree. I guess developers and end-users have completely different
perspectives and the difficult part of managing a project such as this
is finding a good balance between the both "worlds". In my role as a
developer, though, I strongly believe that you should not start painting
your house's walls without even have set a firm foundation. An unstable
or poorly designed backend influences the whole program all the way to
the GUI. For instance, if the new admin UI came as a response of the
multiple flaws that were (and still are) in Opencast, but the developers
tried to solve everything in the frontend without really addressing the
backend problems. That's like finding a hole in the floor and hiding it
under a rug. Don't get me wrong, this is not about the rug (the rug is
fine), but the hole is still there, you floor is still flawed and it
won't fix itself, and the more you wait to address the problem, the
messier it gets.

Anyway, I digress. This is about Capetown's upcoming contribution. Feel
free to answer me in private or perhaps we could make a separate thread
if you would like to keep the conversation.

Best regards and /schönes Wochenende/


Rubén Pérez Vázquez

Universität zu Köln
/Regionales Rechenzentrum (RRZK)/
Weyertal 121, Raum 4.05
D-50931 Köln
✆: +49-221-470-89603


You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@opencast.org.

Fixed and reviewed

Assignee

Stephen Marquard

Reporter

Stephen Marquard

Tags (folksonomy)

None

Components

Fix versions

Affects versions

Priority

Major