Avoiding stepping on changes

[jean]

Does Trello expose a 'last modified' timestamp?

Answering myself: yes it does. The resource to use is /actions, e.g. on a card: https://developers.trello.com/advanced-reference/card#get-1-cards-card-id-or-shortlink-actions Pass e.g. {'filter': 'updateCard', 'fields': 'date'}.

• Is it possible to avoid overwriting newer with older content? (I.e. ask Trello to block if the POST'ed timestamp is older than the target resource.)

[its-rigs]

How would you know what is old an new content?

What I mean is if you have posted to update a card name already and then I post to update the same card name, how can you determine that the second request is older content?

Even though it may be second and may therefore be older, doesn't mean that it isn't valid to send that request.

[jean]

I'm thinking of the case where I get a card, using Trolly, at T1. Someone else updates that card at T2, unbeknownst to me. Now I change my card.

I'd like Trolly to tell me: hang on, your card is out of date. Do you really want to overwrite the change from T2 unseen? or do you want to have a look at the most current state and reconsider? [Case 1]

It's also possible that me and you both get the card at T1 and change it at the same moment. Or you change it via the web just after I sent my edit via Trolly. In this case Trolly has no inkling and the last change to arrive at Trello wins. [Case 2]

Since I tend to use Trolly interactively I can hang onto cards for quite a long time and they could well get out of date. So handling Case 1 seems useful to me. However if you're editing cards in a loop it would be irritating if it blew up wherever it encountered an older card. I see two ways of dealing with this:

• be specific in what you check, to avoid false positives. Trello can let you know if it's the description, or some checklist, etc.
• make the check optional, e.g.: card.update(..., force=True) doesn't check.

A nice adjunct to this would be card.refresh() which you could call just before updating it to make sure you're working with the latest state.

[its-rigs]

I think exposing the last modified seems like a good idea but I think it's on the consuming service to actually handle checking this date and avoid stepping on changes. Since this is just a wrapper around the API I'm not convinced that it should provide this sort of functionality itself.

[jean]

Fair enough, I'll look into exposing the info when I get back to Trolly.

On Tue, Mar 22, 2016 at 3:40 PM, Luke Rigby notifications@github.com wrote:

I think exposing the last modified seems like a good idea but I think it's on the consuming service to actually handle checking this date and avoid stepping on changes. Since this is just a wrapper around the API I'm not convinced that it should provide this sort of functionality itself.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/plish/Trolly/issues/37#issuecomment-199702570

jean . .. .... //\oo///\