Feature request: subinstitutions/subdelegates

[DanielTosello]

Long story short: Some politicking has created LIEF funding conditions for us in which certain sections of our compute have approval oversight from specific departmental people, and they're under the naive impression they want institutional delegate powers but have also been clear they think they shouldn't be bombarded with spam, but ALSO don't want to have to wait to have requests manually routed. I guess we also would prefer not to have to take time to manually route them too.

The cleanest way i can see of building the functionality they want without breaking heaps of stuff is to add another layer to the delegation system.

grumble

Components required:

• ability to create a set of department-level sub-institutes which are full institute objects with a parent institute. Also, admin interfaces for creating & associating sub-institutions, etc.
• ability to have parent delegates grant sub-delegate capability over sub-institutes.
• additions to forms that will show a dropdown list of sub-institutions when a user is applying for access, etc.

Let me know what you think, @brianmay. We'll be building this, but i want your opinion on how it should fit into the existing architecture or whether there's a better approach to this.

[brianmay]

Not sure if I understand 100%, but makes me think of #222, which I just closed 6 days ago :-)

[brianmay]

Am having trouble understanding the subdelegates requirements.

[DanielTosello]

Eh i'm probably over-complicating it in my grumpy description... but it sure does seem like it'll fit well alongside #222... I'm proposing adding another level of institution, adding an optionally populated list to each... think of it as, say, department or faculty. Users indicate if they're from a specified list of departments when signing up. All these departments auth off the same provider, but have different institutional delegates. The parent institutional delegate entry is still populated as it currently is, and that delegate has authority to assign and remove delegates from departments associated with their institution. Trying to keep the functionality as generic as possible. --Daniel

…

On 3 May 2018 at 18:04, Brian May ***@***.***> wrote: Am having trouble understanding the subdelegates requirements. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#433 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHCX85_fIxgOre6J-r4GM3gpJ4uUoyzdks5turoMgaJpZM4TtbG7> .

[brianmay]

Storing a tree structure in SQL without having slow queries for deeply nested structures is a non-trivial operation, there are some Django libraries designed to try and help this. Common code picked one for Karaage 4, but it seems like it wasn't well maintained.

At the moment, we have a department field for users but it is a free form text field. Maybe if we changed this to port to a Department database object instead? UI might be interesting though, having institute and department both on the one page, with (currently) no JavaScript functionality.

[DanielTosello]

I intended only 2 layers to it, rather than endless nesting. I hear you with regards to db calls from forms, etc. Converting the department field to a DB object sounds promising.

…

--Daniel

On 22 May 2018 at 17:02, Brian May ***@***.***> wrote: Storing a tree structure in SQL without having slow queries for deeply nested structures is a non-trivial operation, there are some Django libraries designed to try and help this. Common code picked one for Karaage 4, but it seems like it wasn't well maintained. At the moment, we have a department field for users but it is a free form text field. Maybe if we changed this to port to a Department database object instead? UI might be interesting though, having institute and Department both on the one page, with (currently) no JavaScript functionality. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#433 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHCX8wfVqBYCUC1F5e0LxcE_zmnwudYBks5t07gPgaJpZM4TtbG7> .

[brianmay]

As this is two years old now (almost), just checking, is this still desirable?

[DanielTosello]

It's really a pretty low priority request... another instance of me trying to translate functions people imagined. It was almost entirely a response to external delegates not fulfilling responsibilities but wanting to retain special status. Functionally this is already handled by allowing multiple delegates for an institution.

…

On Fri, 27 Mar 2020 at 07:52, Brian May ***@***.***> wrote: As this is two years old now (almost), just checking, is this still desirable? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#433 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYJP42PQFYCOYW2WL4L6V3RJO6CTANCNFSM4E5VWG5Q> .