search

National-Forestry-Authority / farmers

0 stars 1 forks source link

Deprecate Harvest & Accounts sections #87

Closed peacog closed 2 years ago

peacog commented 2 years ago

The Harvest and Accounts sections should be deprecated, although each area/sub-area crop needs to be able to be retired through indicating it has been harvested, which then releases it for the establishment / creation of a new crop

peacog commented 2 years ago

Hi @LeScruf , @Rashids2021

Can you clarify what is required here?

Removing the Harvest section would mean deleting the following:

Removing the Accounts section would mean deleting the following:

LeScruf commented 2 years ago

-- Should we remove harvest and accounts completely, including any existing data? -> Can these parts of the system be depreciated for now and hidden, just in case they need to be revived in the future?

-- What does it mean to retire each area/sub-area crop through indicating it has been harvested? We have an Area Harvest checkbox on sub areas. Is that what you mean? -> Yes - the check box should retire the area/sub-area but I think it would be good if retired sub-areas were viewable in a separate section (we need to look at how) - such that they can be 'unretired' if they have been retired by mistake, and also be available for subsequent review and analysis?

peacog commented 2 years ago

Hi @LeScruf . We will hide the harvest and accounts section but leave the backend in place.

As for retiring a sub-area. Do you mean that if the check box is ticked the sub-area will not appear in the Sub-areas tab on the farmer's page? An administrator would be able to retrieve it from the drupal content administration page and unretire it if it was done by mistake.

LeScruf commented 2 years ago

Hi, re para 2, yes correct. This then enables an entirely new sub-area to be created as needed to replace part or all of the retired sub-area. I guess then, in order to retrieve / reinstate the retired sub-area, one would first have to delete any new overlapping sub-area first. This means a rule / script will need to created to prevent overlapping areas being created / retrieved - if this is not already the case (if not this is something to add as a key functionality).

peacog commented 2 years ago

We don't currently have that functionality. We would have to compare the polygon against other existing polygons and warn or block if one already exists, correct?

LeScruf commented 2 years ago

Yes. Else we'll get all sorts of overlapping polygons...

On Tue, Mar 15, 2022, 15:24 peacog @.***> wrote:

We don't currently have that functionality. We would have to compare the polygon against other existing polygons and warn or block if one already exists, correct?

— Reply to this email directly, view it on GitHub https://github.com/Cambrico/tree_farmer/issues/87#issuecomment-1067926031, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ3CXI62OGI2T6HEUKOCK3VAB6ODANCNFSM5OX3KBZA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>