Usual CSS woes
- Really not confident about positioning top and left with `em`.
- Z-index shenanigans to skip unexpected offset in positioning,
where the absolute of a child in a relative container
won't point to top left but to bottom of other child in static
(try moving the merit profile below the input.emote, and remove z-indices)
Right now the merit profile is shown to all logged in, whether they judged or not. This is not the intended final behavior. Ideally we'd have settings fdr this.
Still experimenting with the spacing in templates.
I know Gitea does not use spaces.
My sight is not getting any better,
and spacing helps a lot.
Yes, I'm already using bigger fonts.
After careful consideration, it's probably best to namespace.
Also, explicit is better than implicit. :)
BREAKING CHANGE: Not sure how the migrations will operate here.
This is why it's best to do it now than once we're actually using it.
Ideally this whole thing should be a plugin and not a fork.
Not sure how to add new Db models and Routes.
We'd also need a custom spot in the issue view template,
but that can probably be merged upstream.
So far it holds.
The score is a bit long (90chars = 15 chars per possible grade)
but it won't get any longer with more judges,
unless we have to go over 500 billion judges.
This was entertaining, but it's perhaps wrong,
although we can't find any reason why so far.
We contacted the world's top specialist on the matter.
…
Three gods, A, B, and C are called,
in no particular order, True, False, and Random.
True always speaks truly, False always speaks falsely,
but whether Random speaks truly or falsely is a
completely random matter.
Your task is to determine the identities of A, B, and C
by asking three yes-no questions; each question
must be put to exactly one god. The gods understand
English, but will answer all questions in
their own language, in which the words for yes
and no are da and ja, in some order.
You do not know which word means which.
* Fix bug preventing transfer to private organization
The code assessing whether a private organization was visible to a user before
allowing transfer was incorrect due to testing membership the wrong way round
This PR fixes this issue and renames the function performing the test to be
clearer.
Further looking at the API for transfer repository - no testing was
performed to ensure that the acting user could actually see the new
owning organization.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* change IsUserPartOfOrg everywhere
Co-authored-by: zeripath <art27@cantab.net>
domi41
zeripath
techknowlogick