aliasing2

common/proto/table_definition.proto

@@ -108,14 +108,18 @@ message PostTableDefinitionRequest {
 // column, though, so it is free to be anything: this is where that choice is
 // made, instead of a RenameColumnAlias call afterwards.
 //
-// The ACCOUNTING_TRANSFER connectors are the exception. They are refused here
-// exactly as RenameColumnAlias refuses them.
+// Only ACCOUNTING's columns may be renamed. Renaming a generated column
+// requires its relationship to whatever generated it to be recorded, so the
+// rest of the system can find it without knowing its name; ACCOUNTING has that
+// in table_accounting_definitions, and nothing else does. The ACCOUNTING_
+// TRANSFER connectors and the PHONE and IBAN companions are refused, the
+// latter because a row write finds them by rebuilding their names from their
+// parent column's name.
 message GeneratedColumnAlias {
   // The name the backend would otherwise give the column: one of ACCOUNTING's
-  // "name", "tax_point_date", "debit", "credit" or "account", or a companion
-  // such as "work_phone_extension". Must name a column the request really
-  // generates -- an alias for anything else is rejected rather than ignored,
-  // so a typo cannot pass silently.
+  // "name", "tax_point_date", "debit", "credit" or "account". Must name a
+  // column the request really generates -- an alias for anything else is
+  // rejected rather than ignored, so a typo cannot pass silently.
   string generated_name = 1;
 
   // What the column should be called instead. Same rules as any column name.

common/src/proto/komp_ac.table_definition.rs

@@ -56,16 +56,20 @@ pub struct PostTableDefinitionRequest {
 /// column, though, so it is free to be anything: this is where that choice is
 /// made, instead of a RenameColumnAlias call afterwards.
 ///
-/// The ACCOUNTING_TRANSFER connectors are the exception. They are refused here
-/// exactly as RenameColumnAlias refuses them.
+/// Only ACCOUNTING's columns may be renamed. Renaming a generated column
+/// requires its relationship to whatever generated it to be recorded, so the
+/// rest of the system can find it without knowing its name; ACCOUNTING has that
+/// in table_accounting_definitions, and nothing else does. The ACCOUNTING\_
+/// TRANSFER connectors and the PHONE and IBAN companions are refused, the
+/// latter because a row write finds them by rebuilding their names from their
+/// parent column's name.
 #[derive(serde::Serialize, serde::Deserialize)]
 #[derive(Clone, PartialEq, Eq, Hash, ::prost::Message)]
 pub struct GeneratedColumnAlias {
     /// The name the backend would otherwise give the column: one of ACCOUNTING's
-    /// "name", "tax_point_date", "debit", "credit" or "account", or a companion
-    /// such as "work_phone_extension". Must name a column the request really
-    /// generates -- an alias for anything else is rejected rather than ignored,
-    /// so a typo cannot pass silently.
+    /// "name", "tax_point_date", "debit", "credit" or "account". Must name a
+    /// column the request really generates -- an alias for anything else is
+    /// rejected rather than ignored, so a typo cannot pass silently.
     #[prost(string, tag = "1")]
     pub generated_name: ::prost::alloc::string::String,
     /// What the column should be called instead. Same rules as any column name.