Files
@ dd9cb0a5aba3
Branch filter:
Location: kallithea/docs/usage/locking.rst - annotation
dd9cb0a5aba3
1.1 KiB
text/prs.fallenstein.rst
admin: hooks: restore delete functionality as intended
Commit 9d34bea3059d9abd0d912f37a2475ee67c8e2918 ("style: various minor-ish
markup changes, preparing for Bootstrap") partially broke the delete
functionality of hooks. When clicking the delete button, the hook is deleted
via AJAX and then the corresponding form group is intended to be removed
visually. This relies on an 'id' attribute on the form-group div.
The mentioned commit moved the div with the 'id' attribute outside the loop
iterating over the different hooks, so that there no longer is a div with
the id expected by the delete button. The hook would still be deleted, but
the page visually still looks the same until refresh/Save.
Move the diff back into the loop. This causes a little more visual
separation between the different hooks, but still looks OK.
The layout of the built-in hooks (that can't be removed) is left untouched.
Making the same change there would be possible but there the extra vertical
whitespace seems somewhat unnecessary, although this is personal.
Commit 9d34bea3059d9abd0d912f37a2475ee67c8e2918 ("style: various minor-ish
markup changes, preparing for Bootstrap") partially broke the delete
functionality of hooks. When clicking the delete button, the hook is deleted
via AJAX and then the corresponding form group is intended to be removed
visually. This relies on an 'id' attribute on the form-group div.
The mentioned commit moved the div with the 'id' attribute outside the loop
iterating over the different hooks, so that there no longer is a div with
the id expected by the delete button. The hook would still be deleted, but
the page visually still looks the same until refresh/Save.
Move the diff back into the loop. This causes a little more visual
separation between the different hooks, but still looks OK.
The layout of the built-in hooks (that can't be removed) is left untouched.
Making the same change there would be possible but there the extra vertical
whitespace seems somewhat unnecessary, although this is personal.
aa17c7a1b8a5 aa17c7a1b8a5 8d065db04909 8d065db04909 8d065db04909 aa17c7a1b8a5 5ae8e644aa88 8d065db04909 03bbd33bc084 03bbd33bc084 5ae8e644aa88 5ae8e644aa88 8d065db04909 aa17c7a1b8a5 5ae8e644aa88 8d065db04909 aa17c7a1b8a5 8d065db04909 5ae8e644aa88 8d065db04909 aa17c7a1b8a5 8d065db04909 8d065db04909 5ae8e644aa88 8d065db04909 aa17c7a1b8a5 8d065db04909 8d065db04909 | .. _locking:
==================
Repository locking
==================
Kallithea has a *repository locking* feature, disabled by default. When
enabled, every initial clone and every pull gives users (with write permission)
the exclusive right to do a push.
When repository locking is enabled, repositories get a ``locked`` flag.
The hg/git commands ``hg/git clone``, ``hg/git pull``,
and ``hg/git push`` influence this state:
- A ``clone`` or ``pull`` action locks the target repository
if the user has write/admin permissions on this repository.
- Kallithea will remember the user who locked the repository so only this
specific user can unlock the repo by performing a ``push``
command.
- Every other command on a locked repository from this user and every command
from any other user will result in an HTTP return code 423 (Locked).
Additionally, the HTTP error will mention the user that locked the repository
(e.g., “repository <repo> locked by user <user>”).
Each repository can be manually unlocked by an administrator from the
repository settings menu.
|