如果临时编目库的用意是让中心的馆员用户提交待编书目记录，似乎可以不要赋予他们 delete 的子操作权限。
如果赋予了这个权限，意味着，假如出现了一个喜欢捣乱的用户，他就可以把这个库中的记录一条一条给删除了。虽然这个库中的记录不是最重要，但其他用户刚放进去的记录被删除了也是很麻烦的。
可以改进为给他们赋予 ownerdelete 权限。就是说，一个人只能删除他创建的书目记录，不能删除别人创建的书目记录。
但，如果修改的权限 change 赋予了用户，他如果存心要捣乱的话，依然可以利用这个权限修改记录后保存，把一条记录修改成很短的几乎没有内容的状态，也变相实现了类似删除的效果。要防范这种情况、再严格一点的话，可以用 ownerchange 来替代 change 权限，这样，只有这个用户自己创建的记录才能修改了，他修改不了其他人创建的记录。
不过，任何事情都是有正反两面性的。本来，在正常情况下，如果馆员之间互相帮助，你可以修改我的记录，我可以修改你的记录，其乐融融是很不错的。有时候出现了错别字，别人发现了，就随手改了。或者，帮助别人删除发现重复的记录(当然前提是这条记录下面还没有登记册记录)，也本是一种好事。
一旦失去了相互的信任，或者处在“半信任”状态，势必要求软件严格限制权限。如上所述，简单可以分为两个级别：第一个是卡住删除权限；第二个就还要卡住修改权限。越来越严和细致。
这里我只能说，软件提供了这些设施，用户单位需要根据自己的实际情况加以选择，并没有一种标准的应用模式。
在权限受限的情况下，如果馆员本来要直接修改书目记录，但权限不允许了，他们可以改为用添加评注记录提出意见，因为评注记录跟随在书目记录之下，也算是一种方便的注释和反馈意见的措施。那么有权限的管理员就需要频繁观看最新的评注记录，亲自进行必要的数据维护操作了。