Hey @Glenn_Jaume thank you for the response!
I know you understand the technical aspects of this better than I, and if you need to have the permissions be constant throughout the dDoc and the pubDoc, so be it.
However there are some things Coda could do to make it easier for Makers and the users of their docs.
First of all, speak plainly. The language / UX around this issue is confusing; no one on the forums, nor the Codans answering here and in intercom support, were able to articulate the actual policy as you did. So that would have gone a long way in terms of managing expectations. Perhaps the reason that 95% of the publishing is view/edit is because publish/edit is not accurately articulated and doesn’t work the way its expected to, so this is a fallacy to think that metric is guiding. Having publish/edit unlocks so many possibilities!
If true Publish/Edit can’t be achieved, how about hardening the ‘Edit’ and ‘Locking’ features so that the Ddoc can act published. For example:
- disable search bar
- disable show hidden pages
- hide side bar > top
- hide Coda chrome
- don’t show dDoc on coda homepage
We’re trying to make interfaces that people expect and aren’t distracted by things. For example, if I want to create a ‘search’ feature for the user to find something in a certain table, we can show them that, but a month later when they come back to the doc and the first thing they see is the persistent and noticible search box, it confuses them and they use that and then it brings up a hundred unrelated responses and they think its broken.