Admin Panel / Settings / Visibility / Rules gets "Boards may show their
Rules to members, read-only", off by default (Settings
rulesReadOnlyForMembers, site admin only). With it on, a board admin ticks
"Show these Rules to board members, read-only" on the board's Rules page
(rulesVisibleToMembers). Members of that board then get Rules in Board
Settings and see the rules list and each rule's details, with no control
that changes a rule; the methods that change rules keep their board-admin
checks, so nothing is granted. Without both ticks only board and site
admins see the Rules page, which until now drew its list for any member
who opened the address.
models/lib/rulesReadOnly.js decides 'edit', 'read' or 'none', and
client/lib/rulesAccess.js is the one place the Rules page, Board Settings
and rule details ask. tests/rulesReadOnly.test.cjs covers both switches,
each alone, a non-member, and that a reader's page has no edit control.
boardMenuOrder now leaves the reader's alternative branch out of the
admin's sequence and pins it alone; instanceFeatures counts the fourth
site-admin method; roleHelperRegressions follows the canAdmin check to
rulesAccess.js. The new strings are English placeholders until the next
translation pass.
Thanks to justinr1234 and xet7 !
Fixes#2217.
Admin Panel / Settings / Visibility / Optional APIs ticks REST APIs in the
shape of Trello's, Jira's, GitHub's and Gitea's, so apps and scripts written
for them - Trellinator, Jira and GitHub clients - can use WeKan as their
backend, each described on the page with the address a client uses.
None has rights of its own. Each is a translator: a request in the other
tracker's shape becomes the matching request to WeKan's own REST API, made
with the caller's own WeKan token on the loopback address, and the answer
becomes the other tracker's JSON. Every WeKan permission therefore applies
unchanged - read-only and comment-only roles, assigned-only members, list
permissions - and an API that is not ticked answers 404. All of them sit
under /api, so WITH_API turns them off with the rest of the REST API.
Trello: members, boards, lists, cards, labels, comments and checklists; a
deleted card is archived. Jira: projects are boards (the board key), issues
are cards (DEV-7), statuses are lists and transitions move cards, with
simple JQL. GitHub and Gitea: repositories are boards and issues are cards,
open or closed as in Board View / Version Control, with labels, milestones,
comments and Link pagination.
The new strings are translated in every locale. A runtime test over real
HTTP shows a read-only member refused and a Trello-created card readable
through Jira and GitHub.
Thanks to xet7 !
Fixes#4930.
Above the Features Save there is now one tick per field type of Board
Settings / Card - the same icons and names, all ticked by default. An
unticked field, for example Pomodoro, is not offered in any board's Board
Settings / Card and is not shown on any opened card or minicard, whatever
the board chose. Visibility only: no card data and no board setting is
written, so ticking it again shows every board as it was set. There is no
ordering here; the order stays each board's own.
The catalog and the decisions are models/lib/cardFieldVisibility.js. It is
stored as cardFieldStates on the settings document (missing means shown,
so existing installs are unchanged), published with the other Features
settings and saved by the site-admin-only saveInstanceFeatures method,
which refuses unknown field keys. The hiding happens at the client's one
board read (ReactiveCache.getBoard), which returns the board with the
hidden fields' flags reading false - the same object when nothing is
hidden - so every card and minicard template that reads a board flag agrees
without being edited; the per-card List title and the user's Labels text
override check the same mark. The server's reads, publications and the REST
API are unchanged. A whole-column tick in Board Settings / Card leaves the
hidden fields' board values alone.
Thanks to xet7 !
Admin Panel / Settings / Visibility has a new Features group. Each
optional group of board views (Table, Calendar, Time, Overview, Gantt,
Scrum, Flow charts, Map) can be turned off for the whole instance. A
disabled feature is removed from the Board View menu and from Board
Settings / Board View rather than greyed out, and a user who had it open
is moved to the board's default view. Its data and every permission stay
as they are.
Administrators can preview disabled features, and named pilot users see
them too. An opt-in policy keeps features added by later WeKan updates
disabled until an administrator enables them; the features present when
it is turned on stay as they were. Swimlanes and Lists are core and
cannot be disabled. The English texts are pending Transifex.
Thanks to nalilord and xet7 !
Fixes#6736.
Lauri Ojansivu