Limit file size of a member to check in

[khoppe]

To avoid adding of files by mistake it would be good to have an admin setting to limit the file size for a member revision.

In the past in our company has added the logfile of long-run test. File Size:  13.5 GB  ...

Another reason why I postulate to bring this as a functionality to Integrity:

AFAIK with an early 10.x Release there has been added the possibility to define a Sandbox scope.

From my perspective this features basic idea is similar to what I'm asking for:

Allow to define a project's scope regarding :

• File Types (allow and/or deny definition)
• Maximum File Size
• (..)

[VolkerEckardt]

Hello Mr. Hoppe,

isn't this just a simple check.in trigger that validates the file size, and in case if the size is above a limit it will throw an exception?

Regards

[khoppe]

Maybe.

But is it necessary that every customer needs to develop it by their own?

From the answers you can see that there exist some interest into that idea.

@Harald Bock:

IT would be great to give a comment why you disagree with this idea.

Best regards

[Siddharth]

Klaus Hoppe‌ Thanks for submitting this idea. We're currently working on introducing new web UI for Integrity Lifecycle Manager - wherein Requirements Management enhancements is first priority, with Source improvements being next. It means this idea will be considered when we start working on Source improvement project.

[khoppe]

Please provide some more infos like Roadmap of new UI including Planned dates (or at least Releases).

It would be great to get an info, how long we have to wait until this idea will may be taken into any Backlog of working tasks.

Regards

[jhampson]

What trigger bean is available to query the size of the file being added/checked-in? ScriptCheckInArgumentsBean has a method to get the BufferedReader for the file but I cannot see anything similar for ScriptAddMemberArgumentsBean. Even with the BufferedReader I'm not sure how that could be used

[MichaelChatel]

FYI, I don't think you can do this via trigger/script coding yet - from my understanding the check-in pre trigger *does* have access to the check-in arguments via the ScriptCheckInArgumentsBean, which is passed the tempfile about to be checked in.

From the bean there’s a getTempFileReader() / releaseTempfileReader() pair through which the tempfile can be read.

But currently , there is no method to determine size (ex.  Something like a getTempFileSize()).  And I don't think the add-member pre-trigger has access to the tempfile now anyway. 

[jhampson]

From speaking to support we have managed to implement a check of the file size pre "add" and "check-in". I thought I would share this in case it is of use to anyone else. You can setup a client-side trigger (refer to the admin guide). Adding to the global policies in the admin console:

si.AddMembers.pre=add_pre
si.CheckInMembers.pre=add_pre
si.trigger.add_pre.command=wscript.exe "P:/integrity/FileSizeCheckinPre.vbs"

A non-zero return code form the script will veto the check-in or add. The script can be batch, VBScript etc. We chose a VBScript wrapper:

command = "powershell.exe -nologo -command P:/integrity/FileSizeCheckinPre.ps1"
set shell = CreateObject("WScript.Shell")
exitcode = shell.run(command,0,true)
WScript.Quit(exitcode)

That calls a PowerShell script. The PowerShell script checks the size of the file. If the file is too large then we check the groups the user is in. if the user is in the admin group then we allow the action, otherwise we return a non-zero value to veto the action:

# Filename: FileSizeCheckinPre

Add-Type -AssemblyName PresentationCore,PresentationFramework
$ButtonType = [System.Windows.MessageBoxButton]::Ok
$MessageIcon = [System.Windows.MessageBoxImage]::Error
$MessageBody = "You are not authorised to check-in the file(s) more than allocated quota of 100MB. Please contant your project super user."
$MessageTitle = "Authorization"

if ((Get-Item $Env:MKSSI_WORKINGFILE).length -ge 100Mb) {
        $cmd="aa users --hostname=$Env:MKSSI_HOST --port=$Env:MKSSI_PORT --groups $Env:MKSSI_USER"
        foreach ($mac in Invoke-Expression -Command:$cmd){
            If($mac.Trim() -eq "Project_Admin"){
            exit 0
            }
        }
        $Result = [System.Windows.MessageBox]::Show($MessageBody,$MessageTitle,$ButtonType,$MessageIcon)
        exit 1
}
exit 0
# end of script

[MSDV_Marcus]

I am prefering the idea of Mr. Hoppe, instead of implementing a client-side trigger. Maybe this idea could be enhanced by not uploading such files to the server, because of performance. See also CS83547.

Because a client-side means nevertheless additional maintenance work for example when you different locations overall over the world - shall they access a central server for such scripts do you provide different local server and so on.

And why is there already a text file based policy not a general or a binary one, too ? Are text files that large, that you have to have the policy ? No, but there are editors which can/could not handle such large files. This would mean, because no one tries to open binary files with an editor - there is no binary policy !!!