Allow setting wiki writeable for all users on an instance #6312

ashimokawa · 2019-03-12T14:46:06Z

This change allows to set wikis of an organization wiki to writable for all user of an instance.
This setting is also available on github (even default?).

Internally the setting is available to all Units but currently only used for wiki.

This PR is heavily inspired by #5833 by @lunny, and will conflict with his. Thanks and sorry 😅

codecov-io · 2019-03-12T15:00:04Z

Codecov Report

Merging #6312 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #6312      +/-   ##
==========================================
- Coverage   38.82%   38.81%   -0.02%     
==========================================
  Files         359      359              
  Lines       51137    51146       +9     
==========================================
- Hits        19854    19850       -4     
- Misses      28411    28425      +14     
+ Partials     2872     2871       -1

Impacted Files	Coverage Δ
models/repo_unit.go	`61.4% <ø> (ø)`	⬆️
modules/auth/repo_form.go	`43.24% <ø> (ø)`	⬆️
routers/repo/setting.go	`10.18% <0%> (-0.02%)`	⬇️
models/repo_permission.go	`68.18% <0%> (-3.85%)`	⬇️
models/unit.go	`0% <0%> (-14.29%)`	⬇️
routers/repo/view.go	`41.08% <0%> (-1%)`	⬇️
modules/process/manager.go	`81.15% <0%> (+4.34%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b2e9894...e56187c. Read the comment docs.

lunny · 2019-03-16T12:38:04Z

I think you mean default read or default write for a unit of repository?

ashimokawa · 2019-03-17T11:28:29Z

@lunny
Sorry, I do not understand your question.

This PR is for optionally making wikis of organizations writable to all logged in users (not anonymously).

lunny · 2019-03-17T12:57:20Z

@ashimokawa I think your PR is for the unit default permission for all logged users. Currently public repositories will let logged in user read all the unit of them. But this PR will change the default to write.

ashimokawa · 2019-03-17T13:08:20Z

@lunny
I intended to only set the permission to write if the flag AllowWriteAll is set for a unit (this flag is only set for the wiki unit type so far, if the checkbox is set an orianziations repo)

This is my first time tinkering with the code base, would you mind to explain what I missed? Your comment suggest that my PR is actually doing more than I intended, right?

lunny · 2019-03-17T13:13:19Z

Yes, I mean the column AllowWriteAll is too special. Maybe DefaultPermission is better. This column could be Read or Write and default should be Read to keep compatible with old version.

ashimokawa · 2019-03-17T14:34:55Z

@lunny
You mean literally storing a string "Read" or "Write" in a string type database column?
I can do that if you want, I just looked at #5833, and there you also introduced a new flag - so I followed that pattern.

stale · 2019-05-16T15:07:06Z

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

ashimokawa · 2019-05-18T06:25:00Z

@lunny
Still waiting for an answer to the question above.
As I said I am willing to change that as you wish at long as there is a chance then that it gets actually merged.

davidsvantesson

As lunny I think this should be more generic. Maybe even None should be a possible value (to restrict an otherwise public repo)

davidsvantesson · 2019-12-03T20:35:11Z

templates/repo/settings/options.tmpl

 							<label>{{.i18n.Tr "repo.settings.use_internal_wiki"}}</label>
 						</div>
 					</div>
+					{{if .Repository.Owner.IsOrganization}}


Setting should only be available for public repositories?

lunny · 2019-12-04T15:22:06Z

models/repo_unit.go

+	ID            int64
+	RepoID        int64    `xorm:"INDEX(s)"`
+	Type          UnitType `xorm:"INDEX(s)"`
+	AllowWriteAll bool


We need a migration.

I thought false is the default, then we would still need it?

All database structure changes should have a migration. You can find many example on models/migration

Thanks, I see, I somehow thought that there was some magic invovled which inserts missing columns automagically.

There is some magic involved, and you've probably got your column migrated automagically.

There are two stages to Gitea migration:

The "manual steps" stage (from models/migration), that update the internal version and change data as needed.

The "startup" stage, where any remaining database structure is updated.

The problem comes when you rely on the 2nd stage to do your migration. It will work the first time, but in the future (e.g. Gitea 12.2) some manual steps can be added in the first stage of the migration that will need the structure that is not there yet (as it is created in the 2nd stage). If some user attempts to migrate from 1.10 to 12.2, all the steps on stage 1 will be executed, and that particular step will fail because of the missing column.

That's why we don't rely on the 2nd stage and make all migration steps explicit, so any upcoming step can count on the previous steps to upgrade the database to the expected state.

I hope this makes sense!

Thank you for a great explanation! Understood and I am convinced ;)

ashimokawa · 2019-12-05T17:36:05Z

To be honest I do not like that this setting only works for wikis of repos of organizations (not if the repo is owned by a normal user), it has been a while, so I have to look up why I found it difficult to do it for all wikis.

a1012112796 · 2020-08-25T14:45:27Z

Hmm, I think we should do more work about improving collaborative authoring support for wiki.

wxiaoguang · 2023-04-25T13:22:12Z

This PR has been stale for long time, and it seems there are not enough people having interest in it?

fnetX · 2023-04-28T22:28:54Z

There is a lot of interest in it. It's repeatedly requested by users on Codeberg since this is literally what a "wiki" is meant for.

For example: https://codeberg.org/Codeberg/Community/issues/28 and https://codeberg.org/leiningen/leiningen/issues/13 and sometimes via Mastodon.

wxiaoguang · 2023-04-29T02:33:31Z

Thank you for letting me know the context.

Then the question is:

Is the approach good and safe enough, any design document? eg: make sure writers won't do force push to destroy the wiki, or block some user from spamming (I am not sure, just curious)
Is this PR active and maintainable?

fnetX · 2023-05-02T14:31:52Z

No, the code is not currently used, because rebasing it was too much effort.

I was thinking about this in the past days, but I'm not fully sure. While we considered a trust/reputation system for new users a few times already, this is likely out of scope for this PR. Since this Pr added a switch, it is probably for the projects to deal with it (one project had a patch in use for a few times quite successfully).

Bonus features could be:

easy reverting of commits via the GUI
commits from users without write access (or better: without previously accepted contribution) require an approval from a maintainer

But I think the patch as-is is useful and a quick fix for a problem where moderation features can be added later.

wxiaoguang · 2024-04-15T09:35:16Z

Thank you ashimokawa for this PR. Since it has been stale for long time (there is still no migration or progress), I think we could close it. I managed to proposed a new one:

-> Allow everyone to read or write a wiki by a repo unit setting #30495

Replace #6312 Help #5833 Wiki solution for #639

GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Mar 12, 2019

lunny added the type/enhancement An improvement of existing functionality label Mar 16, 2019

stale bot added the issue/stale label May 16, 2019

lunny added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label May 16, 2019

stale bot removed the issue/stale label May 16, 2019

davidsvantesson suggested changes Dec 3, 2019

View reviewed changes

lunny requested changes Dec 4, 2019

View reviewed changes

Allow setting wiki writeable for all users on an instance

92bf953

Codeberg-org force-pushed the global-wiki-edit branch from e56187c to 92bf953 Compare August 29, 2021 17:52

wxiaoguang added the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label Apr 25, 2023

wxiaoguang removed the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label Apr 29, 2023

wxiaoguang mentioned this pull request Apr 15, 2024

Allow everyone to read or write a wiki by a repo unit setting #30495

Merged

wxiaoguang closed this Apr 15, 2024

wxiaoguang added a commit that referenced this pull request Apr 17, 2024

Allow everyone to read or write a wiki by a repo unit setting (#30495)

3feba9f

Replace #6312 Help #5833 Wiki solution for #639

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow setting wiki writeable for all users on an instance #6312

Allow setting wiki writeable for all users on an instance #6312

ashimokawa commented Mar 12, 2019

codecov-io commented Mar 12, 2019

lunny commented Mar 16, 2019

ashimokawa commented Mar 17, 2019

lunny commented Mar 17, 2019

ashimokawa commented Mar 17, 2019

lunny commented Mar 17, 2019 •

edited

Loading

ashimokawa commented Mar 17, 2019

stale bot commented May 16, 2019

ashimokawa commented May 18, 2019

davidsvantesson left a comment

davidsvantesson Dec 3, 2019

lunny Dec 4, 2019

ashimokawa Dec 5, 2019

lunny Dec 6, 2019

ashimokawa Dec 6, 2019

guillep2k Dec 6, 2019

ashimokawa Dec 7, 2019

ashimokawa commented Dec 5, 2019

a1012112796 commented Aug 25, 2020

wxiaoguang commented Apr 25, 2023

fnetX commented Apr 28, 2023

wxiaoguang commented Apr 29, 2023

fnetX commented May 2, 2023

wxiaoguang commented Apr 15, 2024

Allow setting wiki writeable for all users on an instance #6312

Allow setting wiki writeable for all users on an instance #6312

Conversation

ashimokawa commented Mar 12, 2019

codecov-io commented Mar 12, 2019

Codecov Report

lunny commented Mar 16, 2019

ashimokawa commented Mar 17, 2019

lunny commented Mar 17, 2019

ashimokawa commented Mar 17, 2019

lunny commented Mar 17, 2019 • edited Loading

ashimokawa commented Mar 17, 2019

stale bot commented May 16, 2019

ashimokawa commented May 18, 2019

davidsvantesson left a comment

Choose a reason for hiding this comment

davidsvantesson Dec 3, 2019

Choose a reason for hiding this comment

lunny Dec 4, 2019

Choose a reason for hiding this comment

ashimokawa Dec 5, 2019

Choose a reason for hiding this comment

lunny Dec 6, 2019

Choose a reason for hiding this comment

ashimokawa Dec 6, 2019

Choose a reason for hiding this comment

guillep2k Dec 6, 2019

Choose a reason for hiding this comment

ashimokawa Dec 7, 2019

Choose a reason for hiding this comment

ashimokawa commented Dec 5, 2019

a1012112796 commented Aug 25, 2020

wxiaoguang commented Apr 25, 2023

fnetX commented Apr 28, 2023

wxiaoguang commented Apr 29, 2023

fnetX commented May 2, 2023

wxiaoguang commented Apr 15, 2024

lunny commented Mar 17, 2019 •

edited

Loading