mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-07-16 05:33:49 +03:00
Schedule account expiration #3851
Closed
opened 2026-02-05 07:39:53 +03:00 by OVERLORD
·
3 comments
No Branch/Tag Specified
development
l10n_development
release
snyk-action
ci_and_static
mfa_key
phpstan_june26
MilnerMart/development
GamerClassN7/impersonations-for-admin
Zhey-on/feature/csp-image-css-controls-6033
tortillas5/development
llm_only
vectors
McTom234/oidc-key-algorithms
captcha_example
v26.05.2
v26.05.1
v26.05
v26.03.5
v26.03.4
v26.03.3
v26.03.2
v26.03.1
v26.03
v25.12.9
v25.12.8
v25.12.7
v25.12.6
v25.12.5
v25.12.4
v25.12.3
v25.12.2
v25.12.1
v25.12
v25.11.6
v25.11.5
v25.11.4
v24.11.4
v25.11.3
v25.11.2
v25.11.1
v25.11
v25.07.3
v25.07.2
v25.07.1
v25.07
v25.05.2
v25.05.1
v25.05
v25.02.5
v25.02.4
v25.02.3
v25.02.2
v25.02.1
v25.02
v24.12.1
v24.12
v24.10.3
v24.10.2
v24.10.1
v24.10
v24.05.4
v24.05.3
v24.05.2
v24.05.1
v24.05
v24.02.3
v24.02.2
v24.02.1
v24.02
v23.12.3
v23.12.2
v23.12.1
v23.12
v23.10.4
v23.10.3
v23.10.2
v23.10.1
v23.10
v23.08.3
v23.08.2
v23.08.1
v23.08
v23.06.2
v23.06.1
v23.06
v23.05.2
v23.05.1
v23.05
v23.02.3
v23.02.2
v23.02.1
v23.02
v23.01.1
v23.01
v22.11.1
v22.11
v22.10.2
v22.10.1
v22.10
v22.09.1
v22.09
v22.07.3
v22.07.2
v22.07.1
v22.07
v22.06.2
v22.06.1
v22.06
v22.04.2
v22.04.1
v22.04
v22.03.1
v22.03
v22.02.3
v22.02.2
v22.02.1
v22.02
v21.12.5
v21.12.4
v21.12.3
v21.12.2
v21.12.1
v21.12
v21.11.3
v21.11.2
v21.11.1
v21.11
v21.10.3
v21.10.2
v21.10.1
v21.10
v21.08.6
v21.08.5
v21.08.4
v21.08.3
v21.08.2
v21.08.1
v21.08
v21.05.4
v21.05.3
v21.05.2
v21.05.1
v21.05
v21.04.6
v21.04.5
v21.04.4
v21.04.3
v21.04.2
v21.04.1
v21.04
v0.31.8
v0.31.7
v0.31.6
v0.31.5
v0.31.4
v0.31.3
v0.31.2
v0.31.1
v0.31.0
v0.30.7
v0.30.6
v0.30.5
v0.30.4
v0.30.3
v0.30.2
v0.30.1
v0.30.0
v0.29.3
v0.29.2
v0.29.1
v0.29.0
v0.28.3
v0.28.2
v0.28.1
v0.28.0
v0.27.5
v0.27.4
v0.27.3
v0.27.2
v0.27.1
v0.27
v0.26.4
v0.26.3
v0.26.2
v0.26.1
v0.26.0
v0.25.5
v0.25.4
v0.25.3
v0.25.2
v0.25.1
v0.25.0
v0.24.3
v0.24.2
v0.24.1
v0.24.0
v0.23.2
v0.23.1
v0.23.0
v0.22.0
v0.21.0
v0.20.3
v0.20.2
v0.20.1
v0.20.0
v0.19.0
v0.18.5
v0.18.4
v0.18.3
v0.18.2
v0.18.1
v0.18.0
v0.17.4
v0.17.3
v0.17.2
v0.17.1
v0.17.0
v0.16.3
v0.16.2
v0.16.1
v0.16.0
v0.15.3
v0.15.2
v0.15.1
v0.15.0
v0.14.3
v0.14.2
v0.14.1
v0.14.0
v0.13.1
v0.13.0
v0.12.2
v0.12.1
v0.12.0
v0.11.2
v0.11.1
v0.11.0
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.2
v0.8.1
v0.8.0
v0.7.6
v0.7.5
v0.7.4
v0.7.3
0.7.2
v.0.7.1
v0.7.0
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.0
Labels
Clear labels
🎨 Design
📖 Docs Update
🐛 Bug
🐛 Bug
:cat2:🐈 Possible duplicate
💿 Database
☕ Open to discussion
💻 Front-End
🐕 Support
🚪 Authentication
🌍 Translations
🔌 API Task
🏭 Back-End
⛲ Upstream
🔨 Feature Request
🛠️ Enhancement
🛠️ Enhancement
🛠️ Enhancement
❤️ Happy feedback
🔒 Security
🔍 Pending Validation
💆 UX
📝 WYSIWYG Editor
🌔 Out of scope
🔩 API Request
:octocat: Admin/Meta
🖌️ View Customization
❓ Question
🚀 Priority
🛡️ Blocked
🚚 Export System
♿ A11y
🔧 Maintenance
> Markdown Editor
pull-request
Mirrored from GitHub Pull Request
No Label
🔨 Feature Request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/BookStack#3851
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @austozi on GitHub (Jun 12, 2023).
Describe the feature you'd like
I would like for the admin to be able to pre-set an expiration date for any user account to help automate user management. It could be added as a setting under Settings > Users > Edit User. Perhaps it could be implemented as part of the user roles, e.g., when a user account expires, the user is demoted to a lower access level which does not give them access to any content, without erasing/messing up the history of their contributions. Even better, if the access level they are demoted to can be customised, e.g., instead of not being able to access the content at all, grant them read-only access.
Use case: I use BookStack to manage information for a group of users. The users join the group for a pre-determined amount of time (typically 1 year). After that, they leave the group, whereupon their access to the BookStack instance should be revoked. At the moment I am doing this manually, but having to do so manually for multiple users at different times of the year (they join at different times) has become a chore. I basically have to monitor which user leaves when, and remember to log on to BookStack to revoke access for them. If I forget to do it, then the users have access to contents they should no longer have access to. I have only about ~10 users at any one time. It's not the number of users, but the fact that they all have different joining dates (and therefore revocation dates) and the constant turnaround of users, that make this difficult to manage manually.
Describe the benefits this would bring to existing BookStack users
It helps automate user management. Many corporate IT systems do this already, e.g., when you cease to be an employee, your access to the IT systems gets cut immediately, or within a predefined grace period. It saves admin time and effort, and importantly, enhances security by making sure users who should no longer have access cannot continue to access the content.
Can the goal of this request already be achieved via other means?
Short of doing it manually, there is currently no existing way to do it programmatically in BookStack (that I'm aware of).
Have you searched for an existing open/closed issue?
How long have you been using BookStack?
1 to 5 years
Additional context
No response
@ssddanbrown commented on GitHub (Jun 12, 2023):
Thanks for the request @austozi,
This feels like something quite specific though and, with lack of previous request for such a system, not something I'd maybe see as worthwhile supporting in the core project.
There's a couple of options to achieve this:
The API would be the best approach IMO, could likely tie it into any wider automation you may already have.
@austozi commented on GitHub (Jun 12, 2023):
Thanks for taking the time to reply, @ssddanbrown. I didn't know about the REST API. Sounds like the way forward. I'll investigate it!
@ssddanbrown commented on GitHub (Jun 20, 2023):
I'm going to go ahead and close this off, as per my comments and alternatives above, but if you need any further guidance in using those alternative options feel free to let me know, here or via our discord.