Feature #66948
closed
Make workspaces.previewLinkTTLHours setting part of the WS itself
Added by Patrick Gaumond over 9 years ago.
Updated over 4 years ago.
Description
Right now the preview links lifetime in WS are related to User TSconfig. In an environment with many WS, some may need different duration/TTL. Make it related to user makes no sense in such installation.
If someone needs TTL of 2 days, 7 days and 30 days with Preview links genrated by the same editor, how could this be done with conditions or anything at the moment? Creating "dummy users with different TTL" is not quite elegant...
3 potential solutions :
- A quick fix could be to add PAGE TSconfig support for workspaces.previewLinkTTLHours.
- Another way to solve the problem could be to let editors in BE to choose from a dropdown menu or enter a duration of the preview link then save it into sys_preview with that timestamp.
- An even more satisfactory solution would be to store the TTL value in the WS itself.
- Target version set to 8 LTS
- Status changed from New to Needs Feedback
Which setting takes precedence? I'd say
- options.workspaces.previewLinkTTLHours
- sys_workspace.preview_link_lifetime (would be a new field then)
- default (48 hours)
Which setting takes precedence? I'd say
- options.workspaces.previewLinkTTLHours
- sys_workspace.preview_link_lifetime (would be a new field then)
- default (48 hours)
Just to be sure, you mean :
If nothing is done default (48h) and then if there's NO value in User TSconfig (options.workspaces.previewLinkTTLHours) but one for the new sys_workspace.preview_link_lifetime value in the WS record itself then that's the one who would be used (my original suggestion).
Right ?
- Status changed from Needs Feedback to New
- Target version changed from 8 LTS to 9.0
- Target version deleted (
9.0)
- Status changed from New to Needs Feedback
Current implementation is a huge problem, as it is related to the CURRENT's userTS (the user who creates the link).
Making this completely part of the workspace record makes a lot of sense to me, effectively removing the UserTS option. What do you think?
Benni Mack wrote:
Current implementation is a huge problem, as it is related to the CURRENT's userTS (the user who creates the link).
Making this completely part of the workspace record makes a lot of sense to me, effectively removing the UserTS option. What do you think?
Still annoying 5 years later. Workspaces need more love and fixes.
I still thinks it should be a setting at WS level.
- Status changed from Needs Feedback to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by