Allow the creation of Project Wikis using the internal provider

[mereghost]

This covers parts of OP#XWI-52, OP#XWI-53 and OP#XWI-54 on the OP#XWI-42 feature.

What is missing at this moment:

• Updated Wiki enable/disable tests.
• Update flash messages

[github-actions]

Warning

This pull request does not link an OpenProject work package.

Please add a link to the work package in the description, or reference it in the
title in square brackets, e.g. [SLUG-123] My title here.

[mereghost]

Early feedback is welcome. It builds upon its parent branch.

[NobodysNightmare]

Some first preliminary feedback

[NobodysNightmare]

Nothing that you introduced, but I have to admit that I find it very weird to have a parameter user that can be passed in, that has a default value that can never be nil and then still perform a nil check as the first thing.

[mereghost]

That was probably just some rubocop appeasing at some point.

Well... User.current could be nil

[NobodysNightmare]

I am pretty sure that it can't. We always fall back to the anonymous user...

[mereghost]

Even on test cases? 😮

[NobodysNightmare]

If not, the test cases would behave weird and we'd adapt code purely to work with test cases that behave different than reality.

I didn't check test cases, but I can confirm that opening a fresh rails console also gives me the anonymous user when calling User.current.

[NobodysNightmare]

This method looks unfinished (aside from the TODO comment), I am wondering if it's doing what's intended:

• 3 places call it @project, one place calls it project
• The guard clause returns the wiki after reloading the project, the last clause returns the reloaded project
  • the return value is not used

Right now, I think what you need is

Wiki.create!(project: @project, start_page: "Wiki") unless Wiki.exists?(project: @project)

@project.reload

I also realize (and that's what your FIXME probably hints at) that this is the second place where a wiki is created during seeding, so maybe something can be improved/centralized here.

[mereghost]

Yeah, this whole process got messy right now. It was handled by AR hooks and now we need a proper implementation / solution.

[NobodysNightmare]

😱 😱 😱

[NobodysNightmare]

Probably a good case for component-relative translations?

I.e. t(".enable") and t(".caption")

[NobodysNightmare]

That's a surprising consequence of a method overwrite I saw earlier.

I'd have expected that this would read @project.wiki.enabled?, because that would seem to make sense right?

However, the Project will act as if it has no wiki, unless the wiki is enabled. I guess that this is great for compatibility with existing code, but it definitely also leads to surprising places like this one.

[mereghost]

Agreed. The codebase used to check for the enabled module, now we need 2 different checks: Internal Provider and the Project Wiki.

I'll see if I can de-crapify some of the checks around it without breaking another 400 tests.

[NobodysNightmare]

TODO ^^

[NobodysNightmare]

This is confusing. find_project_wiki is already a before_action, so this method was already executed and it would probably be enough to write if @wiki.

On the other hand, this is the only method that refers to @wiki at all, so I am wondering, whether this should be inlined or at least de-instance-variablified.

E.g.

def create_or_update_wiki
  wiki = Wiki.find_by(project: @project)
  if wiki
    wiki.toggle!(:enabled)
  else
    Wiki.create!(project: @project, start_page: "Wiki")
  end
end

[mereghost]

Oh... it is a remnant of a previous implementation. Good catch.

[NobodysNightmare]

Reminder to self that I wanted to talk to Parimal about this:

• mention of "module" makes this sentence unnecessarily technical
• should we even mention external wiki providers at all?
• the final sentence is complex and does not seem to be correct (e.g. we even hide existing wiki pages, if an external provider exists)

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24195, linked for reference only):

- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]`

Treat this as a standalone task, unrelated to PR #24195. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24195 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @mereghost to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @mereghost, and request a review from @mereghost.
On every commit, set @mereghost as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.