Closed jdechard closed 7 months ago
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
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
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.
@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.
Hello,
As far as I understand, the current hide/forbid feature of Modules allows to:
soft
andhard
options)--not-user
/--not-group
optionsLet's consider the following situation:
user1
,user2
, ...,user1000
) have visibility/access to all modules (module1
,module2
, ...,module999
)module1000
) is addedmodule1000
foruser1000
only, how can I do it neatly?My first thougths:
module-hide module1000
command will hidemodule1000
for all users, it is not what we want.--not-user
I will have a very long file containing: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,