On Admin side it is possible to limit the number of sessions user to avoid an overload done by user which are using very often
scripted access or Web Access or Web Services.
On the other hand one user could create dozens of operations.
Under unfavorable circumstances it could lead to the situation that one user could cover lot's of operations (==> DB Handles).
- Bad configured Jenkins
- Synchronization of a rarely used project with great file sizes from an offshore location
- Temporarily bad network response time
For such cases it would be good to limit the number of allowed concurrent operations per user.
I strongly agrees with the point "great file sizes from an offshore location". When an resync is done for the huge file, the whole bandwidth gets blocked and this results in over utilization of WAN. If PTC provides some configurations to limit the size of files checked it, this could be avoided.
For RM documents they provided configuration to limit the attachment size, but I dono why they not providing the similar concept in Source
Again with respect to Jenkins, it has been poorly configured and I feel the CLI commands is more flexible than the Jenkins-PTC plugin. The reason for my commands about Jenkins is the API always connects directly to server and not via proxy. This affects the bandwidth.
This feature will helpful mainly for organization who works globally.
In past I've thought the same regarding file size.
I've added as additional Idea: Limit file size of a member to check in
Thanks Sathish Kumar Kamaraj & Klaus Hoppe for your comments. We believe this would be a good value add for customers and hence I'm marking it For Future Consideration.
Once again the question: Could you pleaese explain what "For Future Consideration" means on the roadmap of PTC?
At which date will "Future Consideration" start, and at which date can be expected any hint if and when it might be realized?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.