Resolve "dynamic_preferences.preferences.InvalidNameError: Sequence "__" is forbidden in section and preferences name, since it is used to access values via managers" #135
No reviewers
Labels
No labels
Security
TeX
auto-update
board
done
board
ready
board
todo
check
delete-eslint-rc-js
check
update-builddeps-package-json
check
update-eslint-rc-js
check
update-gitignore
check
update-merge-request-template
check
update-prettier-ignore
check
update-pyproject-toml
check
update-renovate-json
check
update-tox-ini
part
backend
part
ci
part
docs
part
frontend
part
i18n
part
non-technical
part
packaging
prio
1
prio
2
prio
3
release-mr-5.x
size
large
size
medium
size
small
source
customer
source
customer::fsmw
source
customer::fss
source
customer::teckids
source
downstream
type
breaking
type
bug
type
feature
type
refactoring
workflow
blocked
workflow
confirmed
workflow
current-todo
workflow
discussing
workflow
new-app
workflow
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
aleksis/AlekSIS-App-LDAP!135
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "30-dynamic_preferences-preferences-invalidnameerror-sequence-__-is-forbidden-in-section-and"
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?
Closes #30
assigned to @hansegucker
added 1 commit
6a2a2b69- Use re to replace underscores in preference namesCompare with previous version
assigned to @nik and unassigned @hansegucker
marked this merge request as ready
added 3 commits
master776f9167- Merge branch 'master' into...Compare with previous version
This change is invalid, because it produces name clashes. The
.must not be replaced by a character sequence which is a valid part in a field name.But then it was already wrong?
Umm… maybe. But maybe not. Isn't
__invalid in field names as well? In that case, the function is entirely useless…In any case, if we fix it, we should fix it for real.
It definitely occurs in field names, so it can't be invalid.
Can you please give me an example for such a name clash?
Yes, well, obviously…
foo__bar → foo_barclashes withfoo_bar → foo_barOh, and:
https://docs.djangoproject.com/en/3.2/topics/db/models/#field-name-restrictions
"A field name cannot contain more than one underscore in a row […]"
Where do we have a field name with more than one underscore in a row, in your opinion?
changed this line in version 3 of the diff
added 1 commit
Compare with previous version
resolved all threads
@nik Can you please review again?
name_without_underscoresis a misleading name, give nthat this substitution's replacement character is an underscore.This will produce an invalid name for fields ending in
_(e.g.key_)This needs a migration path from the old setting names!
changed this line in version 4 of the diff
changed this line in version 4 of the diff
added 1 commit
Compare with previous version
Please choose a better name. I was always thinking of
preficēsreading this abbreviated name, and then found it to be sufficēs ;)resolved all threads
changed this line in version 5 of the diff
added 1 commit
1459327b- Add hash to preference names to prevent double namesCompare with previous version
@nik I tested the migration and it worked fine. So, please review again and then merge.
mentioned in commit
f7ea0c24a7