Fix rebase error
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Today
Don't create the user, test the supposedly existing one instead
Addressed comments
In D5046#63456, @machniak wrote:BTW, none of the other registered passport clients are added via the migration. Maybe they should too. However, as all of them depend on existing-in-config client secrets and Ids, I'm still not sure migration is the correct place. Maybe we should have something like a "global seeder".
BTW, none of the other registered passport clients are added via the migration. Maybe they should too. However, as all of them depend on existing-in-config client secrets and Ids, I'm still not sure migration is the correct place. Maybe we should have something like a "global seeder".
Check for existence first
Thu, Dec 5
We call the seeder after migration, so the seeder will fail because the record already exists.
We should probably contemplate a standard mechanism for cases like this, so we don't copy paste these definitions around.
move the migration to the environment specific overlay
Wed, Dec 4
Tue, Dec 3
Fri, Nov 29
Thu, Nov 28
I tried taking into account how states override each other
Wed, Nov 27
Avoid pushing resync jobs for deleted users
This warning message is not that useful without a wallet ID, I suppose.
Tue, Nov 26
Regarding syncrotons needs:
- I think we need to get away from the timestamp comparisons and instead store whatever we need to as part of the synchronization state (tied to the synckey)
- Ideally we find something better to store than all entries in a folder that are part of the tag, or at least a more efficient representation than huge urls.
just as an fyi, purging users became less of a priority, so I'm parking this diff for now.
Rely on onlyTrashed
Do not disable a pending mandate
Really only test the IMAP_READY status
Rewrote resync to use separate queries for created/deleted