[Koha-bugs] [Bug 14957] Write protecting MARC fields based on source of import

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957

--- Comment #156 from David Gustafsson <glasklas at gmail.com> ---
Thanks for the feedback. I more or less agree with all of pointed out issues
and not that it matters but those design choices, including the somewhat
cryptic naming of modules, were not made by me but comes from the original
version of the patch. I have not addressed them since just wanted to spend the
minimal effort for the patch to get into Koha and have focused on the issues
brought up thus far. But at least 4) has been brought up before and I should
perhaps have fixed that in the current iteration of the patch since the modules
are added in an atomic update and I saw no other instance where data is
inserted in kohastructure.sql. Thus if making a fresh Koha installation this
data will be missing which is not acceptable. Since the modules are not invoked
dynamically in the code, but are hard coded, it makes more sense for them to be
defined as constants, which would resolve the database population issue. I
think this should be pretty uncomplicated to refactor, by hard coding the
modules in the template (to make the label translatable) making that the
authoritative source. In my opinion there is a rather urgent need for having
translatable strings in Koha without (ab)using the template system, but that is
out of the scope of this bug.

About 4) I agree that is to use borrowernumber is not pretty, I guess the
reason it is used instead of userid is it is available in scope without having
to look up the userid in a database call, but userid (username) would be
better. I also agree that it is probably a very rare use-case to need to
specify rules per user, but on the other hand, since the cost of providing this
context is relatively low, it might also be a little bit presumptuous to remove
the option. For example, it is a simple way to allow certain super-users to
override all rules by creating a wildcard "allow all" rule without having to
reserve a user category for this purpose.

-- 
You are receiving this mail because:
You are watching all bug changes.