Add options to module-hide/module-forbid to explicitly hide/forbid modules based on user/group

[jdechard]

Hello,

As far as I understand, the current hide/forbid feature of Modules allows to:

• Hide/forbid a given module for all users (with soft and hard options)
• Prevent the hide/forbid mechanism for given UNIX user/group with the --not-user/--not-group options

Let's consider the following situation:

1. By default all users (user1, user2, ..., user1000) have visibility/access to all modules (module1, module2, ..., module999)
2. A new module (module1000) is added
3. I want to restrict visbility/access to the new module1000 for user1000 only, how can I do it neatly?

My first thougths:

• The module-hide module1000 command will hide module1000 for all users, it is not what we want.
• By using --not-user I will have a very long file containing:

module-hide --not-user user1 module1000
module-hide --not-user user2 module1000
...
module-hide --not-user user999 module1000

with maintainability issue: when creating a new user I will have to add it to this .modulerc file otherwise module1000 will be hidden to him or when restricting access to another module.

Is there a solution that I miss with the current implementation of module-hide/module-forbid ?

If not, it would be nice to have an option to explictely hide/forbid a module to a given user/group like module-hide --for-user user1000 module1000. It will allow to handle the situation where hidden/forbid modules are a corner-cases and exceptions to very specific users/groups instead to be based on mutual exclusion.

Thank you in advance for your advice and let me know if further explanations are needed,

Best regards,

[xdelaruelle]

Hello Jérémy,

For such use case, --user and --group options may be added to module-hide and module-forbid commands. It will also benefit to the module-tag command as the 3 commands share the same option handling code.

Would you like to craft a pull request for such feature? It should be quite easy as the code to add/change is located in a single procedure: parseApplicationCriteriaArgs

Best regards,
Xavier

[jdechard]

Hello Xavier,

Thanks for your quick reply and suggestion.

I made a first attempt in parseApplicationCriteraArgs (see the branch on my fork). Although I'm not satisfied by the variable flag to discriminate the use of --user/--group versus --not-user/--not-group, it seems to work on my testcase. Indeed after some research I didn't manage to find an unified boolean expression for apply and isnearly.

Do you see a better way to handle the new --user/--group option set ?

Regards,
Jérémy

[xdelaruelle]

Nice start!

I think there should be a way to avoid using a flag variable. If either user or group boolean is true and time does not apply (after or before), apply is true.

Could you create a pull request. It will be simpler to review the proposed code.

[xdelaruelle]

@jdechard I think apply and isnearly booleans may be updated this way (not tested):

# are criteria met                                                              
set apply [expr {($user || $group || (!$notuser && !$notgroup)) &&\
   ($isbefore || $isafter || (![info exists before] && ![info exists\
   after]))}]
                                                                                     
# is end limit near ?                                                           
set isnearly [expr {!$apply && ($user || $group || (!$notuser &&\
   !$notgroup)) && [info exists after] && !$isafter && [getState\
   clock_seconds] >= ($after - $nearsec)}]

I may include this work in the next release (v5.4) if it is completed at the end of this month.