create new tag
, view all tags

Edittable Enhancements

This is a placeholder for some significant enhancements to EditTable plugin. The plugin is named different so that we can test this while not disturbing the existing setups.

Documentation is minimum, but I will add to this. The code is always there to see.

Using this plugin

  • Copy it to Plugins directory.
  • Create a topic called 'EditTable2Plugin' in TWiki web, and cut-paste the contents of EditTablePlugin topic.

This is still a development version. Data may be lost.

Key Features Summary

(Update 4th Sept 2003: Column access control is now enabled. THe syntax of acl specification has changed.)

Access Control On Rows

* ACL support - Row ACLs: Designate a column as ACL column, consisting of user IDs and group names, which will have full access to that row.

    • Specification: Within EDITTABLE2{}, use a new parameter acl="| | rowacl=owner:rw,everyone:ro,GuestGroup:rn,userC:rn | | |". Note that column 2 is assumed to contain ACLs that apply to each row.
    • In each row "| 3 | userC,guest:ro | xyz | xyz |". This row is said to be owned by 'userC' because of owner rights 'rw' specified in rowacl specification. (Use login IDs for this purpose.) Note that 'userC has also added guest to the list, but specified read only rights. If 'guest' doesn't appear in rowacl list, these rights will be applied. (Technically, both userC and guest are owners. But userC automatically has more rights due to rowacl default 'owner' setting. Rights assigned this way can only be lower.
    • Rights can be: ro=read only; rw=read-write; rb=only show ACL column value. All others columns are blank; rn=Don't show the row at all.
    • 'ALLOWTOPICTABLEACCESS' can be used to set Table access rights, without providing Topic Edit rights. By default, the table access rights are automatically granted if the user is not guest. (Assuming that the specifications in table take care of actual access controls.)

Access Control on Columns

  • Specification: Within EDITTABLE2{}, use the acl parameter (as defined in row acls) as follows: acl="| colacl=userA:rw,all:ro | rowacl=owner:rw,everyone:ro,GuestGroup:rn,userC:rn; colacl=everyone:rw,GuestGroup:rn,userC:rn | colacl=everyone:rw |"
    • Each column can be made Readonly, or even totally invisible to some group of users. (For e.g., supervisor could add a hidden column to put comments on each row entry contributed by his people.) Bad example, but unfortunately a reality in organizations.
    • Normally, all columns will require colacl specifications.
    • You can make 'rowacl' columns readonly. When new row is added, it will initiate it with user ID and can be made unchangeable. You can even make this column hidden.

ACL Example

Need to update with good example. - Vinod

%EDITTABLE2{header="| *Name* | *Comments* |" format="| text, 10 | text, 25 |" acl="| rowacl:owner=rw,all=ro | |" changerows="on"}%
|*Name*  |*Comments*  |
| usera | Greatly dislike this. Can't see what others write. |
| userb | Totally against wiki culture.     |
| guest | Not logged in== guest.      |
| userd |   |
Try 'all=rn' and 'all=rb'. You can even use user IDs and groups to give edit accesses to all the people.

Replication (And later, Synchronization)

  • Use 'Source="Web.Topic:num"' parameter to refer to another table in the other Web and Topic (num'th table). Use headers= parameter to identify the required headers; in any order. This will make the selected columns replicated in this table.
    • Only applies for new table i.e. no rows are specified. If it already finds a table, doesn't do anything.
    • The algorithm to match header is simplistic: It identifies the first continuous word with spaces and '-' in between. It is likely to fail for complex headers.
    • Use this to switch columns, or select subset of columns and create a new table. Normally maintain all the rows in one topic, and replicate the table, so specific columns are always pre-initialized.
    • headers="all" will copy all the headers.

  • Full (one-way) synchronization is in the works i.e. even after the table is replicated for the first time, the corresponding columns will be updated.

Table Metadata definition as Table

  • i.e. you can manage headers of table in another table.
  • Usage: In the table definition topic (i.e. you include this topic in other table definitions, with include= syntax), specify 'format="tabledef"' instead of the usual specification of column types.
  • When you view this topic, the table is auto-generated. The rows of this table are column definitions of the other table definitions which include this topic.
  • Only applies to first table in the topic.


This will produce "Edit Table" button, that allows you to define columns. A table is appended as usual. This table is inverted and converted into appropriate 'format=' and 'header=' strings. The columns are hardcoded as of now. New columns can be easily added - such as 'acl' as defined above.

Formatted output of Rows (Layout Control)


  • With "one row per person" access control definitions, only one row is shown to user in view as well as in edit screens. It then makes sense to change layout so that we can place the columns not just horizontally (i.e. default) but vertically as well.
  • The ordering of columns shown in view and edit can be independent of how they are in the stored in the file (i.e. when you use 'Edit'.)
  • You want to produce outputs in different formats - such as CSV file etc.

How you specify

Already Implemented

  • rowlayout="| ${1} | ${Name}, ${Surname} | ${Date of Birth} |"
  • 1,2,3 (i.e. a digit used to identify specific column.
  • You can also use header names. However header names need to map to a syntax (to be documented) - a continuous string of characters, blanks, digits, '-' and couple of more such characters.
  • Same layout is used for both view and edit.
  • Vertical bars will be interpreted by twiki as usual. You can use HTML tags instead.

To be implemented

  • A 'totalslayout' for quick functions such as sum (i.e. where you don't want to use SpreadSheetPlugin.)
  • 'viewlayout' and 'editlayout' to be separated.

Important: Naming the column Header names

Right now I am using an algorithm: Longest series of chars with alphanumeric + space + '-' characters will be treated as header.

But going forward, we do require a standard. For example, FormQueryPlugin has similar requirements; from its page:

A crucial point. Field names - form items and table columns - must observe the following rules:
    * They must not contain '.'
    * They must contain at least one alphanumeric character
    * They must be unique after all the non-alphanumeric characters have been removed
    * They must not conflict with any of the auto-generated relation names.

We can come back to this later.

Plugin Code


Comments, Use Cases, Whether specifications look OK, ..., ...

-- VinodKulkarni - 29 Aug 2003


Topic attachments
I Attachment History Action Size Date Who Comment
Perl source code filepm EditTable2Plugin.pm r3 r2 r1 manage 64.3 K 2003-09-10 - 00:42 VinodKulkarni EditTable2 Plugin.pm File
Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2003-09-10 - VinodKulkarni
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.