I’d appreciate any tips, and please excuse the dumb title, but I didn’t think opening a thread for each of these questions would make sense. Not expecting to be spoon-fed so if there’s a temple which partially does this, please point me at it, and I’ll go see what parts I can re-use.
Here’s what I am trying to do:
I occasionally employ somebody on an hourly basis. I would like to have one table and a dashboard which shows 3 widgets to work with that table.
The table should be populated by a form which should sit on my dashboard at (1) where I enter the starting date/time and the end date/time. It should immediately show the payment due at (4) before even submitting, so I can also add the amount I paid before submitting the form. Also, having an option of selecting a rate from a drop-down every time I clock work/payment would be nice.
Since it’s rarely an even amount, or sometimes I don’t have the exact amount ready or the other person can’t give me my change, I simply want to keep track of how much was over/underpaid.
The widget at (2) should have a filter, so I can filter for a specific time range, i.e. This year, last year, etc. This filter should also apply to the table widget at (3) — widget (2) should then show the cumulated amounts I should have paid and the cumulated amounts I did pay as well as the “tip” as a sum and as a %.
So far, widget (1) does not seem possible as the form needs to be published via a URL, is there a similarly nice solution? (In a pinch I can also directly edit the table, but then I could also simply use Excel :-/
Widget (2) I have absolutely no idea how to incorporate a filter AND the mentioned data/calculations.
Widget (3) should be easy as it is simply a table and if another widget selects this one as “select by” the filter should apply.
You are trying to use a form as a Widget. Unfortunatelly, they can´t be used like that. You publish them. And send them as LINKS Notce you can fill the form right there.
the closer you get to a form is the Card Widget. Yes, it’s not the same as a form, meaning that as soon as you write something you are already recording it, unlike a form where you must click a button to send the data.
there were some discussions a while ago on how to simulate forms and publish and edit data buttons on Grist cards.
But you would have to mess with permissions and specially the Action Button widget.
If I am not mistaken, one solution would consist of having a temporary holding table, same fields as the one you really use. You write on that table, but the data is not sent to the REAL table until you click the SEND Action Button, which copies the data from the temporary table to the real one.
Thanks for the offer. I would love to do that, but I think I’d rather wait until my thread about grist + authentik + OIDC has been clarified/solved, so I won’t interrupt access to my grist instance while sorting out authentication.
Thanks, I could do that, but that document would not contain more than you can see on the initial screenshot. All that I need is one table with the column you see in the screenshot and a “pretty” way to fill it in.
Pretty means, not editing the table by hand.
It means clicking to get a drop-down for date and time, with the current date/time preselected so it becomes a one-click-process.
The card widget does not seem to do this while a published form does.
And then as explained above, I need to be able to see stats for i.e. current month, last month, this year, last year.
Which shows how much I have tipped or still owe.
If this does not clarify my questions, please ask specific questions. The screenshot shows everything I have.
Here is a proposal. Honestly, no screenshot, no explanation is worth a quick-and-dirty showcase: it makes it easier (and faster) for us to understand what you expect, and easier for you to discuss our proposals and understand how to adapt to your situation.
Thanks, and I apologize, I misunderstood. I thought you asked me to share it to better explain my use case which didn’t make sense to me.
Of course to tinker and actually help (which you did, and I appreciate) a proper shared document is the way to go. Sorry for making you create this, I should have just shared mine as it is identical to yours to spare you the trouble.
Now in reply to your mock-up:
the Payment widget does exactly what I was looking for except it’s a hassle to type in the time instead of selecting it (like a published form does)
the Stats widget seems to simply show what I need but does not seem filtered by anything. Ideally I was looking for a quick drop-down to switch between different fitlers.
For the Payment widget, the trick is you should fill directly the End field, by double-clicking it: that way, you may click on “Today” for the date, and yes, the time can only be typed. But there is a trigger formula on the Start field, so it should be automatically filled. If you prefer, it’s possible to invert that (if you fill it at the end of work). It remains possible to use the workaround about the form widget, and it won’t have any negative influence on any other part.
The Stats widget is filtered, and you may add different ranges by clicking on the top-right three dots menu, then “Show raw data”. It isn’t exactly a dropdown, but you may navigate thanks to the arrows on top right, or thanks to PageUp and PageDown keys.
I think I just dissected all the widgets you provided in order to figure out all your tricks Are these all the tables involved? Your test document you shared has plenty of pages and I haven’t yet figured out if it is possible to somehow see all tables attached to a specific page.
One more question, I just noticed the rates here on top. Do you have a keyword for my search to figure out what that object up there is called, and how does it figure into the whole solution? I mean I see I can edit those rates but no idea what else is behind them being shown up there.
The Rate field in the Payments table is a reference field: the formula in Should uses $Rate.Rate, which means “the value of the Rate field of this record within the Payments_Rate table”.
As Grist is awesome, you may directly enter new values within this table by typing a new value within the Rate field in Payments, and clicking + to add this value into the referenced table.
But sometimes, when making a typo (or if you want to change the default rate), you need to edit the referenced table itself. In those cases, instead of “wasting” a whole new page, I prefer adding a widget on the same page, and collapsing it onto the top.
Thanks, I’ll mark this as solved. Your proposed solution does what I asked for, although it’s not as “pretty” as desired and workaround-ish it does the job.
I learned a few tricks by looking at your configured widget.
Also, it looks like if one wants stats and sums and such, it’s rather better to do it via additional tables and just show the results via widgets? Is this correct? I am referring to the “stats” widget, could that be done directly without the help of the additional table payment_stats as in having a widget dynamically calculate stuff rather than just showing figures calculate in a table?
I am referring to the “stats” widget, could that be done directly without the help of the additional table payment_stats as in having a widget dynamically calculate stuff rather than just showing figures calculate in a table?
This is exactly what I did: I first added a table widget, then changed it to a card. Every widget you have on a page (including tables) is in fact a widget, backed by a data table (that you can see in the raw data page).
Are these all the tables involved? Your test document you shared has plenty of pages and I haven’t yet figured out if it is possible to somehow see all tables attached to a specific page.
