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
Related to #3 ("in milestones 3 / 4 we will use SRAM to edit groups"), but maybe that's not realistic for Custom Groups.
Adding remote users to custom groups is currently not supported of course -
Should this be managed in SRAM or do we need to do some GUI work here? If the latter, in which milestone will we put this, https://github.com/SURFnet/rd-sram-integration/milestone/3 maybe? Then we also have some better overview of the workflow and who switches when between RD GUI and SRAM GUI (presumably end-user only uses RD GUI and SRAM GUI is only used by site admins?)
The text was updated successfully, but these errors were encountered:
Let's discuss in today's standup whether we could also make SRAM leading for both group types. We will need some sort of AAI in the back to make sure all node have the same list of federated groups, otherwise #14 isn't going to work.
Maybe we can have a distinction between local custom shares and SRAM-federated custom shares?
Related to #3 ("in milestones 3 / 4 we will use SRAM to edit groups"), but maybe that's not realistic for Custom Groups.
Adding remote users to custom groups is currently not supported of course -
Should this be managed in SRAM or do we need to do some GUI work here? If the latter, in which milestone will we put this, https://github.com/SURFnet/rd-sram-integration/milestone/3 maybe? Then we also have some better overview of the workflow and who switches when between RD GUI and SRAM GUI (presumably end-user only uses RD GUI and SRAM GUI is only used by site admins?)
The text was updated successfully, but these errors were encountered: